Hello @mocoloco, without any further replies or questions, we will consider this thread as solved by Thursday and flag it accordingly. Thank you for your understanding, Ferdinand

Hello Ferdinand, yes, I was talking about the plugin ID argument of GeDialog.Open() and Restore(). Thanks for your explanation. I'm completely fine with your answer, despite some seeming here and there. I do understand the problems a codebase grown over decades can cause for answering such questions definitely. Nevertheless your explanations largely sync with my expectations from quite a few experiments. Regarding the mentioned issue of the other thread, I can acknowledge, the plugin ID parameter did not seem to have influence on the issue in my experiments. This question here was really more targeted the sizing issues I have with requesters of varying content. And your answer provides me with some confidence, I can make use of different plugin IDs (I should probably rather say unique IDs from Plugin Café) even if they are not related to any registered plugins at all. While I had already thought so and did not find any issues with this practice, it's always a bit hard to know for sure from the outside. And there's always this feeling one could be doing something harmful, which will only bite at the worst possible point in future. Thanks for the clarification. Cheers, Andreas

Hello @pyr, without any further replies or questions, we will consider this thread as solved by Thursday and flag it accordingly. Thank you for your understanding, Ferdinand

Amazing, thank you @ferdinand! I figured GetActiveDocument() was the issue, so I was attempting to use takeData.GetCurrentTake() instead in the GetResolutionTakes callback but it still was exactly the same issue where the active take does not change. I didn't know about the callback data argument that already contains the correct document state in data[0], so thank you for letting me know to use that instead and pointing me to further details in the RegisterToken Documentation. Replacing: doc = c4d.documents.GetActiveDocument() with doc = data[0] renderData = doc.GetRenderData(takeData) with renderData = data[1] to get the following code below worked perfectly: def GetCameraName(data): doc = data[0] bd = doc.GetRenderBaseDraw() sceneCam = bd.GetSceneCamera(doc) camName = sceneCam.GetName() return camName.upper() def GetResolutionActive(data): renderData = data[1] renderResX = round(renderData[c4d.RDATA_XRES]) if renderResX >= 1920: return "highRes" else: return "lowRes" Thank you again very much for the help! Really appreciate it.

Hey Andreas, no need to feel sorry. It is valuable for us to be aware of this, as this could cause more serious problems further down the road, even though it is hard to reproduce for now. We have pushed this off to QA for now, due to them having the required tools (hardware) to assess this more thoroughly. I do not see anything inherently wrong with that. But the only ones who could answer this with complete certainty are the developers who wrote the Cinema 4D core. And until we cannot say with a reasonable degree of certainty that this is a reproduceable bug that we want to address, I will not bother them with this, since there is other "stuff" in front of the queue for them anyway. I have forked your second part of the question, as I would like to keep this thread clean, as I would anticipate that QA will confirm this bug, it then going to the developers, and we will then report back here. Which will get a bit convoluted when there is a second question being discussed here. The topic can be found here. I understand that this is not the most satisfying procedure for you, as it will take a bit of time. The issue of yours must go through our bug tracking system now first, rather than taking the shortcut we sometimes offer here, of us talking with the developers and then creating an issue if we decide to do so. Cheers, Ferdinand

Hi Maxime. Sorry for the confusion, I was referring to a Redshift material node, and a specific node called "Round Edge". We know that we can edit the rounded edges node via the API in Xpresso materials already, but we were trying to not use Xpresso here. Turns out, we can actually edit the Round Edge node in Redshift materials when we use c4dpy instead of executing the script by placing a .pyp file in the plugins folder. This solution works for us, so I think this issue is resolved. Thanks!

Hello @Boony2000, without any further questions or postings, we will consider this topic as solved by Wednesday and flag it accordingly. Cheers, Ferdinand

Thanks for the info!

So, now we have a maxon.Int :} Yes, the system is working - thx @m_adam Consider it solved // more info in general on the maxon framework - especially on the python side - would we be welcome..

Hi Ferdinand, thanks for the confirmation and looking into it. While it's a bit unfortunate, I do not consider this a major road block. From my side this thread can be considered close. Cheers

Hi, @Boony2000 you are right, the documentation will be fixed. Cheers, Maxime.

Hello @kng_ito, without any further questions or postings, we will consider this topic as solved by Wednesday and flag it accordingly. Cheers, Ferdinand

Hi! Thanks for your input! I just found the cause. There is an os.kill call on the C4DPL_ENDPROGRAM message. If you leave it out some python stuff seems to keep running and preventing Cinema from being opened again. I am assuming that's why the original author did that. I will just catch the dirty flag myself and deal with unsaved scenes before terminating the process. Unless you know a more elegant way. I will mark this as solved. Thanks again. P.S.: This is off topic, but trying to reply I would always get an error and I had to log out and in again to post this. EDIT: I found the elegant solution - Adding c4d.documents.CloseAllDocuments() before the process termination handles the save dialogs perfectly!

Hello Paula, of course, I understand these restrictions, but on the other hand it is in this case hard to just guess the problem. Feel free to reopen this subject at any time. Cheers, Ferdinand

Hi @ferdinand RE: Please note that this is not a commitment of us to do this regularly . . I understand. Thanks for the detailed explanation and background theory for the answer. Have a nice ahead! Will close this thread now.

Hi. Oh I understand, thanks for your answer, it has helped me a lot.

Hello @JH23, without any further questions or postings, we will consider this topic as solved by Wednesday and flag it accordingly. Cheers, Ferdinand

Hey @ferdinand Thanks again! I think the question is closed

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

@cairyn Thank you again. I will check your patreon