Scope of "Restart Layout" ?

I got in a muddle. Can a kindly person clarify the precise nature of "Restart Layout" for me, please?

So when within a layout that:

1) has an "Includes" definition referencing an event sheet with globals and global constants an events with instance variables;

2) has global constants;

3) has global variables;

4) has events with instance variables (and is deterministic such that multiples new instances of things will be created, meaning even more instances if the previous processing of the layout leaves it old stuff behind to whatever degree);

Which of these categories/subcategories will be affected/changed/reset?

I'm actually worse off for the simplifications in this case: please give me the real deal.

Thanks folks.

From the manual:

Restart layout

Restart the current layout. Note that unlike Go to layout, this action resets all event groups to their initial activation state. Global variables keep their current value - they are not reset. To reset them use the system action Reset global variables.

So global variables will be kept at their current state

All things not global will re-initiate..

I read the manual.

All globals, or just the ones initialised in the layout being restarted? Does this include globals initialised in 'included' event sheets?

I thought this was very clear:

Global variables keep their current value - they are not reset. To reset them use the system action Reset global variables.

If you have an event that on start of layout changes global variables, that event will be run because of the restart of the layout..

Global means that they are reachable from every eventsheet, so it doesn't make a difference on which event sheet they are..

Thanks for the additional info. I'm not asking this out of total inefficacy; but because my muddle indicates that there might be some fringe cases where these obvious/stated/implied aspect of restart layout are contradicted. I need to check it's not me screwing something up, and yet fully expect to find that is.

So the other things I need to check-

What of the local variables for events on the layout being restarted; and for layouts included?

Argh, my issue is a result of code required to mitigate the bugs with Touch object. One has to code manually to debounce it (necessarily using a global variable) or touch-triggered events are triggered multiple times.

For the case where I want to restart a layout (new game) I can debounce in a diff way, using button UI visability (this isn't always possible when managing touch events using multiple instances of identical sprites).

However this has revealed to me that what I'd really like is a new variable scope: layout variable. Or at the very least, to be able to set local variables for root events instead of globals.

There's no method to create a new instance of a layout; only a reset. This means one is almost always going to require a global variable reset to achieve a meaningful reset of the layout. So for the common situation where you need certain values to persist that can't be implemented as constants before the user makes choices (eg, number of players) one will have to use a data dictionary or something. I mean that's fine, but a) one won't know this at the design stage and b) its very inelegant, and begs the question, "why not use a data dictionary for everything that needs to persist?"

Not only that, but the likelihood that you'll need to reset global variables in order to meaningfully achieve a layout reset means that other layouts are necessarily affected, further forcing me to use a data dictionary for anything I need to persist. Surely that can't be considered optimal at any stage, design, code or run time?

This status quo implies the following issue I don't even have a solution for: how do allow a player to back out from a game into a menu, then start a new game? I can only code for a 'go to layout' action from the menu, which gives no option to reset the old state; and there's no event for 'on layout changed' to use as a basis for triggering a reset.

It seems to me that I am currently forced to manually include data dictionary storage and instance management for pretty much every aspect of every layout I might ever need to reset the state of. Please tell me this is not the case and I am a lunatic!

Maybe the persist behaviour can help?

https://www.scirra.com/manual/161/persist

It makes the situation a bit less inconvenient for certain types of object. It doesn't affect the architectural issue as a whole (I don't think - but I'm new!).

By reading your previous message, you may be doing a lot of unnecessary work on start of your layout.

But on the other hand, as you never precisely state what you are actually trying to achieve, you throw assessments about touch plugin and variables is all.

Try to describe precisely what you are trying to achieve, post a capx of what your code currently looks like, explain what you expect from this code, and finally tell us what exactly you see happening when executing your project.

From there, it will be easier for us to explain further on or to provide alternate solutions more in par with C2's ways.

Ah, a core issue here is - now knowing - that 'goto layout' creates a new instance of it; it doesn't return to the 'old' one.