Hi, there is this thread where Maxime is talking about drag and drop. If you have any question about it, please open a new thread. We like to keep question separated. Cheers, Manuel

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

@manuel Thank you very much!

Hello, @ferdinand Thanks, I will take it into account. All the best, ... YB

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

@m_adam Thanks for you reply , and there is nothing worry about the time, you are much busier than me I already try the defaultX and nothing changed, the dialog is always bigger than I set , it seems the dialog is considering teh hiden element size or something , the code is bit long for the forum ( maybe we should add a folding option to the code block in the forum ), and I sent an copy to ferdinand , and newest version has nothing changed for the UI part, Is that convenient for you to get a copy from ferdinand or post your email I can send you emails to, Cheers~

hi, well, if it works. Cheers, Manuel

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

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

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.

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.

Hello @ferdinand, sorry for coming back this late. Work kept me quite busy. @ferdinand so, I had a play with your code example. It works like a charm and also seems to have a lot of potential for all kinds of update/dirty checking issues. Thanks again @ferdinand for your help, the effort you always put into answering our questions and the eloborate examples you come up with! Cheers, Sebastian

@manuel Hi Manuel, I just wanted to let you know that I have decided on your suggestion and have decided on a license system with serial numbers that are automatically created and delivered upon purchase and in combination with a kind of license server that controls the licenses..... thank you for the hints

@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~

@ferdinand thanks for your generoso help. I already send you an email with an zip file , and some notes in the front of the codes. Have a good day!

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

Hey @mogh, Thank you for pointing out that problem. No, there is no Vector(0, 0, 0) being added, there was simply a small bug in my code. self.min: c4d.Vector = c4d.Vector(sys.float_info.max) self.max: c4d.Vector = c4d.Vector(sys.float_info.min) float_info.min is 2.2250738585072014e-308, i.e., the smallest representable increment of the float type, not the lower representable boundary. So, the code did initialize the max-value boundary as ~(0, 0, 0) which then caused values to be discarded which should not be discared. I of course meant here the following: self.min: c4d.Vector = c4d.Vector(sys.float_info.max) self.max: c4d.Vector = c4d.Vector(-sys.float_info.max) Fixing this should fix your problems. I have updated my original posting to not mislead future readers. Cheers, Ferdinand

@manuel Cool ! Thank you ~

I use CreateLayout ... no description file ... but as I wrote probably a little bit to cryptic I am fine for now. Thanks for the reply Manuel. Cheers mogh