Sprite objects from differents scenes in a global group : unable to use sprites related actions in editor

[KinkGD]

Hi !

New fresh issue spotted while working with global group and sprites objects:

when using a global group wich contains sprite objects from differents scenes, it's impossible to use sprites related actions with the global group. Sprites related actions are missing in actions list (using old or new editors). If trying to use the name directly in the parameter of the action, there is an error "The object does not exist or can't be used here".

Here is an example to help to reproduce the issue (just try to change tint on scene 1 by using global group name as object name): My project34.zip

To reproduce the bug from scratch: 1) create 2 scenes and add different sprites objects on each scene 2) create a global group, and add the sprite objects from the two scenes inside the global group 3) on one scene, try for example to change the tint of the objects by using the global group name => sprite actions will miss from the list.

On contrary: if the global group contains sprite objects from only one scene, sprites related actions are available.

[4ian]

I see, this is because when GDevelop handles the groups, it looks "ok what are the objects inside this group, so I can know what kind of group it is (a group of sprite, a group of texts, or a group of any kind of object?)" When it see an object that does not exist in the scene, it's like "jeez, I can't find this object in the scene or in global objects at all, so I'll assume it's a base object without any specific type (not a sprite, not a text, nothing, just an object)" so it ends up considering the group "has a sprite, another sprite, and an object without a type", so it ends up deciding "then this group is a group of object without any kind of specific object. So don't dare using a Sprite related action on it!".

We might change this behavior to : if the object is not found, just simply ignore it. Would need to check if this has any other good or bad consequences though.

[Bouh]

In the project, New Scene contains a Global Object groups, inside Gear and OrangeButton come from New scene2. If you remove Gear and OrangeButton of this global groups the action work (and the action in the generated code is done)

Otherwise with Gear and OrangeButton in this global group, the code generation fail to create the actions.

[4ian]

Note a workaround: you can create empty, almost useless objects called "Gear" and "OrangeButton" that are sprites in the first scene (and vice versa in the second scene). But it's more a "hack". Other workaround: make objects global?

[KinkGD]

i can't use these hacks ^^ btw i'm not stuck in my project by the issue because i can use different way for my aim.

To explain more the use case i was expecting when i discovered this limitation: I have potentially 50+ scenes and 150 objects to put inside the global group, wich might be used just to change sprite tint when the mouse cursor is over an object of the group on each scene.

From this point of view and the actual project i'm talking about, i see one really good consequence if this might be enhanced : using one global group and a couple of 2 actions (changing tint on mouse over and mouse out) in an external event to change tint on a lot of object on each scene. Furthermore it might be useful for all sprites related actions in external events, using global groups :)

I let you think about bad consequences on such changes (unworking actions if the object type is not compatible ?), it's out of my skills to determine if it might create bad side effects.

[Silver-Streak]

Just to chime in on this, I feel that a Global Group really shouldn't require global objects to function in multiple scenes, otherwise you're somewhat limited the usefulness of external events (and global groups in general), not to mention you'll eventually make your object list unusable (Unless we eventually get the "tags as folders"/advanced filtering we've discussed elsewhere). While I don't know for sure, I'd also expect having so many global objects would eventually impact memory utilization in all scenes, correct?

I think the idea of "if these events don't apply to objects in a group, ignore them" could solve this issue. It could also allow users to have multiple types of object in the same group and simplify the creation of more advanced events, such as those used in my GUI Layer example.

I think this actually directly relates to the conversation we had around a year ago, here: https://forum.gdevelop-app.com/t/object-groups-containing-text-objects-no-longer-selectable-for-shadow-events-if-made-global/22635/

[4ian]

I think the solution would be to indeed ignore objects that can't be found in groups, and maybe have, as you mentioned in the linked thread, a way to force a group to be of a selected type. This would ensure that you can use it in events as the selected type, and if you try to put an object of another type, you'll get warned (and even if you do it, object would get ignored).

Would solve the issue of global groups having missing objects and would make groups more "error resilient".

[Silver-Streak]

Hmm...wouldn't forcing events to ignore missing/incompatible objects in Global Groups solve for both? Maybe I'm missing potential risks there.