@m_magalhaes Thank you for answer!

Mike, thank you a lot!

Thanks Maxime, "NOCAMERA;" worked, and the priority was a typo, now it does work!

Just one last comment on this licensing issue. I have a video that tells users how to install and license my own plugins for R21 upwards. It has been viewed 33,882 times as of today. It is my most watched video every month. I don’t have that many customers or sales. These views are from regular C4D users using Google to figure out what to do now since the old way is gone.

@m_magalhaes Thanks for the confirmation. I have meanwhile found that while the API doesn't cover the OM window states, you can still call CallCommand and IsCommandChecked on the functions. c4d.CallCommand(100004762) # Show Search Bar c4d.CallCommand(100004719) # Show Path Bar c4d.CallCommand(100004746) # Show Filter They only address the last used OM though; it doesn't seem to be possible to target a specific OM (like it is possible with the Open/Close flags which are stored as NBITs). And of course it doesn't tell me anything about the current visibility of an object in the OM. If the developers will think about commands to cover the filter/search/root conditions, they may want to go one step back and think about a more general concept to handle the multi-copy windows (Object Manager, Attribute Manager, Timeline) in some way that allows me to ask what was the last window, the active window, a window by index.

Unfortually no you can't.

Hi @orestiskon, thank you for flagging the topic as answered. Cheers, Ferdinand

Correct, thanks for poitning it I will add a task to improve documentation of Custom GUI

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

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.