Hey, Node attributes are things that are directly present on a GraphNode. You could also call them fields, because a GraphNode like many things in our API has qualities of a DataDictionay, i.e., you can write values over keys into it, just like for Python's own dict. Such node attributes (for true nodes) are then rendered out quite similarly to port values in the Attribute Manager but they are fundamentally different from ports, as users cannot drive their value with a connection, i.e., the value of a port of another node. And a port also always requires another GraphNode attached to the true node¹ for which they are a port, while the attribute sits directly on the true node. An attribute, e.g., the name of a node, will also never show up in the node representation in the graph. In the screen below I for example right clicked on the RS Reference node and invoked Add Input > All; but things like Name, Color, Show Preview etc. are alle not listed. [image: 1744368637847-174097cf-d777-49d2-b0ea-0057c8474a5e-image.png] That is because they are all attributes and not ports. There is unfortunately no absolute rule like 'everything in Basic is attributes and everything else is ports'. While it holds (for now) true that everything in Basic is an attribute, especially Redshift also puts attributes into other tabs. They usually only appear in more complex scenarios when dealing with port bundles and variadic ports, but they exist. And just for clarity, attributes do not only exist on nodes that are what our API calls 'true nodes'¹, but also on other GraphNode types, e.g., a GraphNode representing a port. It is just that they are usually not rendered out to the GUI there and more of an internal nature (nodes have a lot of internal attributes). Cheers, Ferdinand ¹ GraphNode instances that represent what the end user would consider a 'node', e.g., the RS Reference node, and with that excluding GraphNode instances that for example represent an input port.

Ah, super! thank you.

@ferdinand said in SAVEDOCUMENTFLAGS_AUTOSAVE still added to the recent file list?: But please provide instructions on how to use your code when required in the future. oh shit, i'm so sorry. you're right. completly missed this one. ... and of cause thanks for the explaination / clarification.

@i_mazlov Thanks

@ferdinand said in How to simulate a drag behavior with UA?: All it it does when the users starts to drag, according to Maxime, is inject the asset object into the document, make sure there is no object selected and then enable the place tool (and probably set the mouse cursor) This is my solution in my mind, definitely take a try after work.

Hey @T1001, I am still not 100% sure how you all mean that. But in short what you are doing is not possible in the public API and also only to some degree in the internal API. First of all, Cinema 4D only supports HDR in the viewport and it must be enabled by the user: [image: 1744104813146-f4036fae-fdc3-44bd-bd44-b876a51f4699-image.png] I.e., viewport effectively means Drawport API. What the docs write there about the only the viewport is only semi true, because you can embed a drawport into a GeDialog (but that functionality is still not even semi-public I think, but we could change that in a future release). I am not quite sure what you mean by 'integrating a custom OpenGL pipeline into a plugin'. When I take this at face value, I would say you cannot do this. The Drawport API is an abstraction around effectively Vulkan and Metal. We do not write OS specific graphics API code anymore. This goes as far as that we have (sort of) our own shading language (MSL). You cannot just draw with OpenGL into a GeDialog, because that dialog will not be drawn with OpenGL and we also do not offer a direct access point to drawing handlers. I assume this all has something to do with implementing some kind of render buffer? I really would recommend then applying for the Maxon Registered Developer program to get access to the Drawport API. Just as a warning ahead, the Drawport API is not totally undocumented but not documented to the same degree as our fully public API. It is an API from graphics API experts for graphics API experts. You seem fairly knowledgeable there, so this might be just your thing, but you have been warned, there will be less hand-holding there. Cheers, Ferdinand

Fantastic @i_mazlov ! Both issues are solved, thank you so much ! Cheers, Flavio Diniz

@ferdinand Thank you for your kind explanation. I will explore other options.

Hey @skibinvitaliy, Welcome to the Maxon developers forum and its community, it is great to have you with us! Getting Started Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules. Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment. Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support. Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads. It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: How to Ask Questions. About your First Question No one is judging you here, problems are part of the game and what we are here for to help with . But please familiarize yourself with our forum rules, such question should be accompanied by example code and the version you are migrating from, as we otherwise mostly have to guess what is going wrong. I am assuming you are migrating from a pre-2025 SDK, that is at least what your errors imply. With 2025 we introduced our cinema namespace. Please follow our Migrating Plugins to the 2025.0 API guide. You are likely just missing a couple of using namespace cinema; at the top of your files. Cheers, Ferdinand

Hi Sebastian, correct, it hasn't been included into 2025.2.0. The next minor release will likely have it fixed though. Cheers, Ilia

Hey, there is no NOT in the query syntax, if that is what you are asking for, although that could be a cool idea. What you would have to do, is apply two partial descriptions in one ApplyDescription call, one that first selects all nodes with an enabled preview and disables it, and then one which selects the end node and disables its preview. Or just carry out two successive ApplyDescription calls. Cheers, Ferdinand PS: You can of course do whatever you want with your module attributes, and things like __author__, __license__, __email__, etc are not formally standardized, but the quasi standard module attribute is called __author__, there is no __authors__. When you have multiple authors, you usually put them semicolon separated into the __author__ field. When you use __authors__, tools which support that quasi standard won't find your attribute and the whole purpose of these module attributes is being machine readable, as you could otherwise also just write things into the doc string of the module. See: The original Python Enhancement Proposal by Guido van Rossum (the now famous pep8) which introduced the concept of module dunder attributes and one of the many guides of how people interpret this, what this has evolved into.

Hi sorry I fixed my code. Cheers, Maxime.

Thanks, I'll test Dirty on selection.

Hi @BigRoy, Please check our Support Procedures in regards of the question structure, namely: Singular Question: The initial posting of a support topic must contain a singular question. Do not ask ten things at once, that makes it extremely hard to answer topics. Break up your questions into multiple topics. Asking follow-up questions is allowed but they must be bound to the initial subject. Singular Subject: From all this follows that a topic must have a singular and sparse subject tied to a specific problem. 'My Nodes API Questions' is not a valid topic as it splits up into too many subtopics. A valid subject could be 'accessing node attributes' or 'traversing a node graph'. One could for example first ask 'how to get the name attribute of a node?' and then ask a follow up question about 'how to get the icon attribute too?'. This specifically applies to plugins, just because you have two problems with one plugin does not mean that they should be asked in the same topic. Regarding you question, there's no high level API that allows you to get a list of all files you've mentioned at once. This effectively means that not only do you need to access this yourself, but you also need to do so for the render engines you'd like to support, as these are likely going to differ among them. Specifically for the Redshift AOVs and output files question, please check related threads: get the names of redshift multi passes AOV names from the render settings Add Expression Value in Render Settings Save Path As for the takes, the only application where they make any sense is the Render Queue. If you're not using it, it's only the active take that's being rendered. Of course you can deal with it by using SetCurrentTake function. I suggest you keeping this thread for the "render output files" part of your initial question and encourage you to make separate postings for your other questions that diverse from this topic here. Cheers, Ilia

Hey @Smolak, I understood what you wanted to do, but it is still not possible. First of all, the OCIO color space enum values are dynamically assigned, i.e., the value 3 might not always mean the same space. In the OCIO API there are special conversion functions for that, but you could also do that manually by parsing the description of the document. But you will never be able to apply such value then, because to do that, you have to call BaseDocument::UpdateOcioColorSpaces which does not exist in Python (yet). See the C++ Docs for an example. Cheers, Ferdinand

Thank you @ferdinand for the help! Write raw memory does help a lot, appreciate!

thanks @ferdinand this makes perfect sense now. I appreciate the time you took to explaint he best practice.

@ferdinand You are correct, there was no further question, I was just closing the loop in case someone else ran into something similar. Thanks for the additional suggestions. -v

@m_adam, Thank you! Yes, Message(GeListNode* node, Int32 type, void* data) works for me. I'm wondering shall my plugin just return true after processing MSG_DESCRIPTION_CHECKDRAGANDDROP in the Message() function (set the value of DescriptionCheckDragAndDrop::_result) or still call SUPER::Message(node, type, data); at the end? It looks to me that calling SUPER::Message(node, type, data); at the end still works. But the example in MSG_DESCRIPTION_CHECKDRAGANDDROP Message doesn't call SUPER::Message(node, type, data);. Thanks!

I use this to Thank You Ferdinand. This is how I imagine an SDK example should look like .... a simplest version , an altered simple version and a complex touching the boundaries of the subject. I am thankful and praise your work .... ! cheers mogh