@ferdinand Yes, thanks, that indirect answer is enough for me. I was mainly wondering whether a check performed on both the client and the server is robust enough, or if it could be bypassed using Python, for instance. I’m well aware that it can be cracked somehow. I’m also already using ExportLicenses() for my node-locking system in combination. Thanks a lot for your help.

This is not common knowledge, otherwise I would have spotted that earlier. So, you are not really expected to know this as a third party dev. You can look at the geometry_caches_s26.py example and there at this line, under [2] I mention that the cache of that object is muted. But that is of course only very indirect information and not enough to deduce this. I think we also talked about it a couple of times on the forum. The flag BIT_CONTROLOBJECT is set on input objects of generators, e.g., the to be extruded spline of an Extrude object, the profile and rail spine of a Loft object, the to be cloned cube and sphere objects of a MoGraph cloner, etc. As shown in the caching example, Cinema will mute the caches of input objects. To be very formal, they are actually built but then again deleted. BIT_CONTROLOBJECT marks such input objects. Your light in that scene should not have that flag, as it is not the input for some generator. But it somehow got it anyway, there is probably somewhere a bug. For normal scene evaluation that bug is also not really a problem (because as you saw from your own test, the light still converted correctly when you inserted it on its own outside of caches). The problems start when that irregularly as BIT_CONTROLOBJECT marked object is part of a cache. 'Make Editable' then incorrectly collapses the cache. Not only does it not stop at nested generators which are incorrectly marked like this, it also seems to apply the cache muting logic for input objects (resulting in the empty null object instead of the content of the cache of the collapsed generator). I already told the relevant devs that I consider this borderline buggy but they do not seem very inclined to do anything about this. What is effectively missing somewhere in cache resolvement is the evaluation if the flag BIT_CONTROLOBJECT 'makes sense on an object'. That is of not so easy to do, as generator - input object relations can be quite complex in Cinema. Which is probably also why the modelling team does not want to touch this. Cheers, Ferdinand

@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