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

@ferdinand Thanks for the reply! Ah, of course, I should have considered that Command is actually the last message I get for that operation. This Message stuff totally got me on the wrong track. Naturally, resetting the link and thereby cancelling and reverting the user's drag or pick operation is not as nice as showing a "stop sign" mouse pointer during the operation. Since the ACCEPT clause in a Resource allows setting accepted types, I wonder why there is no API functionality allowing the same. It's not even in the C++ implementation. I suppose people should use external resources anyway, but seeing stuff in the API makes functionality clearer to me at least. Regarding PyCapsule, no, I didn't happen across that previously, I just took code from some other thread on this forum to get into the message. I was lazy and looked for PyCapsule in the Cinema 4D API doc, and assumed it undocumented when it wasn't found. Totally my fault, I should have checked the web too. Never program in an unfamiliar scope past midnight! Nice code btw.

Hello @fss, thank you for reaching out to us. I would first point out three things: We cannot help users with bugs caused by third party plugins or libraries. We cannot disclose how to read our crash reports in detail, both from a practical and willingness standpoint. I also have difficulties following what you are here talking about in all detail; it is just a little bit too much tech jargon for my librarian brain. Information about Cinema 4D Crash Reports The primary data provided by a crash report is the _BugReport.txt file. It contains a stack trace for the list of stack frames which led up to the exception/crash. Our traces are organized bottom-up, i.e., the first entry in the stack is the thing which led to the crash. Stack traces mostly make sense in an environment where you have also access to the source code (or debug symbols) of the binary you are debugging. You can debug against our SDK, or more specifically the frameworks contained in them, to get more meaningful stack traces when debugging, however: We cannot provide the full declarations of the Cinema 4D API (i.e., the private frameworks and core modules) or debug symbols for them. When you want to debug a binary that is not port of Cinema 4D, e.g., the Corona plugin binary, you will either need at least the declarations of entities (a.k.a. "frameworks") or the debug symbols for it. So, when a crash happens in our core, you will also not get too much useful information out of a debugger attached to the binary with the public frameworks included. Because they do not contain information about our core. In its serialized form a trace (a _BugReport.txt) does not provide too much useful information. // The stack trace container. CINEMA_4D_Crash_Report_WINDOWS { // The thread container in the trace. Call_Stacks { // The thread in which the exception did occur. Call_Stack_Thread_9180 { // The stack frame which caused the exception which led to the crash. Here it happened // in the binary which handles a CPython virtual machine for Cinema 4D. pythonvm.module.xdl64: Ordinal0 + 0x14ae32 (SP: 0x000000BD342F8850, PC: 0x00007FFADC16AE32) // The frame before that in the same binary. pythonvm.module.xdl64: Ordinal0 + 0x145db3 (SP: 0x000000BD342F8950, PC: 0x00007FFADC165DB3) // The call before that came from the CPython binary, it yields a bit more descriptive // information without a debugger attached, as we get here function names and not just some // memory offset to the binary. python39.dll: PyUnicode_InternInPlace + 0x461 (SP: 0x000000BD342F89B0, PC: 0x00007FFAD8221DDD) // ... } // A stack trace for another thread which has been executed. Call_Stack_Thread_BLAHBLAH { // ... } //... } } I do not really understand where you get your information from regarding logos, 'KernelLand', and the 'hexadress of the position in the dump that corresponds to the error number'. But without the source code or debug symbols you cannot make much sense of it. It could be that Corona is using a lot of Windows libraries, but in general, our code is very OS agnostic. So, it seems unlikely that you found a crash in a Windows binary. Cheers, Ferdinand

You can also filter your objects. Using GetInfo for example, you can check if the current object is a generator or not. If you make a generator editable, the generator will/should handle the children itself. The only exception are primitives. Primitives are generators but they do not care about their children. Cheers, Manuel

Thanks alot Ferdinand. I investigated some further and added the classes to the plugins list: _plugins = [ "Tools", "Recipe", The error was also caused, by the executables having different libraries. Meaning, we call once cinema 4d.exe, which uses the {prefs}/python39/libs folder. The second part of the plugin is executed using the classic Commandline.exe and uses the {prefs}_x/python39/libs folder. Im a idiot, but a stubborn one. Have a great day. Topic can be locked now.

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

Hi @m_adam , thanks for your apply. I have solved this problem. The reason is I used maxon::BaseArray to store tree node data. When I append the array, the address of node may change, but the next pointer in node remain unchanged. And this cause the crash.

Got it. Thank you.

@kbar, thank SO MUCH. I will look into it.

Thanks for the link to the updated page on the dev blog.

Thank you for your very kindness support.🥺 There are methods I didn't know about Python, so I learned a lot! I've already assembled the other parts, but I'm going to update it with the code you wrote. Please let me know if there is anything else! Cheers!

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

First of all, thanks for your support. It is not possible, at least not without A LOT of work, to implement polygonal geometry that is driven by Attribute Manger parameters and can maintain vertex-by-vertex manipulations of users. You must reimplement all its vertex/edge/polygon interactions OBJECT_POLYGONOBJECT is sort of uncharted territory. That answers my question. My approach was trying if I could use the already implemented geometry interactions and add from that point. Since I found no example for OBJECT_POLYGONOBJECT, thought that could be it, but seems not. If you just want to some information being displayed for objects, I would recommend implementing a tag which does that. If you want to, you could hide that tag from the users view, and also write a plugin which automatically distributes that tag in a scene My plan B was along these lines, with a dialog to show the info. Thanks, Oscar

Hello! Sorry for not providing any specific info about the problem, it was not really aything to provide in fact. Your last guess about document related stuff is absolutely correct. There is a piece of code responsible for handling a license which was indeed using documents. Thanks!

@ferdinand Thank you!

Hello @DGLopez, without any further questions or other postings, we will consider this topic as solved and flag it as such by Friday, 17/06/2022. Thank you for your understanding, Ferdinand

Hello @bentraje, without any further questions and other postings, we will consider this topic as solved and flag it as such by Friday, 17/06/2022. Thank you for your understanding, Ferdinand

Kindly ignore. Adrian from Redshift forum answered it. You can look into the rslight.h from Plugins\C4D\R26\Redshift\res\description, all the parms are there

Hello @yaya, without any further questions and other postings, we will consider this topic as solved and flag it as such by Friday, 17/06/2022. Thank you for your understanding, Ferdinand

Aaaand of course I forgot a crucial point: After modifying the clone positions in marr, you need to write them back to the MoData, but the last parameter apply_strength must be False: moData.SetArray(c4d.MODATA_MATRIX, marr, False) This is at first glance unintuitive since we want the strength to be present but when looking closely, you can fathom that the function will internally multiply with the falloff strength that it calculated itself, and that probably comes from GetFalloffs() again, so it's 0 and nothing is won. We do not want SetArray to do that at all, because we have already applied the falloffs that we calculated ourselves, and SetArray should keep its buggy hands off it!