Thank you.

Hey @thomasb, no worries, don't be too concerned about it. And you should not be ashamed, that was certainly not what I wanted to convey. "Every person his or her book", the second so called law of library science, is something I truly believe in. Everyone has valid information needs and we are trying to help users on their individual journey. You should not feel discouraged, we are and were all once in your place. But at the same time, I sometimes have to regulate a bit forum conduct as we, the Maxon SDK group, and other users are human too. And people tend to get confused, when they are being hit with a stream-of-conscious like threads were a user comments diary-style-like on his or her development state. It is not that I would not understand people are doing that. When one is in that situation, one is overwhelmed by the possible routes one can take, the amount of information to traverse. And verbalizing that does indeed help. But for someone who tries to help you or for people who later search for similar information, this "stream-of-conscious/diary" is then an obstacle rather than a help. So, sometimes I try to regulate both interests a bit. But as I said, please do not feel discouraged. Cheers, Ferdinand

@manuel Wow! Manuel thank you so much I'm new in code development so that's why its fo easy for me to have those kind of mistakes. Thank you so much for your support.

@ferdinand Yes you are right, in relation to this the self.spline etc is unnecessary that could also be a normal local variable. Is correct. But basically if I load a profile spline in my init method, for example, I can already save it in such a variable. I need to be able to access it from anywhere in the class. But here it is totally superfluous....sorry

Thanks for the update @m_adam

hi, well you cannot inherit from the Hair Object as you could from a class. What you can do is to load the description of the hair object or include it in your description, create the hair object internally and link your description parameters to the internal hair object. Probably add your own parameter in your description. Than inside GVO you could generate the hair object with those parameter and return the result of it. While this seems to be possible, there are probably a lot of issue you are going to face, be ready ^^ Cheers, Manuel

@m_adam Thanks. Works as expected!

Thanks, @ferdinand Yes seems intended but could be troublesome if you use mograph / redshift object color to drive something ? C4D Version : 2023.1.2 A solution to guide the user could be to disable the object color when set to "Render Instance" , but from a UX standpoint I am not a fan of taking away control from the user. thanks for taking it to CS kind regards mogh

Thank you Ferdinand for your time, and also providing a high / low level solution. As far as I can tell it works all as intended - my code now results in clean colors "measured". (in lowlvl R20 and highlvl 2023) I found a small discrepancy with render instances but that's another topic. Cheers, mogh

Hello @herrmay, Yes, it can be a bit cumbersome to write a whole abstraction layer, but most of the time it is avoidable to do that in the first place. In your case it should be pretty simple. Iterate over all layers you want to save to disk. Get the MAXON_CREATOR_ID UUID of each layer and its data container. Write the UUID and the data container to disk using JSON or HyperFile, I would recommend the latter as it will be less work. You only must convert the UUID bytes to a string, put the string into the file, then the data container and you are done. If you want to, you could also store all layer data in one file per document, or just have one giant file for all documents. Later load these hyper file fragments back and do what you want with the data. When you need the original node, traverse the layers in the active document for a node with the stored UUID. You could also make things fancier and search in all open documents or even store the document path in your serialized data and load that document. Saving things in the document container is a possibility too, you should make sure though to use a plugin ID for that. Cheers, Ferdinand

@manuel Thank you very much!

hi, well, if it works. Cheers, Manuel

Hi @ferdinand , I get it ! Thanks again to your reply!

Hello @gilleskontrol, welcome to the forum and thank you for reaching out to us. Websocket client in C4D - best practice for this? You must use a third party library, e.g., the popular websockets as our NetworkWebSocketConnectionInterface has not been ported to Python and CPython does not support the WebSocket protocol out of the box. Plugin_ID - why do I need to do this, how do I properly do this? You can get them here in the forum with the little plug icon at the top. See How to get Plugin IDs[URL-REMOVED] for details. If it won't work in the scriptmanager, (because scriptmanager will freeze up even with threading) how do I do it without the scriptmanager? The script manager is blocking by nature. It is not your thread which is blocking, but the fact that you have likely put some code into your script which wait for the spawned thread to end. Which will then run as all Script Manager scripts on the main thread therefore block it. You could technically omit waiting for your threads to end and therefore have a non-blocking script, but that would result in dangling and never ended threads which is a bad thing. When you launch your thread in a plugin, this problem can either persist or go away, depending on what you do. There is no general answer to that. Let's assume you have the method MyPlugin.Foo. When you spawn the thread T in Foo, you wait for T to end before you exit Foo, and Foo runs on the main thread, as for example CommandData.Execute, you will experience the same problem. What you can do is: Wait for a thread T to end from a function f which runs on the non-main thread S. Doing this makes rarely sense in Python but you would not block the main thread doing this. You check for being on the main thread c4d.threading.GeIsMainThread. The more common and sensible approach is to defer reacting to your thread having ended to other places. In a dialog or MessageData plugin this could be a timer to parodically check in Message for your threads having ended. For nodes you could simply make the thread send the node a message once it has ended. Your documentation could really benefit from some step by step examples as searching for things you don't know the names of or why you even need them is next to impossible. Hm, I agree that our documentation lacks an abstract subject-matter access which can make traversing its content over subjects something in between laborious and impossible. However, the solution to that would be subject indexing and not having a perfectly matching tutorial for every possible information need of users (although that is of course what all users want). In which area did you find step-by-step information to be lacking in your case? Cheers, Ferdinand [URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

Hi @StefanGMBG debugging python plugin is not possible in Cinema 4D R25 since debugpy previously known as ptvsd hardcoded the type of the files so you can debug only .py file. However since S26 we released a Visual Studio Code Extension that work with a Cinema 4D Plugin. And this extension once correctly configured as shown in Cinema 4D Connector - Documentation let you loads, runs, and debugs Cinema 4D scripts and plugins from VS Code. Cheers, Maxime.

Hey @mogh, Thank you for reaching out to us. The idea of a node, a c4d.C4DAtom not being alive means that the Python layer cannot find the C++ C4DAtom which the Python layer c4d.C4DAtom was referencing, usually because something has been reallocated in the background while someone was long-term storing a c4d.C4DAtom instance. We talked about it here in more detail. Sometimes you then must write elaborate interfaces which recapture the same thing over their UUID, e.g., get hold of the same shader once its Python reference has gone bad. But that does not seem necessary here since you are interested only in the active viewport of the active document. It is in this case also not only the case that the viewport could have been reallocated, but also what is the active viewport could have changed (although that will likely cause viewports to be reallocated). So, when you want to modify the active base draw, in fact any node, make sure to get a fresh reference when possible. doc: c4d.document.BaseDocument = c4d.documents.GetActiveDocument() bd: c4d.BaseDraw = doc.GetActiveBaseDraw() self.AddCheckbox(ID_SAVEFRAME, flags=c4d.BFH_LEFT, initw=270, inith=0, name="Show Save Frame") self.SetBool(ID_SAVEFRAME, bd[c4d.BASEDRAW_DATA_SHOWSAFEFRAME]) If you need access to the active viewport of the active document very often, you could make it a property with some mild caching. import c4d import typing class Foo: """Provides cached access to the active document and active viewport. """ def __init__(self) -> None: self._activeDocument: typing.Optional[c4d.documents.BaseDocument] = None self._activeViewport: typing.Optional[c4d.BaseDraw] = None @property def ActiveDocument(self) -> c4d.documents.BaseDocument: """Returns the active document. """ if self._activeDocument is None or not self._activeDocument.IsAlive(): self._activeDocument = c4d.documents.GetActiveDocument() return self._activeDocument @property def ActiveBaseDraw(self) -> c4d.BaseDraw: """Returns the active viewport in the active document. """ if self._activeViewport is None or not self._activeViewport.IsAlive(): self._activeViewport = self.ActiveDocument.GetActiveBaseDraw() return self._activeViewport def Bar(self) -> None: """Makes use of the #ActiveBaseDraw property. """ self.ActiveBaseDraw[c4d.BASEDRAW_DATA_TEXTURES] = True Although this also suffers from the problem that what is the active viewport could have changed. Caching anything that is "active" is a bad idea as what is active can change. Active entities should always be retrieved when required unless one can guarantee that they cannot change (by being in a modal dialog for example). Cheers, Ferdinand

@ferdinand Thanks for your help. I did search on web and find the Unicode string, and Chinese characters is so much complicated ，when most user use Chinese for the GUI language, Maybe sometime the translation of the world "在队列中" witch means "in the queue" in English has changed ( I belive now Chinese translation is response to IHDT so it won't randomly changed). That is not a big problem but maybe a little "uniform" with the "ID" And the "brief moment" is I don't sure why does it happend. In another word ,I think the initializing render process can be also called "rendering" . so it is a bit of counterintuitive for me , maybe I should add an additional check to make sure the spying will not break while the brief. Cheers~

Hello @wuzelwazel, without further questions or postings, we will consider this topic as solved by Friday 02/06/2023 and flag it accordingly. Thank you for your understanding, Maxime.

Creating an instance for each subdialog solved the issue thank you so much.