Hello, I'm not aware of any other components that won't work with that optimization. But again, we don't use this optimization so I haven't tested that. best wishes, Sebastian

@s_bach Wow! I didn't see that coming. Thanks for the clear-cut explanation. Now I know in which direction I have to move. Thanks again !

@s_bach Hello Sebastian, Thanks a lot for clearing my confusion. Now I know what to do. Thanks for the help! Best Regards Gogeta

@a_block Case solved! Thanks again for your patience.

Hey Maxime, thank you very much for the detailed explanation. Makes absolute sense now! It works perfectly now. I tried a similar approach, but I was adding the Undo in g_MakeInstanceEditable() per object - that was the main culprit. Cheers, Robert

Thanks very much. (There is so much information to be read!). -Pim

Hi Gogeta, glad that in the end it worked out properly. Please, in order to close the topic, mark the post that actually solved your initial question or simply mark the thread as solved from the Topic Tools menu Cheers, Riccardo

Hi zhhm156, so for coming late here, but it took more than expected. After getting in contact with the team in charge of the development and making some further researches, it appears that the VerifyServerOnClient function is indeed deprecated. I'll get back on this discussion in the future to notify about potential workaround to achieve a similar functionality. Best, Riccardo

Great, thank you.

@mp5gosu deleted an owned topic is now enabled for all users and no error is anymore notified when attempting to delete a first post. Best Riccardo

Thank you.

Great, thank you for the great explanation, especially of the loop! I will give it a try. -Pim

Hello, please see here: https://developers.maxon.net/docs/cpp/2023_2/page_maxonapi_programming_advice.html and especially here: https://developers.maxon.net/docs/cpp/2023_2/page_maxonapi_dev_windows.html (Windows includes)

Hi, actually this is not a bug, but a design decision. Here at MAXON we have a pretty large code base and especially disabled code branches tend to age a lot faster. So we try to force developers to also maintain such code pieces or to at least think about, if they are still valuable and otherwise remove and thus cleanup the code base. Cheers, Andreas

Hi, glad you were able to solve your problem. We'll take this as a hint and see if we can improve our documentation in this regard. Cheers, Andreas

@a_block Thank You so much Andreas ! I would like to try all the suggested approaches and hopefully I'll get my issue resolved (except second option is out of my context as I can't use another application). Third potion seems to be the best suited option and I would like to give it a try. Thanks Again...!

Hi, it depends... Via the NETRUNONSERVER flag (to be returned from GetRenderInfo()) a VideoPost specifies, that it can be run on the server. Where the VideoPost is actually executed in the end, depends on the scenario. For a distributed single frame rendering, such a VideoPost will be executed on the server. On the other hand, for animation rendering, where every client finishes entire frames, the VideoPost will nevertheless be executed on the clients. Cheers, Andreas

@m_adam Thanks. You are right. It didn't exceed 5GB. I guess 5GB is when it is uncompressed. I was able to build the plug-ins now.

Hello, LoadDialogResource() and LayoutFlushGroup() should work perfectly fine together. Typically LayoutFlushGroup() is called in reaction to some user interaction or in InitValues(): Bool CreateLayout() { if (!GeDialog::CreateLayout()) return false; if (!LoadDialogResource(11000, nullptr, 0)) return false; return true; } Bool InitValues() { LayoutFlushGroup(11003); AddButton(100, BFH_SCALEFIT, 0, 10, "Button"_s); LayoutChanged(11003); return true; } best wishes, Sebastian