That was it, some of them at some point were placed into an effects layer. Sorry for all of the confusion, I honestly don't know how they got in there. And thank you.

I can confirm that this also happens with sprite objects, and also with the Sprite's Spawn another object action.

Thanks, that got it working.

As far as I can tell, this seems to be a bug with Construct. I made a test project to see if it'll still happen there and these are my results:

The layout:

The event sheet:

The result:

According to the debug, there are only 3 of the red tiled background objects during runtime, meaning the fourth one that should've been created from the event sheet isn't there.

Am I supposed to report this somewhere?

Small correction: I said that the Vines positions are set, but I actually meant their size.

I have a simple case where I have a tiled background object (ProjectileField) that spawns another tiled background object (Vines) in a different layer than itself.

However, instead of picking the newly spawned Vines object and setting only its angle and position, it picks all of the other Vines already in the layout and sets all of their angles and positions. This only happens when I use a function to determine the correct layer to spawn it in. If I set the spawn layer to 1 (which is disabled in the screenshot) the picking works perfectly fine. Am I not allowed to use a function there? What am I doing wrong?

Maybe useful added context:

- The ProjectileFields are already in the layout, some spawn Vines, others don't.

- I used a text object to see how many Vines are picked immediately after the Create action, the result is "-27-1-1-1-1..." meaning that 27 are picked the first time the ProjectileField On Created block runs, and then only 1 after that.

Found this completely by accident, and only knew it wasn't on that page because I was looking for a shortcut like this for my current project.

That said, I'd completely understand if this is hidden just to avoid people accidentally using it to Back/Forward on their webpage.

Thanks for the reply. Didn't know the performance impact would be minimal, which was my big worry.

My plan for implementing parallel realities is simply to have the two levels overlapping in a single layout and switch the visibility and collision of each as the player switches from one reality to another, probably through a placed portal.

I want my game to run on any regular browser but I'm worried that essentially having two levels on the screen at the same time may cost too much memory, or something.

I'm sure just having a layout for each dimension would be simpler and less resource-intensive, but I want the dimension-switching to be as fast as possible.

Anyways, my question is: is this approach too much, or is there a better one that is still very fast?