Thank you for response @ferdinand! Will try to make it with hidden tags

@m_adam thanks!

Hi Kent, so far for the moment the viewport drop operation are more related to scene management rather than scene creation. By that I means except for an asset being loaded which create new elements (scene, object, material, etc...) other drag command are just here to act on the active object. So regarding drag operation for file, only DRAGTYPE_FILENAME_IMAGE is allowed and an object should be selected, then a texture tag will be applied to this object and a new material with the texture will be automatically assigned. DRAGTYPE_FILENAME_SCENE is not supported. For DRAGTYPE_ATOMARRAY it is only allowed for some particular categories, like layers to be applied on the active object or even materials for the same condition, so in any case the layer/material should already be part of the scene. So for the moment the only workaround would be to create your own temporary asset and pass this asset to be inserted into the document. For more information about the asset API I let you read Asset API - Handbook but this is S26.0+ only. Cheers, Maxime.

@m_magalhaes Thanks for the detailed explanation as to why it crashed！

Once again, thenk you very much for all the information, Ferdinand. What I had done already was the last "solution". I do have a file inside the plugin folder that, when the code detects that it is present, skips some verifications. So, I guess I will go on doing that. That even allows me to check for specific filenames and perform different actions for each one. I was just checking to see if there was any type of build-in mechanism to emulate that pragma directives did. And I do know that python is interpreted and that real pragma directives are evaluated in the prepass stage. But I didn't knew if the Source Protector performed some type of evaluation, when protecting the code.

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

Hello @jack0319, Yes, this is a bug. I had to do some digging first (debug against c4d) to find out what is going wrong here. It seems like this is a bug in the scroll group gadget. I was unable to pinpoint what is going exactly wrong, but when a new document is created, the scroll group position is set again, because Cinema 4D is reinitializing its layout. You currently cannot do anything about this. I have filed a bug report on our bug tracker and will update this thread when the bug has been fixed. We cannot make any guarantees regarding an ETA and considering that this is a negligible impact bug, it could take multiple revisions until the bug is fixed. Cheers, Ferdinand

Hello @pixelsinprogress, Thank you for reaching out to us. I must unfortunately tell you that it currently is technically not possible to set the alpha values of a c4d.Gradient instance in Python. In C++ this works because there Gradient::GetAlphaGradient returns a pointer to the underlying alpha gradient. The Python layer unfortunately makes a copy of that layer, severing the connection between the alpha gradient and its associated color gradient (which is also why the Python docs warn about that). I also tried some other venues of poking around in the alpha data by using C4DAtom.SetParameter, but these unfortunately also do not work in Python. I have created a ticket for this to be fixed at some point, as I would agree this is something the Python layer should be able to handle. But this is not a bug, as this was done somewhat intentionally. So, it might take a long time before we (most likely @m_adam) will find the time to do it. Cheers, Ferdinand

tx, i just wanted to report it...

Hello @a_block, Thank you for reaching out to us and pointing out these flaws. We are aware of these changes but since it was for quite some time unclear if these changes were intentional or not, we postponed documenting them. The changes to the look and functionalities of GeDialog borders will be included in an upcoming documentation. But since these changes effectively demand symbols or even function arguments to be deprecated, this would be more a developer's task than a documentation task. I can of course put a note into the documentation, but this would only be a band aid. I will try to find a clean solution by poking the relevant devs. Cheers, Ferdinand

Just for the info, calling the command to open the PictureViewer and RenderDocument with both c4d.RENDERFLAGS_CREATE_PICTUREVIEWER and c4d.RENDERFLAGS_OPEN_PICTUREVIEWER works just fine for me : c4d.CallCommand(430000700) # Picture Viewer c4d.documents.RenderDocument(doc, rdData, bmp, c4d.RENDERFLAGS_EXTERNAL | c4d.RENDERFLAGS_CREATE_PICTUREVIEWER | c4d.RENDERFLAGS_OPEN_PICTUREVIEWER)

Hi Jesse, thanks for the report those issue have been fixed and will be up in the next update of the documentation. Thanks a lot for reporting them and if you see other one please report them ! Cheers, Maxime.

First thank you Ferdinand, as always, you put so much effort in your answers, this is so great.. Related to my code, yes there are of course weird things going on sometimes :-), I am not professional and the API is sometimes like a jungle and so Python, so I am messing up a few things...This process is called "learning" But anyways thank you for your detailed and quick answer.... Sincerely Thomas

Hi Ferdinand, thanks for the quick and detailed answer, even trying to find workarounds. I had hoped, I could spare you this extra effort by saying, that it's no functional issue on my end. I am already satisfied with the confirmation. Often it is enough to be able to stop worrying about my own mental integrity. And while this new behavior certainly will not improve performance, I can happily ignore performance issues beyond my own responsibility. Regarding the GeDialog stuff: No worries, either. As mentioned back then, no future fix/solution can help me there and I went down a different route to get the project done with support for R19 to present. Yet, I'm thankful for your tenacity and that the issue is still being researched. Some meals simply need time to develop their flavours. Thanks and cheers, Andreas

Hi, thanks for the information. Hopefully it will get fixed in the future updates. Cheers, Arttu

Hello @WTools3D, without any further questions, we will consider this topic as solved by Tuesday, November the 2nd and flag it accordingly. Thank you for your understanding, Ferdinand

Hi @SteveJLV, the APPEND mode is not supported by the HyperFile. The FILEOPEN enum is also used in BaseFile, which is the underlying class used by the HyperFile. BaseFile properly support Append mode, but extra code in the HyperFile prevent it to work correctly. So far I don't see any workaround possible for you in Python, the only way would to first read the HyperFile and rewrite everything + the things that you want to Append (pretty inefficient). I opened a bug report, to support APPEND within HyperFile. I set this post to solved, and I added the tag ToFix t your topic, but don't worry we will keep you in touch when a fix will be available but we can't say when it will be available neither if it will be fixed. Cheers, Maxime.

yes exact, it's a bug not an error from your implementation.

Hello @kbar, I should have replied here since there is at least an implied request in your last answer. I have added a task for this in our documentation task pool and added the tracking tag to this topic. Without any further questions or replies, we will consider this thread as solved by Monday the 20th and flag it accordingly. But that does not mean that the topic is forgotten, due to its to fix tag. Thank you for your understanding, Ferdinand

Hello @indexofrefraction, without further questions or replies, we will consider this topic as solved by Thursday and flag it accordingly. Just for clarification: This does not mean that the bug is solved or that we won't track it, we simply do not want to keep the thread open until the bug has been fixed. The bug status is tracked with the to fix tag that has been added to the topic. We will report back here when the bug has been fixed. Thank you for your understanding, Ferdinand