New Condition to Select All Objects on a specific Layer

Guys, I identified a problem with some layers of my game, and I only noticed it after a while. But I decided to post an example here for those who know in the future this request will come true.

When working with several layers, and they are not visible, it would be interesting for the player not to have collision with them.

For example, I have two layers, a normal platform on the base layer, and another platform on a layer above. Only if that layer above is visible could I access it. something that currently doesn’t happen.

I created an example

This would be interesting for those who (like me) work with several menus in the game that are in several layers.

While I would wait to see if any contributors chime in to confirm since I’m going off memory:

I believe this is by design, and recent conversations reiterate that layers are explicitly designed to be visual only, and not logic impacting.

As an interim workaround:

Add your platforms to an object group.
Add a for each event for that group
Add a condition check for if the platform behavior for that group is enabled
Then check the visibility of that layer group (ObjectGroupName.Layer() expression will help here)
Then disable the platform layer.

Do the inverse if the layer is visible.

1 Like

That’s exactly or almost what I do, my problem has already been solved, with ID variable in some objects. But the fact is that if the layer isn’t visible the objects on it wouldn’t be either, so “is visible” should work!

Yeah. Sadly Object visibility and Layer visibility flags are not linked by design.

I thought this a bug a few months back and submitted it. You can read more about it here: Show or Hide layer does not show or hide objects from that layer for Conditions · Issue #2883 · 4ian/GDevelop · GitHub

The resulting workaround above was my solution after that github issue. There was supposed to be a new description added to make this more clear, but it doesn’t look like that was added to the actions/conditions themselves.

Wow, what a pity, that would result in a better use of the layers. If they were like groups and everything in them was linked, that would be cool. Thinking like that, there should be a way to create a group for the layers, and everything that was in that group would have global action (for that layer)

I agree.

With that known, maybe the better request in this case would be for a “Pick all objects on layername Layer” condition?

Then it becomes easier to not have to make manual groups or manually adjust them?

Yes, exactly! Creating a layer and attaching groups or objects to that layer could help.

For example:
I created a layer called LBag, it could have an option that we could attach objects or groups to this layer and everything on that layer could have an action, like “Take Into Account Linked objects!”

If you are good with that idea, I can update the thread title to match that.

If you want to change the title, go ahead. I can think about what I can do, whoever has ideas could contribute here too!

I’ve updated the topic subject.

If/when a contributor can take a look at this, I think the general request would be to have a “Pick all objects on LayerName” condition, or something similar to add all objects on a specific layer to the current object list of an event.

From what I can see, objects already have an attribute storing which layer they’re on in the exported source code, so I’d think this is feasible? This would allow for a lot less clunky control over things like what Willianholtz is trying to accomplish, as well as simplify handling GUI objects in many cases without having to manually make object groups.

1 Like

Wouldn’t it be interesting to put this up for discussion on github? This is an idea we could take forward and it’s a big step for GDevelop. I don’t know much about the javascript language, let alone how this function is in the IDE’s source code, but I believe that this would not be something difficult to do, it may be a long-term thing, but being able to control objects through the layer would save a lot of time, variables and lines of code.

Github discussions have been described to me as primarily being for technical implementation questions/best paths forward.

The technical implementation for this is already feasible from what I can see, it’s a question of whether it’d be implemented or not.

1 Like