Changing Layout will create objects on the next layout

I came across this issue I was having again, after noticing it over a year ago: request-destroy-all-sprites-action_t80832

I think sprites are created (every browser/node) when changing layout. This means sprites are created on the next layout you go to. What's the logic you're using when you use the "go to layout" action? Because the way it seems to be working for me is this: When it gets the event "go to layout" all instances are destroyed, then it continues to run the rest of the sheet (or just the triggers?), if you had any "on destroyed" events or "create object" actions that were going to run that that tick then they'll be created — but on the next layout.

This causes issues for me, you can see here that after "go to blank layout" it has some newly created sprites? The layout should be completely black, but it's not, it has objects that were created from the previous layout:

This also seems to cause issues when I return to the layout:

Nodewebkit:

Chrome:

Firefox:

I originally thought that objects were simply lingering from layout to layout, but since realizing that they were most likely newly created I then tried disabling a group that was creating most of these objects before I used the go to layout action:

Disabling that group, which I use to mostly create things, seems to have solved the issue of objects from one layout moving to another layout and I now get a nice black screen when going to my blank layout. It also removed the above errors from occurring.

____________________________________________

Summary:

Objects are probably destroyed by the "go to layout" action is performed but then events that use "on destroyed" are still run afterwards. This should not be the case as it means objects will be created on the next layout you go to.

Here is a CAPX: https://copy.com/gRmijhp1JWJb7Qkz/bug_c ... download=1

You'll notice that after 2 seconds, it will change to a black blank layout, and an object from the previous layout will be on the next layout (when it shouldn't be there).

I'm guessing this is something like what you're currently doing for the tick?:

• Change layout action is noticed
• Automatically destroy every object
• Layout is changed
• Continue running the event sheet for that tick (which may include creating objects, that are then placed on the new layout)

It doesn't sound like that's the way it would work but it sure seems to happen in the example.

To drive it home, disable event 1. Where all blocks are destroyed, one is created.

Work around is to put a destroy in "on start of layout"

(which, now that I think about it, I seem to remember doing with Chicks on Trampolines...)

Thanks for confirming that it's not just me!

I think I'll just wait for the fix, bug workarounds end up making things messy in a large project.

the "on destroyed" is a trigger, it will fire when the instances are destroyed, this happens just before the layout ends (so using an "on end of layout:destroy" may work), IIRC it has already been reported but was closed as wontfix, but that could change.

other workaround that is cleaner:having a variable that changes just before you ask for a layout change, the value of the variable influencing if the "on destroyed" will work.

Still hoping for a definite fix.

IIRC it has already been reported but was closed as wontfix

That's a bit odd?

Currently for me a it's a game breaking bug, on none of my event sheets have I told it to create objects on a different layout, but it's doing it anyway.

I reported it before and it's come up a couple of times since then but it's working as intended.

Thanks for showing that closed report, I still desire an understanding of the logic though. To me it doesn't seem right to still create objects on the next layout, as I never told it to do that.

To me the best way would be to finish running the event sheet (which includes finishing the trigger events, so basically stopping the sheet) THEN destroy all objects and change layout.

To me the best way would be to finish running the event sheet (which includes finishing the trigger events, so basically stopping the sheet) THEN destroy all objects and change layout.

Definately makes sense to me as well.

Since it is not classed as a bug, maybe it would make a good feature request.....

Have you tried adding wait(0) before changing layout ?

To me the best way would be to finish running the event sheet (which includes finishing the trigger events, so basically stopping the sheet) THEN destroy all objects and change layout.

It already does that, but destroying objects just before changing layout still triggers 'On destroyed' for those instances (since they're being destroyed by the engine). Triggers still work normally in this case and then you end up creating a new object halfway through the engine's process of switching layout. This is a really awkward time to create a new instance. If the engine then destroyed that instance again, then it risks firing another trigger which creates another instance which the engine then also needs to destroy, creating an infinite loop and hanging (this is what my reply to the other linked bug report was getting at). So it doesn't try, it just destroys everything then switches layout, and if any new objects were created they end up on the next layout.

The workaround should be simple: in the 'go to layout' action set a flag to disable the creation of new objects in 'on destroyed' triggers.

I can't reproduce the "drawing instance on wrong layer" error in the .capx you provided, so I have not attempted to investigate that. Please file a new report with a .capx that reproduces that particular issue if you want me to have a look at that.

Thanks for the reply!

Ashley I still don't understand why the engine still allows those triggers to be run when they should be stopped though?

I didn't even know what was happening when I experienced this bug, since it's been in every game I've made so far I'd always just expected that you should never change layout if possible because weird stuff happens, thankfully I realized the exact details and I hope other users will be able to stumble upon one of these posts in the future so they don't have to suffer too.

— I think that, internally, layouts do not exists like we think they do, so " change layout" is basically just destroying the objects that are not global, destroy the layers, changing the LayoutName value, change the event sheet (already too late), creating the new layers, creating the new objects, apply the on start of layout.

could be wrong though.

still thinkiing that a internal flag verifying that this transition is not happening could be nice to have, but maybe it would be bad regarding general object destruction perfs wise.

Finally found this thread to help me fix this issue. I'm going to post this in feature requests, but I think we should have a "Remove object" feature, and also have the layout "remove" objects on layout change rather than "destroy." (Because destroying triggers "On destroy" effects... I think it's obvious that unwanted effects will occur here.) That would have saved me about 4 hours.

— I agree, it's still unfathomable to me that this isn't considered a bug. Creating objects on a layout you never told it to create to is considered "working as intended".

I still don't understand why the engine still allows those triggers to be run when they should be stopped though?

Go to layout

Go to layout (by name)

Switch to another layout in the project. Note that global variables keep their current value - they are not reset. To reset them use the system action Reset global variables.

FWIW, in the manual it is also not described to work that way. (stopping triggers from firing)

I would stuff those triggers in a group which get disabled before the change layout action, and enabled on start of the next layout.