@Cairyn @ferdinand Thanks for the response. The python generator works as expected. I did try to retrieve the cache earlier for mograph but with a python tag rather than a python generator, but it has some priority delays. Your solution is much more stable. Now, I don't have to jump to houdini for such simple scenes. Have a great day ahead!

Thanks Manuel, yes that's how I ended up doing it in the end. I thought it would've been simpler to extract a variable from the main function, since it had already calculated. All I would need is to save the variable somewhere where the button function can read it, so this is where I tried the global variables but it didn't work.

Hello Maxime, Thanks for fixing the category for my post. I am new to Cinema4D. I found the correct IDs by opening the UI for the material and drag and drop the settings into the Python console. Kind Regards, Chris

@m_magalhaes Thank you! Works perfectly. Dan

@m_adam alrighty got it working. Thanks again. You can close this thread if you like. Cheers, Sebastian

Hello @pim, without any further feedback or questions, we will consider this topic as solved by Wednesday and flag it accordingly. Thank you for your understanding, Ferdinand

hi @ferdinand thank you very much for your response! the python_init.py does the job perfectly great support, thanks a lot! best, marc.

Hello @JH23, without any further feedback or questions, we will consider this topic as solved by Wednesday and flag it accordingly. Thank you for your understanding, Ferdinand

@johntravolski I figured it out, I needed to add node.Message(c4d.MSG_UPDATE) after the for double loop where I set the polygons.

@m_magalhaes Thank you so much for the help! The script works fine after adding this line. Cheers, Kon

Hi @mfersaoui there is nothing wrong with the way you are doing, but I would like to point out that the sys.path is a global variable shared over the current python environment. Meaning that 3rd party will be able also to import your own module so it's recommended to have an ambiguous name (e.g. if your module1.py is called util.py) people will be able to do import util and this can be really misleading so it's preferred to have a unique name (maybe you can start with a prefix). Finally, the solution offered by @mp5gosu is the cleanest one as it will create a local import space, so your util.py will only be importable by your own pyp file that actually calls the local import so it's so far the cleanest way as you are not "polluting" the global sys.path. But which one is the best, only you can decide according to what you are aiming to produce. Cheers, Maxime.

Hi @blastframe, yes, that would be one, and probably the more modern way to do it. I personally like also an explicit call to the base implementation. I think it is more readable for someone else reading your code. But that is probably a rather subjective choice. So for clarity, I am speaking about something like this: foo = bar * baz return c4d.gui.GeUserArea.InputEvent(self, msg) There is of course the advantage of super taking care of calling the proper implementation(s) for you which is not taken care of by this approach, but you cannot have everything and in this case things are rather unambiguous for us here Cheers, Ferdinand

After a few mails with Ferdinand I switched to a Tag plugin solution. This does the job perfectly. So the solution was not to use an Object data solution but a TagData. Thanx!

hi, @beatgram said in Undo Problem For TagData Plugin: So these bracket notation style is safer than using BaseContainer in any case? this should be exactly the same. Sorry i didn't got time to warp my head around it. Cheers, Manuel

@mp5gosu Sorry, I missed it! That works! In case other devs have a solution, I'll mark yours as the right answer. Thank you!

@ferdinand Thank you, Ferdinand for the thorough answer and ideas for workarounds. I don't quite have my head around how to use threading in Cinema 4D yet but you've inspired me to look into it. Thank you!

hi, I don't see how we could do it with the Draw Method in a efficient way. Cheers, Manuel

Hello @HerrMay, thank you for your reply. Please note that we prefer users to flag topics as solved, as doing it ourselves always comes with the danger of erroneously flagging a posting as solved. Please refer to our Forum Guidelines - Forum Feature: Ask as Question in case you do not know how to do this. Cheers, Ferdinand

Hi @blastframe, so this is a bug that happens independently of Python. It also not connected to your example using a dangling dialog, but to the fact that it is using a dialog. When you implement some form of NodeData plugin and a FONT resource element in it, this bug won't happen. I have opened a bug report for this. For now you would have to either use my little workaround or move outside of a GeDialog environment an implement the whole plugin as some form of NodeData plugin. If a dialog is of high priority for you, you could also display an instance of that node in a DescriptionCustomGui inside your dialog. Which should work and somewhat be a mix of both options. Cheers, Ferdinand

Hello @blastframe, I forgot to put the final outcome for this here. So, after some back and forth we decided to not fix this for reasons I unfortunately cannot disclose. But we will update the documentation in an upcoming release to avoid this being as opaque as it currently is. This is probably not what you hoped for, but currently the best course of actions for us. Thank you for your understanding, Ferdinand