Z Order are not applied correctly, even if they say they are.

[tbvns]

I'm back with a bug that makes absolutely no send (I'ts been 5h trying to fix this I want to die) but it seems like object placed with a custom ZOrder in the object string is not displayed properly: here is what I mean: Here is what I have with the mod: Here is what I should have: Note that the only thing I did was update the ZOrder in the game.

[tbvns]

I did not have this issue before, I think an update to GD caused the issue.

[iAndyHD3]

I just use higher level robtop functions, not much I can do I think. Anyway, it would be helpful if you provided

• Object string of the desired result objects with working z order
• Object string you used for the objects placed with the mod you can use get level string action

[tbvns]

ok, here is the bugged level: bugged.gmd.zip and here is the not bugged version (modified by hand): not bugged.gmd.zip Sorry for the .zip, GitHub wouldn't upload otherwise. Those are GDShare level

[tbvns]

And here are the json messages:

{
  "action": "ADD",
  "objects": "1,2903,174,0,202,1,456,1,208,0,508,0,25,6,209,0,2,0.0,3,300.0,57,10,203, 1,204, 2,205, 4,206,3,207,1,21,1,22,1"
}
{
  "action": "ADD",
  "objects": "1,2903,174,0,202,1,456,1,208,0,508,0,25,5,209,1,2,0.0,3,300.0,57,10,203, 5,204, 6,205, 8,206,7,207,1,21,2,22,2"
}

[tbvns]

the code to create it looks like that:

    public static void addGradient(Float posX, Float posY, Integer groupe, int p1, int p2 ,int p3, int p4, int id, int zorder, int colorID) {
        String JSON =
                "{\n" +
                        "  \"action\": \"ADD\",\n" +
                        "  \"objects\": \"1,2903,174,0,202,1,456,1,208,0,508,0,25," + zorder + ",209," + id + ",2," + posX + ",3," + posY + ",57," + groupe + ",203, " + p1 + ",204, " + p2 + ",205, " + p4 + ",206," + p3 + ",207,1,21," + colorID + ",22," + colorID + "\"\n" +
                        "}";
        request.add(JSON);
    }

then i call

        GDObject.addGradient(0f, 300f, 10, 1, 2, 3, 4, 0, 6, 1);
        GDObject.addGradient(0f, 300f, 10, 5, 6, 7, 8, 1, 5, 2);

[tbvns]

Any news ?

[iAndyHD3]

currently working to port the mod to 2.206. no plans to look on this, sorry

[tbvns]

currently working to port the mod to 2.206. no plans to look on this, sorry

No problem, I'll maybe suggest a new action soon about that tho, I'll come in a bit with the full concept

[tbvns]

Ok so, to fix this issue, I thought of doing an action that uses the same function as the UI, I don't know how geode works, but I think you can do that with it. The first issue with this was the ability to select which object was the target:

this would change the last object(s) placed by the mod (the last ADD action)

 {
    "action": "Zorder",
    "value": "some nuber",
    "last": "true"
 }

this would change the objects(s) at the said coordinate

 {
    "action": "Zorder",
    "value": "some nuber",
    "posX": "X",
    "posY": "Y"
 }

this would change the objects(s) on the said group(s)

 {
    "action": "Zorder",
    "value": "some nuber",
    "groupe": "some nuber"
 }

those could be used to select almost any object in the level if you can stack selector and would fix my issue.

Example of stacked request:

 {
    "action": "Zorder",
    "value": "some nuber",
    "last": "true",
    "posX": "X",
    "posY": "Y",
    "groupe": "some nuber"
 }

I hope you like my proposition, I think this model could be used for lots of other action like the REMOVE action or maybe even a SELECT action to select object in the editors. I'm also hoping that the port of this mod to 2.206 is doing well, but don't overwork yourself, it won't bring any good. I'm also learning c++ to help with development at some point, so I can stop asking and just submit a pull request.

[iAndyHD3]

Thanks for the proposal, the proposed solution is not what I have in mind, however a similar object filtering system is in the works to be added in the future, but I don't promise anything.

Please do not work on a pull request before I explicitly approve the design or changes to avoid waste of time and work

I will look at this issue after the 2.206 port is completed, it's currently taking longer because several functions used are now inlined