Oh! Forget guys my message above!

The calling of Python code from C++ plugin in @kbar 's advice does the trick!

If someone from the future who will read this thread will need the code example, I just use the code snippet from here: https://developers.maxon.net/docs/cpp/2023_2/page_maxonapi_python.html

and feed to it this code:

// call it from somewhere
String code = "import c4d\nimport maxon\nimport os    ";
        code+= "\n\nprint(f'This is simple message')";
        code += "\nos.rename('C:/Code/sdk/plugins/myPlugin/myPlugin.xdl64', 'C:/Code/sdk/plugins/myPlugin/old_myPlugin.old')"; 
        
ExecutePythonScript(code, GetActiveDocument());

Hi.
After 2024.4 I got a message from the customer that now my plugin broken.
It seems the old Dynamic Connector was rewritten in the 2024.4 release and was significantly changed. But the release page says: "Legacy Connectors will be compatible".

I've realized that the Dynamic Connector which my plugin creates is not compatible anymore.
F.e. Instead of legacy FORCE_TYPE DescID now there are two DescIDs: FORCE_TYPE_GROUP and FORCE_TYPE_MODE.
It is pretty frustrating, because now all legacy force_types (like Fixed, Slider, Ragdoll, Hinge, etc) have different ID values. The "Fixed" was 6 before the 2024.4. Now it is 0. Etc.

I've rewrote my plugin in part of FORCE_TYPE and now my plugin creates correct force_types. But now I can't understand what is going on with the old OBJECT_A and OBJECT_B settings of the Connector? In previous versions we were able to add the Joint object here. Now I can't. I am trying to drag and drop my character's joint into the new "Objects" field but nothing happens.
My plugin really depends on the Joint object in this field. 
Is it not possible to use Joint objects with the Bullet Dynamic tag as objects which Connector connects anymore?
If yes, then legacy Connectors are not compatible anymore.

If I am not right and Joint object is still valid I can't understand how this code should look in a new version?

connector->SetParameter(ConstDescID(DescLevel(FORCE_OBJECT_A)), objectA, DESCFLAGS_SET::NONE);
connector->SetParameter(ConstDescID(DescLevel(FORCE_REFERENCE_A)), 2, DESCFLAGS_SET::NONE);

Hello @ferdinand,

Yeah, it will hard to debug, I am agree with you. This problem was strange and hard to debug even in previous versions. I almost blindly found that time that BaseSelect::Free(polyS) somehow has fixed that issue (yeah, I understand how it sounds for you). I just think that two piece of code 2023 and 2024, the second is without BaseSelect::Free(polyS), the second one works wrong, the first one works entirely correctly, despite that this line should do nothing. That's why I assume it should do something behind.

Have you tried flushing polyS before leaving the scope, because that is the implicit effect of freeing the selection? I.e., call polyS->DeselectAll()

My plugin in this module takes the character's mesh and cuts it for parts to make ragdoll's colliders. So each new iteration of -

BaseSelect* polyS = polyObj->GetWritablePolygonS();

-the polyObj is (become) a new mesh.
Before the polyS->DeselectAll(); I change the meshes structure in other parts of code: make cuts, delete polygons, delete points, MCOMMAND_SPLIT, triangulate polys, add new edges etc. Of course ->DeselectAll() too. Then in the piece of code above I grab the resulting mesh and trying to delete isolated islands. But if I do not do the BaseSelect::Free(polyS) before, then I do not get the "Access violation" but in the result "happens something" and it selects not the polygons which should to be deleted...

Hey @ferdinand,

Thanks for your explanation. I understand what you say, and you have a logic, and most of all I am not right and you are, but I just remember that when I putted a lot of efforts to this code, everytime I got an incorrect work of mesh slicing in my plugin. Before I've added this line. Without freeing of BaseSelect it worked like the wrong version on the video above. It was very strange problem, which was looked like a bug, I couldnot understand its root. But when I've added BaseSelect::Free(polyS) it has started to slice my mesh correctly.

Could there be a small, most incredible possibility that this line did something?

Hello @ferdinand ,

Actually this code works perfectly in 2023.2. And in r21, 23, 24, 25, 26 too.

Now, in 2024 I've started to get the error above. So I decided to do not Free the base select as you say. But now my plugin starts to work incorrectly.
Here is the video of the comparison:

It is the same code, except BaseSelect::Free(polyS); which is now commented in version for 2024

This line (BaseSelect::Free(polyS);) was really necessary when I worked on it, and it does the stuff.

Good day. This code worked till 2024 in 2023 and early versions. But now in the v.2024 the last line throws exception: Access violation reading location.

I've edited the ->GetWritablePolygonS() as it described on the doc-page about 2024 migration and because the next ->DeselectAll() and ->Select() lines have started to return me an error.
How to correctly use BaseSelect::Free() in new 2024 is not mentioned.
Am I missing something with the adaptation BaseSelect::Free() too?

Int closestPolyID = GetDistanceToMesh(joint, static_cast<BaseObject*> (polyObj)).polyId;

        if (closestPolyID != NOTINDEX)
        {
            BaseSelect* polyS = polyObj->GetWritablePolygonS();
            polyS->DeselectAll();
            polyS->Select(closestPolyID);

            ModelingCommandData    gmcd;
            gmcd.doc = doc;
            gmcd.op = static_cast<BaseObject*> (polyObj);
            //gmcd.bc = &bc;
            gmcd.mode = MODELINGCOMMANDMODE::POLYGONSELECTION;
            if (!(SendModelingCommand(MCOMMAND_SELECTCONNECTED, gmcd)))
                GePrint("MCOMMAND_SELECTCONNECTED FAILED"_s);

            if (!(SendModelingCommand(MCOMMAND_SELECTINVERSE, gmcd)))
                GePrint("MCOMMAND_SELECTINVERSE FAILED"_s);



            //Convert selection from poly to pnt
            BaseSelect* pointS = polyObj->GetWritablePointS();
            pointS->DeselectAll();

            BaseContainer bc;
            bc.SetInt32(MDATA_CONVERTSELECTION_LEFT, 2);
            bc.SetInt32(MDATA_CONVERTSELECTION_RIGHT, 0);
            bc.SetBool(MDATA_CONVERTSELECTION_TOLERANT, false);
            ModelingCommandData cd;
            cd.doc = doc;
            cd.op = static_cast<BaseObject*> (polyObj);
            cd.bc = &bc;
            if (!SendModelingCommand(MCOMMAND_CONVERTSELECTION, cd))
                GePrint("MCOMMAND_CONVERTSELECTION FAILED"_s);


            AtomArray::Free(gmcd.result);

            BaseSelect::Free(polyS);
        }

Thank you for your explanation. I suspected that most likely it would not be possible to catch the moment of the beginning of Undo/Redo. Sad...

So if to consider your advice:...
@manuel said in Get ID of Undo-ed parameter...?:

You can either update all your objects based on the new data or check all your structure and check if it needs any updates.

...if I want to call update function in MSG_DOCUMENTINFO_TYPE_UNDO, so how to retrieve the correct object which have been updated here? (it should be my node). As I think I do not need make update in situations when Undo was made for another objects in the scene.

And also I did not understand the second part in the quote. What the structure should I check? Structure of parameters of my node? Or structure of objects? And how to check that they need any updates?

Hi Manuel.
I have a pretty complex structure when not only the slider parameter but also the SplineData parameter of my plugin controls an array of objects (its radiuses, positions, etc).
So I need to use doc->StartUndo() every for-cycle loop for each object in the array. During animation it gets me the error in doc->StartUndo() line, in AddUndo() line, EndUndo() and sometimes causes a crash.
Also I don't need to create the Undo each frame during the animation (when parameter is changed by animation key). I need to create Undo only once - when the user interacts with the parameter(s).

According to your code snippet above. Is the way somehow to achieve this:

1. at the start of Undo/Redo call by user, BEFORE the previous/next version of the node was copied to the scene, somehow to compare the current values of parameters with the values from a copied node-version.
2. store the parameters for which we find the difference
3. at the end of Undo/Redo call by user, AFTER the previous/next version of the node was copied to the scene, send the message to a node with the exact parameter-ID
   ?

the message like this:

DescriptionPostSetValue dc;
DescID distrID = DescID(DescLevel(1140, CUSTOMDATATYPE_SPLINE, op->GetType()));
dc.descid = &distrID;
op->Message(MSG_DESCRIPTION_POSTSETPARAMETER, (void*)&dc);

thank you

C++

Hello.
(very simplified explanation of what my plugin performs )
My ObjectData plugin has some slider parameter ("myParameter") which controls the radius parameter of some sphere.
When the user changes myParameter, MSG_DESCRIPTION_POSTSETPARAMETER catches the message of its ID and calls the function void modifySphereRadius().
(in reality there are lot of "myParameters", "objects" and "modifyObjFunc()"s in my plugin).

At this step everything works fine.

Now I want to make a proper Undo/Redo operation.
I don't want to add AddUndo() operation (doc->AddUndo(UNDOTYPE::CHANGE, mySphere);) inside to my modifySphereRadius() function. It causes the problems during running animation (when myParameter is animated) etc.

So, what I've think, that it would be good to call my modifySphereRadius() function only when myParameter value is restored from the Undo.

Is the way to achieve this?

When the user changes myParameter, the C4D creates the undo-version of my node. And when the user calls Undo action, the old myParameter value of my node is restored.

BUT what I've found that no corresponding messages in the MSG_DESCRIPTION_POSTSETPARAMETER for the myParameter ID was sent.

Is the way to catch the message for the exact parameter ID after it was restored when user called Undo/Redo?

Ok, so it looks like I should to give up of using ParallelFor for InExData. Because it is most expensive part and using ParallelFor for all other parts of code does not speed things up.

And actually as I understand it is pretty logical.
I have 2 InExData parameters in my plugin. So when I copying 3000 items into 2 InExData`s, plus adding 3000 objects into the scene, then the number of operations increases up to 9 000.

And the result for the 3000 objects adding to the scene but with no InExData->InsertObject()

Starting Alloc()...133894.367
Starting ParalelFor...133894.477
Starting Insert()...133894.542
Ending Insert()...133894.551