Hey @ThomasB, so, I had a look and figured it out. When you diff the two objects from my file, there are quite few differences (as I was not 100% faithful in copying all values), but the culprit is this: [image: 1783349248850-cef8fb22-88d1-4073-8b29-1e2958c0db14-image.png] The RS Light uses a standard light to accomplish its VP representation. When you disable the 'Illumination' checkmark, the RS Light GetVirtualObjects will simply return a null object, i.e., the behavior you experienced. I filed a ticket for this (ITEM#651586 Inconsistent Redshift Light 'Make Editable' behavior), as I would consider this so unintuitive that it borders on a bug. But this is outside of the SDK/Cinema 4D domain, so I cannot just fix it myself. In Python, there is currently no way to fix this on your side. The message MSG_CURRENTSTATE_END is not wrapped for Python (with it you can manipulate the output of a "Make Editable" action before it is inserted). The other route, the build flags on HierarchyHelp are also not possible in Python either, because HierarchyHelp is also not wrapped for Python. But I just changed the latter route, and in the next major update you will be able to react to build flags. There will also be a new code example named py-objectdata_buildflags_2027 which showcases this feature. You can then react to your object being made editable, built for rendering, built for export, etc. and react by changing its output. In your case you would then probably not disable the illumination when your object is being made editable. So, for now, you either have to live with the behavior, or turn on "preview > illumination". Cheers, Ferdinand Result The output, i.e., diff, with the offending line highlighted. [image: 1783418649677-d0a8e14c-d913-4990-9ec5-29e4a5150cf3-image-resized.png] Code This assumes my scene from above with everything deleted but the two objects. import c4d import mxutils import difflib doc: c4d.documents.BaseDocument # The currently active document. op: c4d.BaseObject | None # The primary selected object in `doc`. Can be `None`. def main() -> None: """Called by Cinema 4D when the script is being executed. """ data: list[str] = [ mxutils.GetParameterTreeString(node) for node in mxutils.IterateTree(doc.GetFirstObject(), True) ] # Diff the first two strings in the list and print the result to the console. if len(data) < 2: return c4d.gui.MessageDialog("Not enough data to perform diff.") a: str = data[0] b: str = data[1] diff: list[str] = list(difflib.unified_diff(a.splitlines(), b.splitlines(), lineterm='')) if not diff: print("No differences found.") print("\n".join(diff)) print("\n\n" + "=" * 80 + "\n\n") print(a) print("\n" + "-" * 80 + "\n") print(b) c4d.EventAdd() if __name__ == '__main__': main()

@ThomasB That is not a misunderstanding. I am aware that MRDs can only see their own tickets. But we still needed that crash reported, so I did it. I would have done the same if you would not have been an MRD. I usually mention ticket IDs here so that I can come back and close bugs. As you might have noticed, I have moved this into the Bugs forum. You do not have to do anything regarding that ticket, it it inaccessible for non-Maxonians. But we are still very much interested in a version of your plugin or a workflow which caused the crash. Otherwise we will not be able to reproduce and fix the issue. When you cannot provide it, this is also not a biggie (please do not waste time on this), then we have at least documented that there is somewhere a problem with audio tracks and how they handle memory while post-processing audio; in case we run into the same issue in the future in another context. Cheers, Ferdinand To share plugins with us, you can either use a chat on backstage or send us a mail to sdk_support(at)maxon(dot)net. There is a good chance that when you use a binary data attachment in a mail, that our mail system will filter out that attachment. When you use backstage (and upload the plugin there in a chat) that data would be permanently in the assets of that forum. When you just give us a link, we will delete your data once we do not need them anymore for debugging.

@ferdinand Thank you for your detailed explanation, it shed some light on the whole matter for me.

@i_mazlov Thank you very much for the hint with the texture view and for the helpful links. The second thread I have already read, but was not able to find the solution so far. I study these examples. Thank you.

@ferdinand Thanks a lot Ferdinand for your time and effort. It is always admirable how carefully and thoroughly you answer many questions. At first it was often difficult to understand and follow your code examples...now it is a little easier. Thanks for that. I found out that the following method also does the job: c4d.SendCoreMessage(c4d.COREMSG_CINEMA, c4d.BaseContainer(c4d.COREMSG_CINEMA_FORCE_AM_UPDATE), 0) Sorry for the second question about why this buttonDesc[c4d.DESC_FITH] = True buttonDesc[c4d.DESC_SCALEH] = True in the GetDDescription method are not working. I thought this is a follow-up question. I will open another topic for that.

Hi @ThomasB, sorry for the issue. This is going to be fixed in the next version of Cinema 4D. With that's said you can workaround the issue by using directly SetParameter like so: # key[c4d.ID_CKEY_PRESET] = 2 key.SetParameter(c4d.DescID(c4d.ID_CKEY_PRESET), 2, c4d.DESCFLAGS_SET_NONE) Thanks for the report ! Cheers, Maxime.

Hey @ThomasB, Thank you for reaching out to us. Without your code we cannot really help you, we are not the oracle of Delphi There are many things which could go wrong in your plugin. But in general what you are doing is correct; add a dummy point object with your snap points to your cache, when you want to introduce special snapping points for your custom generator object. Snapping onto the points of the returned geometry should work out of the box (but snapping sometimes struggles a bit with deep caches). There is however only limited support for adding special snapping points, as it is not really intended to add you own snap logic in that manner. The snapping module both in Python and C++ does not allow you to implement your own snapping logic, you can just read some data. You should also keep in mind that the snapping is an older part of Cinema 4D which has its flaws. You should check if your problem also does occur when you try to snap onto the converted cache of your object (current state to object). If that is the case, you know it is not something your plugin does, but simply the fact that the snapping struggles with that specific geometry/scenario. Cheers, Ferdinand

Good to hear!

@ferdinand Hello Ferdinand, Thank you very much first of all. yes, you're right, I worked extremely sloppily with the SMC method, of course I'll take the threading into account and also work with a Temp Document. Regarding the problem itself, I can only say that reinstalling CINEMA 4D solved our problem. Cheers

Hey @ThomasB, That has nothing to do with the highlighting but with the fact that Maxime used incorrect links. developers.maxon.net/docs/ links will only work from outside of the forum. Inside the forum you currently have to use dvelopers.maxon.net/assets/docs/ as otherwise nodebb is trying to take over the routing. I am working on fixing that issue. I have fixed both links of Maxime. Cheers, Ferdinand

@ferdinand This is a command, and you can c4d.CallCommand it, but that is all the control you have. thank you Ferdiand,

@ferdinand Thank you Ferdinand for your leniency regarding the three questions.. Will take note of that in the future. =====BaseTime===== Which just surprises me about the BaseTime problem is, that it worked in the Python tag. I didn't get an error message and the prototype worked very well. So I also tried instead of BaseTime int type value in the plugin, but it crashed. It confused me a bit. So I try your suggestion. # In the python tag it worked with int # starf_frame was an int frame = doc.GetTime().GetFrame(doc.GetFps()) - op[c4d.ID_USERDATA,start_frame] ====PoseMorph Symbol==== Regarding the posmorph ID, I should have figured that out myself Thanks for your quick respond Tom

@ferdinand Many thanks for this detailed example, I'll try it out P.S. Oh my gosh, it's working perfectly. I decided to go the easiest way, just to check the dirtyness of the linked object. linkDirty: bool = link.IsDirty(c4d.DIRTYFLAGS_DATA) Many many thanks Thomas

Hello @ThomasB , without further questions or postings, we will consider this topic as solved by Friday, the 11th of august 2023 and flag it accordingly. Thank you for your understanding, Maxon SDK Group

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

@ferdinand At first I wanted to do it exactly like you recommended, but then I thought why, if you save 36 IDs, it's certainly more memory-efficient. And when you just rename it, you've already learned something again. Actually, I wanted to do it with separate IDs. But then I recognized that I need the exact same 3 parameters, just with other Labels. but since renaming was faster, I decided to do it. It's an update of the previous version of the plugin and it was easiest to just change the labels. I'll think about it, I've got time. Thank you because my English is not always the best, I sometimes find it difficult to read your texts. They are already very extensive in some cases. Good evening!

@ferdinand thank you very much

Hi James, You can use GetDeformCache() for that in place. The rest of the code would stay exactly the same, just add the following three lines before retrieving object points and polys: obj = obj.GetDeformCache() if not obj: raise RuntimeError("Couldn't retrieve objects deform cache") By the way, there's a great example that showcases the workflow with generators and deform caches: geometry_caches_s26.py Cheers, Ilia

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

@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