Thanks Ferdinand. Putting those lines in the projectdefinitions.txt of the solution was the... solution

Definitly interested

Thanks for your response. We found the issue. Turns out we had to delay load our dlls for earlier versions of the plugin R21 etc

I have a couple of MaterialData plugins that have input ports/pins that have changed in functionality. In order to make old scenes/materials work, I need to insert a ShaderData plugin inbetween the existing MaterialData port and whatever ShaderData is already connected to that port.

The documentation seems to suggest that versioning should be done at the NodeData::Read function, however this does not seem to be the right place as the gelistnode graph does not seem to be guaranteed to be fully instatiated when this function is called - which makes it a bad fit for changing the graph.

Aside from that I cannot find where I am supposed to do this type of version conversion.

I have NodeDatas that dont need their "Basic" to be shown. Is it possible to hide this tab?

Thanks for your reply m_adam

Thanks for providing the information that the init function should not modify the scene graph. Ill take this into account in the future.

I went through that example you linked, but Im a bit unclear why it is nessesary to manually create the handling of a custom and parallel nodegraph branch when plugin GeListNodes are already graphs themselves?

I am encountering a problem when rendering to picture viewer.
I have two plugins, a TagData and a NodeData as its child.
I also created a link from the TagData to the NodeData for easy access
However when the document is copied and sent to the picture viewer renderer there are two issues.

1. The link is not copied
2. The contents of the NodeData basecontainer are not copied over

The copied TagData does have a child object with my type, so it does exist

Here is how I connect the two plugins

Bool MyTagData::Init(GeListNode* node, Bool isCloneInit)
{
    BaseTag* tag = (BaseTag*)node;
    BaseContainer *data = tag->GetDataInstance();
    BaseList2D* mynodedata= BaseList2D::Alloc(ID_MY_NODEDATA); // Creating my MyNodeData
    mynodedata->InsertUnderLast(node); //Add as mynodedata as a child to mytagdata
    data->SetLink(MYTAG_NODEDATA_INK, mynodedata); //Add link for easy access
    return true;
}

This basically works in all situations, except when sending it to the picture viewer for rendering.
I feel like im missing something, but i cant find what in the documentation

@ferdinand

I wrote a whole a4 reply about your suggestions about maxon style, error handling and my opinions about the sparse documentation and the new api in general, but i deleted it because im just so baffled by how hard it is to just get a connected node, and then get a single enum value from a node that I literally stopped caring about code architecture and style. I have tried so many different thing now im at a loss at what is supposed to be the way to do this?

All I want to do:
1: Get the bumpmap that is connected to the standard material node. (com.redshift3d.redshift4c4d.nodes.core.standardmaterial.bump_input)
2: Get the inputType enum value of the bumpmap node (com.redshift3d.redshift4c4d.nodes.core.bumpmap.inputType)

I have tried so many different things im not even going to post code. I have read the sdk manual. I have rooted through the examples projects. I have read all the code comments in the headers. Never in my life have i spent so much effort doing something this conceptually simple. What am i supposed to do here?

I just want this value

I am trying to wrap my mind around the GraphNode api, and starting to get it a bit (i think)
However, im trying to retrieve the type of a RS Bump Map, however im having a bit of trouble.
I can get the bump map node itself, but I cannot seem to get the effective value that is in its port.
This is my latest attempt, it fails at typeNode.GetValue(maxon::EffectivePortValue,

ifnoerr(auto & bumpRes = inputs.FindChild(maxon::Id("com.redshift3d.redshift4c4d.nodes.core.standardmaterial.bump_input")))
{
    maxon::GraphNode bumpNode = getConnectedNode(bumpRes, maxon::NODE_KIND::NODE);

    auto assetId = bumpNode.GetValue(maxon::nodes::AssetId).GetValueOrDefault().GetValue();
    const maxon::Id& nodeId = assetId.Get<0>();

    if (nodeId == maxon::Id("com.redshift3d.redshift4c4d.nodes.core.bumpmap"))
    {
        ifnoerr(auto & typeNode = bumpNode.GetInputs().FindChild(maxon::Id("com.redshift3d.redshift4c4d.nodes.core.bumpmap.inputType")))
        {
            maxon::ConstDataPtr inputData2 = typeNode.GetValue(maxon::EffectivePortValue, maxon::DataType::DefaultValue()) iferr_return;

            auto type = inputData2.GetType();
            auto typeId = type.GetId();

        }
    }
}

Thank you Ferdinand. Ill try to remember to post bugs to the bug subforum.

There seems to have been a change to userarea default behavior in 2025.3 - however i cannot find this in the release notes.
Mouse clicks still trigger GeUserArea::InputEvent, however keyboard and scroll events no longer work with default settings.
I found that when i explicitly set USERAREAFLAGS::HANDLEFOCUS in the AttachUserArea it will work like it did in previous versions. However USERAREAFLAGS settings are poorly documented and i cannot find what the settings do or if i need them (HANDLEFOCUS, TABSTOP, SYNCMESSAGE)

Ok? will do

We are experiencing an issue where keyboard and scrolling events no longer call the inputevent function of a GeUserArea. They seem to ignore the active window.
It did work with older versions of 2025. Left, Center and Right mouse presses work normally.