@Cairyn Thank you for your reply. The "odd result" it's means the scene is empty , no objects were generated. According to your explanation, I have solved the problem. And it's just an exercise code. Thank you again !

Hi @jenandesign, thank you for sharing your little setup. I think your suggestion is great, but the problem is: We cannot handle feature requests in the SDK-team which are not directly concerned with one of the APIs. And although Cinema's old node editor is kind of "coding-related", it is in the end not directly related to one of Cinema's SDKs, which is the ground we do cover here. So I would have to ask you kindly to bring up your suggestion with Maxon's end user support, as they do handle these kind of requests. Cheers and thank you for your understanding, Ferdinand

Hi @jochemdk, without further questions or feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

@zipit @lasselauch thank you both for your time and knowledge!

Python plugins do not work reliably in R23 on OSX 10.13.6. The C4D minimum spec is for 10.14.6 as Riccardo mentioned. And even if you try to debug a plugin on 10.13.6 what you will notice is that many calls (such as print) don't even work on this OS. So you can't even write anything out to the console to see what the problem might be. No amount of re-installing C4D will help you at all. You just have to let your customers know that the minimum spec for R23 is 10.14.6 and not guarantee any support for anything below that spec.

Thanks for the confirmation. (Follow-up questions moved to a separate post)

Hi, without further feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

Apologies, I thought my mention of the Voronoi Fracture's ability to generate vertex map tags (itself being a generator that deals with variable geometry) would be clear enough, but I suppose a casual mention doesn't suffice for an app this complex, haha! Yeah, it's really all about overcoming that immutable nature of the vertex map tag. I'm generating them on parametric objects and I need them to be able to adapt to changing point counts. Just like they're able to do on editable polygon objects. Which means I have to create a new tag each time the host object's geometry changes and update anywhere else it's linked. That's where TransferGoal() comes in. Where my function was failing was a result of TransferGoal() not only updating the BaseLinks, but also the variables within my code. So in my function, once TransferGoal()is called, both vmap and replacement_tag variables end up referencing the same tag (the new one), leaving me without a variable filled with the old tag to delete. Passing True as the second argument left my variables alone and only updated the links, essentially making it work perfectly. So passing True or False to TransferGoal() didn't make any difference as far as the BaseLinks were concerned. Those always updated correctly. If I had to guess I would say it has to do with the memory addresses of the objects being transferred... which is just more reason to avoid ignoring that little instruction in the sdk;) I'll trust the devs on matters of memory handling lol. Turns out it's quite easy to work around. Since I insert the new tag directly after the old tag I can simply use GetPred() to find the old tag and successfully delete it. As far as your question as to whether I would consider this desirable or expected behavior, I would say no. I would much prefer that my in-code variables remain as they were before calling TransferGoal, because as it currently is I'm left with two distinct variables that hold the same object. In other words, I'm left with redundancy and it ends up preventing me from doing more to the old BaseList2D object. In my case, it happens to be relatively easy to re-find and re-reference that BaseList2D object, but that might not always be the case. But yeah, now I have a working skeleton function (that doesn't break the rules lol). Just gotta bulk it up with appropriate checks and I should be good to go! Thanks for your help @zipit! Cheers! Kevin

That are great news, but sadly I am not a Phyton User

@zipit Hi, thank you for the message. Yes, I believe I already understood everything you explained and I do appreciate your efforts. I knew I wasn't doing anything with the descid in my code, I was just confused as to why when I change one attribute, I was getting MSG_DESCRIPTION_POSTSETPARAMETER messages from all of the attributes as opposed to just the one attribute. Perhaps it is something else in my code that is sending those. Regardless, it isn't hugely important, I was trying to be as efficient as possible. Thank you.

@kbar Thank you for the reply and helpful link. And for anyone look to get this working with your Description files: (from https://c4dprogramming.wordpress.com/2013/05/10/long-cycles-with-icons-and-separator/), put the plugin ids in your Description header and this in your Description resource file: CONTAINER Omyobject { NAME Omyobject; INCLUDE Obase; GROUP ID_OBJECTPROPERTIES { LONG MYOBJECT_ICONCYCLE { CYCLE { MYOBJECT_ICONCYCLE_ITEM_0; -1; MYOBJECT_ICONCYCLE_ITEM_1~Ocube; MYOBJECT_ICONCYCLE_ITEM_2~Opyramid; MYOBJECT_ICONCYCLE_ITEM_3~1021433; } } } } -1 creates a separator.

Hello @wuzelwazel, thank you for reaching out to us. I am sorry if I gave you the impression that this will be fixed with S24. This issue is still on our radar, but it does not have the highest priority. I am also unfortunately not a liberty to give you a time frame when this will be done. Thank you for your understanding, Ferdinand

Hi, ten times slower sounds rough. It is probably because I was a bit lazy and used a lookup table (visited) to traverse the scene-graph, which is a rather expensive thing to do. Feel free to use the fixed traversal if performance becomes an issue here. Cheers, Ferdinand

thank you both @a_block for enduring my beginner questions and zipit always keeping it precise and clean ,,, I managed to get an old script to run 20 times faster by just finding junk I was able to cleanup ! Even though as a beginner I sometimes do not know what I am doing this profiling helps to find stupid code! so few more scripts to cleanup.

@zipit Thank you, Ferdinand, for looking into it!

Hi Manuel, thanks for the info! If smooth is set to false, the wrong positions disappear in deed. The distribution of the positions, however, is much uglier. It requires the user to change some specific attributes of the spline to make it look nice. But I think, that's ok for now. Thanks again & greetings, Frank

Hi thanks for the report this was already reported in Phong Tag with ObjectData and this is going to be fixed in the release after R23 SP1. Cheers, Maxime.

@zipit I'll post code with my scenes/screenshots in the future. Setting the value in MSG_DESCRIPTION_POSTSETPARAMETER fixed my issue! Wow, how do you know all of this stuff??!

hi, Sorry for the delay of this answer, we simply missed your post. When using STRING READOUT_WIDTH { ANIM OFF; } it's important that you initialize the parameter in your Init function. Otherwise uninitialized type will be a int. At some point, the code is comparing the old value type with the new value. That's why it's waiting for a Int while you provide a Str. (feel like a bug to me) I don't see the problem using STATICTEXT or STRING. It does create the expected fields. The StaticText can't be Animated anyway, i would remove the ANIM OFF STATICTEXT PYPREFERENCE_STATICTEXT {} STRING PYPREFERENCE_STRING { } about the border around the static text you can declare the field like this in your ressource file: STATICTEXT PYPREFERENCE_STATICTEXT_BORDER {BORDER;} Cheers, Manuel