New Event Sheet Feature: Gated Sections

Hi Ashley,

I notice that a lot of my code is temporal in nature -- events that happen before or after certain conditions hold, and actions that should only happen after certain events occurred, like state machines.

I think a useful advanced (or perhaps not so advanced) feature would be to have gated sections in an event sheet. Each gates section would have a condition expression that must be true for all events in the section to trigger. It may also be possible to include event sheets into a gated section, which would mean that all events in the event sheet would only fire when the gated conditions are also met.

Like this the event sheet could have a section that is activated when the layout started, and a section that is activated when, say, the player is on low food, which is, say, an important state in the game. Etc. There could also be subsections, which add selected pre-conditions.

I think this can already be implemented with Groups while playing with activation conditions of groups in seperate event expressions. But, it would be nice to have this "out of the box"

Perhaps a simple "syntactic sugar" implementation would be to support conditions on Groups to activate or deactive them.

In a way an event sheet would then be turned into a (hierarchical) state machine in chart form.

what do you think,

Dan

If I understand correctly what you are saying, you are asking for the events to work as they already do.

An event sheets is read from top to bottom, and for each event, all the conditions must be true for the action and subevents to be executed/tested in turn.

You can add include as an indented sub-event, so it will only include another event sheet if the conditions of the top level event are true.

Finally, indeed you can work your way out with activating/deactivating group, and I don't really see how else you could make it but by allowing the user to make events that are tailored for the current project she's making.

How more "out of the box" would you see/want it to be ?

I think you are right.

With sub-events this can be done quite nicely ...

I wonder, if there is value to allow structuring more visually with Groups and activation condition of groups.

Dan

Grouping your events and activating/disabling them sounds like exactly what you're after.

Yes.

Now i have code like so:

on start layout => Activate Group "Group1"

condition ^ once => Deactivate Group "Group1"

So, a group of events/actions included in Group 1, are only active from the beginning of the layout until a condition holds.

I think it would be nice if an activate or deactivate condition could be entered in the group itself. Right now, the only condition available is active when layout starts.

Dan

Yes.

Now i have code like so:

on start layout => Activate Group "Group1"

condition ^ once => Deactivate Group "Group1"

So, a group of events/actions included in Group 1, are only active from the beginning of the layout until a condition holds.

I think it would be nice if an activate or deactivate condition could be entered in the group itself. Right now, the only condition available is active when layout starts.

Dan

you can set the group inactive by default

Yes.

Now i have code like so:

on start layout => Activate Group "Group1"

condition ^ once => Deactivate Group "Group1"

So, a group of events/actions included in Group 1, are only active from the beginning of the layout until a condition holds.

I think it would be nice if an activate or deactivate condition could be entered in the group itself. Right now, the only condition available is active when layout starts.

Dan

IIRC, you can also include an event sheet under a condition, which means it will be read only when the condition is met, not sure however how that works with triggers. That may help you organise things a little.

Thanks codah,

However, in my game the user can return to a layout, and after testing, it seems that unless i reset the layout (with a reset action), the state of the group is "global" and remains as it was when the layout was left. Because of this i can't rely on the

Why would you want to activate/deactivate a group instead of just putting all those events as sub-events under 'start of layout'?

With a group you separate the events from their cause of running, and they also become delayed in time: they don't run at the same time as the 'start of layout' trigger, probably just the next tick afterwards, which can cause confusing sequencing issues. I'd definitely prefer subevents.

Thanks Ashley for the additional information.

In my quiz game I have in each layout "temporal" states, such as "before Quiz starts", "Quiz running", "Quiz Cue 1 Given", "Quiz succeeded" ...

I want to ensure, for example, that when the success event is detected, and hence, Quiz succeeded state is entered, no more cuing occurs. cuing is a counter (with its own states), that runs in parallel.

At the same time I want to separate out code snipplets that deal with different concerns -- hence modularize the code. I don't want for example the cuing timers to know about game states.

So best, if i can place (call back) function that the cuing code calls into a "Gated sheet section" where it can only be invoked when CurrentState<>Success.

Similarly, I would want cuing timers only to run when the game entered the "Running State", and not before -- so they may have their own states that are activated via the main game layout states.

So, all this can be done currently, but i think it would be cleaner if there are designated "sections", each with their "entry condition"

Dan

As far as I can tell, sub-events to exactly what you describe already. Sub-events are "gated" by the truth of their parent events.

You may also be interested in looking in to functions to improve the modularity of your events.

Thanks,

I haven't thought about subevents as gated states, but its a good idea and I will try it out, to see if this is what I was looking for.

Indeed i am using functions a lot, and also like it that functions can have different "versions", based on the conditions attached to them. This makes functions very powerful in C2.

The best thing about functions is that they can be almost completely modular; this really saves time because you can move such functions between projects effortlessly.

I used to use groups as pseduo-functions, but if you activate/deactivate a group at a point in the event sheet that is after the group itself, you have to wait till next tick for the change to take effect. This can really throw things. With functions, you can called them and get data back immediately. Now I tend to use groups more for organization, debugging (finer-grain cpu readings), or for turning large chunks of code on/off.

Ashley grossd

i think groups could improve by using toggle "current" group,

if you copy it, change the group name and your done

and it could also function as a run group once

i like to use them for a processes that i want to run for a period of time

i then start check for events that autoclose the process/group

an added bonus, is that you can easy see how "heavy" the process is in debug

i also made a custom function to toggle multiple groups,

ex: if file loaded, function toggle ('fileload","maineventloop") .. to chain groups

nice, thanks.