Hello @FSS, without further questions or postings, we will consider this topic as solved by Wednesday 31/05/2023 and flag it accordingly. Thank you for your understanding, Maxime.

Eh, this was the first approach i tried, it will map the decoded utf-8 to Windows codepage 1252. (Sorry about the wrong one in the code above). I tried to change the system setting to utf8 but it would not accpet that. Thanks for your help, Maxime

Just a note as mentioned in the documentation BeginTransaction must always be used with the "with" statement, otherwise it could cause Cinema 4D to freeze. Cheers, Maxime.

Hey @brucek5, Thank you for reaching out to us. The Python interpreter shipped with Cinema 4D is not identical to CPython and it is not intended to be replaced by the user. Technically speaking you could try it, but this would be out of scope of support and will likely also fail. We cannot give instructions on how to do it, you would have to hack your Cinema 4D yourself. It also depends on how much you want to change the Python version. Given that you are on R21, i.e., Python 2.7, and likely want to jump to a Python 3.X version, the answer will change from "practically impossible" to "categorically impossible". Cheers, Ferdinand

First of all, thanks for your support. It is not possible, at least not without A LOT of work, to implement polygonal geometry that is driven by Attribute Manger parameters and can maintain vertex-by-vertex manipulations of users. You must reimplement all its vertex/edge/polygon interactions OBJECT_POLYGONOBJECT is sort of uncharted territory. That answers my question. My approach was trying if I could use the already implemented geometry interactions and add from that point. Since I found no example for OBJECT_POLYGONOBJECT, thought that could be it, but seems not. If you just want to some information being displayed for objects, I would recommend implementing a tag which does that. If you want to, you could hide that tag from the users view, and also write a plugin which automatically distributes that tag in a scene My plan B was along these lines, with a dialog to show the info. Thanks, Oscar

LegionLib_Release.dll: Legion::Mutex::lock + 0xc (SP: 0x000000379A5FF720, PC: 0x00007FFA368CF13C) Corona4D.2023_Release.dll: forcePluginDelayLoad + 0x1229cd (SP: 0x000000379A5FF750, PC: 0x00007FFA39D91F6D) Corona4D.2023_Release.dll: forcePluginDelayLoad + 0x1232fd (SP: 0x000000379A5FF7A0, PC: 0x00007FFA39D9289D) Corona4D.2023_Release.dll: forcePluginDelayLoad + 0x139f47 (SP: 0x000000379A5FF7D0, PC: 0x00007FFA39DA94E7) LegionLib_Release.dll: Legion::LowSystemMemoryChecker::`default constructor closure' + 0x90 (SP: 0x000000379A5FF870, PC: 0x00007FFA368F1CA0) KERNEL32.DLL: BaseThreadInitThunk + 0x14 (SP: 0x000000379A5FF8C0, PC: 0x00007FFAD5C674B4) ntdll.dll: RtlUserThreadStart + 0x21 (SP: 0x000000379A5FF8F0, PC: 0x00007FFAD6EC26A1) Registers The counter part to the Mutex. Now looking into hot reloading the dll. If I dont return avenge me.

Hi, We have an example on github to export to obj and how to define the parameters, you can find it here You need to retrieve the plugins with its plugin ID GLTFEXPORTER_PLUGIN_ID 1041129 There is no symbol attached for it. Then, you must send the message MSG_RETRIEVEPRIVATEDATA to define the option you want. For each parameter you will find its ID in the following file : \resource\modules\gltf\description\fgltfexporter.res You will find that the parameter you want to change is c4d.GLTFEXPORTER_FILEFORMAT and it should be set to c4d.GLTFEXPORTER_FILEFORMAT_GLB So just like in this line, you will write objExport[c4d.GLTFEXPORTER_FILEFORMAT] = c4d.GLTFEXPORTER_FILEFORMAT_GLB You should be able to clean the code from the obj example and adapt it to your needs. That will help for your thousands of exports. Cheers, Manuel

Hello @pixelsinprogress, Thank you for reaching out to us. I must unfortunately tell you that it currently is technically not possible to set the alpha values of a c4d.Gradient instance in Python. In C++ this works because there Gradient::GetAlphaGradient returns a pointer to the underlying alpha gradient. The Python layer unfortunately makes a copy of that layer, severing the connection between the alpha gradient and its associated color gradient (which is also why the Python docs warn about that). I also tried some other venues of poking around in the alpha data by using C4DAtom.SetParameter, but these unfortunately also do not work in Python. I have created a ticket for this to be fixed at some point, as I would agree this is something the Python layer should be able to handle. But this is not a bug, as this was done somewhat intentionally. So, it might take a long time before we (most likely @m_adam) will find the time to do it. Cheers, Ferdinand

Thanks a lot kbar.. i'll watch and learn! still... the hurdles to compile a c++ plugin are extremely high nowadays. it would be great if the sdk plugins would be downloadable ready compiled as well

Hi, We do not provide "on demande" script. We are here to share the knowledge and help you to find the information you need, but you must learn how to code and learn how some principales works. I provided you a thread where Ferdinand is explaining how it works to move an object to another position. We have a new example in our github repository that will help you to understand how it is done. In your case, there is no function that is doing that. You must move the object's axis at the position (0, 0, 0) and move the points at the place they were. It is a two steps operation. Cheers, Manuel

@m_adam - Now I'm sorry for my late reply! I appreciate you writing this up for me and I think it's a really good reference. This question has been answered then! Another quick question which sort of relates (I can create a new thread if admins want) - Do you have any recommendation for up-to-date C4D Python API training? I'm coming from writing Python in Houdini and Maya, but Cinema 4D seems to have a more unique setup with how to interface with their API. Any training recommendations would be appreciated. Teach a man to fish and... something something fish. Thank you, Clayton

thanks ferdinand... something to study when this summer heat is over .-)

Hello @InterfaceGuy, without further questions or postings, we will consider this topic as solved by Wednesday 31/05/2023 and flag it accordingly. Thank you for your understanding, Maxime.

Hello @fss, Thank you for reaching out to us. I understand your general question, but some aspects are unclear to me. What plugin interfaces/hooks are involved (CommandData, ObjectData, ...)? Your posting somewhat implies that you want to rely inside PluginStart (which is not technically part of a plugin interface) on another plugin being loaded, is that true? If you are in PluginStart(), at which boot message (the ones emmited to PluginStart) are you trying to determine if some plugin X has been registered? But i logged those out and it always seemed to be called before the commandline arguments are processed. I am not quite sure what is meant with 'logged those out' here? The quick answer is to call c4d.plugins.FindPlugin to determine if a plugin is accessible, but depending on what you are trying to do, this might not the right way. Cheers, Ferdinand

@ferdinand A little update for this topic , my final solution for this problem is reg some tokens , and reg a plugin to analysis the project name and set token string depend on project name structure . like a project name has a version sign like _v , than the output path set a $v for render . All the tokens can set by the analysis plugin . It is a bit stupid way but work well for a quickly set render path just one click. Cheers

We life and learn. Turns out one must select the material tag with doc.SetActiveTag(textureTag) before calling the command c4d.CallCommand(CMD.GENERATE_UV_COORDS, CMD.GENERATE_UV_COORDS) to bake the projection down, down into the ground. It now works as intended.

tx, i just wanted to report it...

thanks Ferdinand this cleared things up for me

Hello @a_block, Thank you for reaching out to us and pointing out these flaws. We are aware of these changes but since it was for quite some time unclear if these changes were intentional or not, we postponed documenting them. The changes to the look and functionalities of GeDialog borders will be included in an upcoming documentation. But since these changes effectively demand symbols or even function arguments to be deprecated, this would be more a developer's task than a documentation task. I can of course put a note into the documentation, but this would only be a band aid. I will try to find a clean solution by poking the relevant devs. Cheers, Ferdinand

AWESOME! Thanks @ferdinand!!!