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());

Hello Ilia.
Thank you for you answer.
As I mentioned in the very first message
@yaya said in New Simulation system: the Compound Collision Shape is no longer available?:

There is only a "Hierarchy merge level" option, which does not do the same.

Just try this workflow from your video but with the OJoint and not with the Clone object.
For some reason it works with the Clone object but with Joint it does not. The tag does not consider the child of joint as an object for physics calculation at all. I've added the project-file in my first message to show it.

And it is pretty strange. Because I was thinking in the same manner as you: that it will be easy, just to need use the workflow like you show.

Hello @i_mazlov ,
As I mentioned, as a developer I am trying to provide to users the option of newly added Simulation system to use it in the my ragdoll plugin. Ideally, I want to use the new trigidbody tag in my code the same way as I use the old Bullet Dynamic Body now.
But I can't understand how to do instead of this:

BaseTag* const DBtag = BaseTag::Alloc(180000102); 
DBtag->SetParameter(ConstDescID(DescLevel(RIGID_BODY_SHAPE)), 11, DESCFLAGS_SET::NONE); 

this:

BaseTag* const DBtag = BaseTag::Alloc(trigidbody); 
DBtag->SetParameter(ConstDescID(DescLevel(???)), ???, DESCFLAGS_SET::NONE); 

As I mentioned above, for a ragdoll I need a compound collision shape. Where the top of a hierarchy is a joint object and it owns the trigidbody tag. The second level of a hierarchy is the child mesh object - it represents the shape of the joint. In the settings of trigidbody tag I want to set it as a Compound collision shape. And then connect these nodes via Connectors to create the ragdoll structure.
So my question is:

1. is my desires are possible on this stage of provided simulation engine?
2. if it does not, then is it in plans to add it in the near future? Because this option already exists in old Bullet tag.

Is it something too complicated what I am asking?

I am trying to use the new Rigid body tag to create ragdolls. My plugin was using the old Bullet Dynamic body tag for this task. And it worked well. But now after new Simulation system has been presented clients start asking about using GPU for ragdolls, which should be much faster.
Also new Simulation System was added the possibility when a Connector object has became to be able to connect two objects under a new SimSystem. And even in the Ragdoll mode.
So it is pretty logical to use new physics to create ragdolls. And even the crowd of ragdolls which with old bullet physics worked slow due its known limitation. So the new Simulation system potentially could be a salvation

And I was thinking it will require just to replace the old Bullet Dynamic body tag to a new Rigid body tag.
But what I've found - there is not option in new system to use the Rigid body tag with the compound collision shapes anymore. There is only a "Hierarchy merge level" option, which does not do the same.
Am I right? It is not possible to use the new RB-tag for compound shapes?
Old bullet tag worked in a way when I: 1) put DB-tag on a Joint object, 2) added the mesh collider shape under the Joint as its child and 3) set DB-tag as a Compound collision shape to consider joint and its child as a physical object.

A new Simulation System does not allow this workflow anymore? Is this a missing feature?
Or if there is a some way I can code it to achieve the desired result, then how to do this?

Hello @ferdinand
I've found that if I create the connector via the code above, I can fix the problem with the itemtree/inexdata and joint settings (reference_axis parameter) successfully.

But by testing it, I've found another issue.
As I mentioned in my first message, instead of the legacy FORCE_TYPE DescID now there are two DescIDs: FORCE_TYPE_GROUP and FORCE_TYPE_MODE.
And if I am trying to set the Connector mode by them, then after the creation of the Connector the "Type" and the "Mode" of the Connector object are selected correctly, but in the viewport they are not.
F.e. I do this:

    connector->SetParameter(ConstDescID(DescLevel(FORCE_TYPE_GROUP)), 3, DESCFLAGS_SET::NONE);
    connector->SetParameter(ConstDescID(DescLevel(FORCE_TYPE_MODE)), 3, DESCFLAGS_SET::NONE);

Here I am trying to create the Connector in the Ragdoll mode.
But in the viewport I see the mode as the "Ball and Socket" mode. And it works if I hit Play as a Ball and Socket.
But in the parameters section it is selected correctly: type=Spherical, mode=Ragdoll.

So, I've found this problem and then I've decided to use the old FORCE_TYPE instead of new FORCE_TYPE_GROUP and FORCE_TYPE_MODE:

connector->SetParameter(ConstDescID(DescLevel(FORCE_TYPE)), 3, DESCFLAGS_SET::NONE);

And in this case the created Connector become in the correct Ragdoll mode.

Actually it is what I need. And it works for all other modes.
...Except for a "Fixed".
The old "Fixed" mode was under the int number = 6.
The new Fixed is equal to 0.
Anyway I've found the way to fix it in my plugin. But it requires to add another new if-statements (#if API_VERSION >= 2024500) in all places where the Fixed connectors should be used .

I do not know is it a bug or feature, just will leave it here to get back in 2 years and remember why I've added all that #ifs in my code

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);
        }