@r_gigante said in Copying / cloning a Volume Builder object.: AliasTrans Great news, I will try it. Thanks. Edit: Yes, everything is ok now! But to be honest, I do not fully understand the functionality. The manual says "Normally Cinema 4D provides an alias translator when needed, for example in NodeData.CopyTo(). However, to copy objects manually use: ..." So, the advise is to use this functionality when copying objects? I see the functionality is here since R17, but this is the first time I came across this issue and this solution.

Hi Riccardo, I think the issue is solved because there is no any issue. Some not good methods of software distribution just confused us. Btw, what benefits different parameters of SetPluginPriority() give to us? For example the xdll has several plugins like materials, shader, tags and renderer. Even some icons with plugin ids. What priority is better to use in this case? I see https://developers.maxon.net/docs/Cinema4DCPPSDK/html/page_manual_module_functions.html For example, what is C4DPL_INIT_PRIORITY_ADVANCEDRENDER: Does it give higher thread priority during some PV rendering task? Or does it just load the plugin before other renderers and give the chance to lock system resources before others?

Hi @mikeudin, first of all, I would like to remind you about the Q&A New Functionality, I've setup your post as a question but please try to do it yourself for the next topics. With that's said, some optimizations have been done since R18 and now a MoText retrieves data from its Tmgweight only if this one is getting dirty while before it was retrieved for each execution. Unfortunately, the Python method GeSetMoDataWeights have not been adapted, so I've filled a BugReport, for now, please consider to call mo.GeSetMoDataWeights(ms_tag, wlist) ms_tag.SetDirty(c4d.DIRTYFLAGS_DATA) # Since you are in a tag, next one are not necessary since tag is part of the scene graph execution # and are executed before the current object evaluated. # Meaning that obj GetVirtualObject will be called in in any case after reading the tag # and since the dirty count of the tag has changed, the Motext will retrieve them and not the one cached. obj.SetDirty(c4d.DIRTYFLAGS_DATA) obj.Message(c4d.MSG_UPDATE) Btw, thanks a lot for the scene, that help us to quickly reproduce the issue ! If you have any questions, please let me know. Cheers, Maxime.

@m_adam Thanks, Maxime! You solved yet another issue.

Hi @merkvilson, Actually, the issue came from inserting the matrix as a child of the cached spline. The cached spline gets a rotation of X then you apply again the rotation of the generator, which make X+X rotation. In order to avoid that, return one null with both object. def GetVirtualObjects(self, op, hh): if not op.GetDown(): return None gch = op.GetAndCheckHierarchyClone(hh, op.GetDown(), c4d.HIERARCHYCLONEFLAGS_ASIS, False) output = gch["clone"] gchDirty = gch["dirty"] if not gchDirty: return output null = c4d.BaseObject(c4d.Onull) indexView = c4d.BaseObject(1018545) output.InsertUnder(null) indexView.InsertUnder(null) indexView[c4d.ID_MG_MOTIONGENERATOR_MODE] = 0 indexView[c4d.MG_OBJECT_LINK] = output return null If you have any questions, please let me know. Cheers, Maxime

Hi @m_adam, thank you for your answer! I'll try command line. Cheers

Hi @merkvilson, this feedback has been communicated to our development team. Cheers, Maxime.

Hi Daniel, Thanks a lot, you are indeed right, SimpleMaterial.cpp has been fixed. Cheers, Maxime.

After a reboot, I'm able to reproduce it again... I will create a bug report and more testing after Season's Greetings & SDK Team Vacation. Anyway thanks a lot. Cheers, Maxime.

Thanks a lot Daniel for following up here. Glad to listen that the update actually fixed it, although even on 20.030 I had no better luck to reproduce. Best, Riccardo

Hi, this sounds more like a TR issue and not so much an SDK problem. If so, then I suggest to rather use the How Can We Help? form on MAXON's homepage. Cheers, Andreas

@a_block No inconvenience at all, just happy to hear it's not only me!

Hello, Indeed this example is wrong. We will fix that as soon as possible. Thanks for noticing us. best wishes, Sebastian

@r_gigante That's sad, because it's a recurrent issue we have. I'll try to isolate it as soon as I have some time.

There is no question here. Just a bug report and a warning/info to other users if they get C4D locking up when using a treeview.