Sequence of execution onStartLayout across include sheets

Hi,

To better structure the code of the game, I am using include event sheets extensively. I have one include event sheet that includes all other event sheets, and that is included in all other layout event sheets. Like this if i want to add event/action behavior across all game layouts in can do so by creating a new "include" event sheet.

E.g.

Layout1-Events sheet includes IncludeInAllEventSheets-Events.

IncludeAllEventSheets-Event includes

-includeEventSheet1

-IncludeEventSheet2

-includeEventSheet3

etc.

Now, my question. If I have an onStartLayout trigger in event sheet 1 and event sheet 2 and event sheet 3 and in Layout1-Events, can I assume that the order in which the onStartLayout will be triggered will be according to the include event sheet sequence?

thanks,

Dan

p.s. If no order can be guaranteed, then I would suggest adding a priority/sequence attribute to each Event trigger, which ensures that same triggers are ordered in the event queue. In essence turning them into "nested" events as it were

One approach I am trying now to overcome this is to turn all onStartLayout code segments into Functions, and then have only one onStartLayout that calls all functions.,

I think the order is guaranted (aka : read your main event sheet in the good order, if you come across an include when you are reading, read that included then come back), but I am not sure if I actually tested this or if I considered true by default.

Included event sheets are always read first, regardless of where the Include event sheet code is used in the event sheet. They are, however, read in the order that they're called in the "parent" event sheet, so there is certainty that can be relied upon.

Thanks,

What about triggers, such as on start layout triggers are they processed in sequence too.

In one implementation I had included a second condition to each on start layout, such as layoutState=1, layoutState=2

like this i tried to ensure that on start layout in a base sheet is only triggered after an on start layout in an include sheet, but this requires a kind of "stickiness" of triggers: the trigger later needs to "wait" until the second condition is true and then fire. But i wasnt sure if this really worked consistently (it seemed to have worked though, i just wasnt sure if its guaranteed, or a fluke).

On start triggers are processed in that order. So if you have On start events in your included event sheet and your parent sheet, it'll first run in the included sheet, then the parent sheet. If an action in your parent sheet is dependent on something happening first in your included sheet, it should work fine in this case.

I use this principle when creating a game that has multiple levels that share one common event sheet but each have their own sheet for special circumstances (in a puzzle game, for example): I can be sure that anything that's set both in the common sheet and in the unique sheet will be overwritten by the unique sheet if necessary.

Included event sheets are always read first, regardless of where the Include event sheet code is used in the event sheet. They are, however, read in the order that they're called in the "parent" event sheet, so there is certainty that can be relied upon.

GeometriX grossd

I've done a quick test, and it seems that it is as Geometrix said for the On start of layout (maybe also for every trigger condition), but not in case of a every tick, where the positionning of the include is of importance.

Aphrodite, ooh, that's very interesting. Thanks for doing such a conclusive test. Now that I think about it, I'm sure that inconsistency has caused me problems in the past!

Thanks for testing — Do you think you could provide a link to the project file ... But, thinking theoretically, its hard to conclusively prove with test cases.

I am trying to instead use call backs and varying secondary conditions (states) to order sequences independent of the layout include sequence; and for critical items I currently duplicate them in the "parent" layout ... (for example for processing that has to happen on end layout)

Thanks for testing — Do you think you could provide a link to the project file ... But, thinking theoretically, its hard to conclusively prove with test cases.

I am trying to instead use call backs and varying secondary conditions (states) to order sequences independent of the layout include sequence; and for critical items I currently duplicate them in the "parent" layout ... (for example for processing that has to happen on end layout)

Have fun : https://dl.dropboxusercontent.com/u/100 ... ering.capx

Also as an advice, I personnaly try to never use any actions or conditions in the Main sheet, and the only times I do, I don't use triggers, but rather variable comparaison and such (which generally serves the purpose of reducing the nuber of included sheets depending on some values), so I've never encountered this problem, it seems to only affect triggers (maybe a bug report could be done since it goes a little counter-intuitive wise, not that it would be corrected, but just to have a trace of this for the future..).

GeometriX

grossd