I would like to suggest some comsmetic "changes", mainly for flattening the "learning-curve"
A sprite is the grafical face of an object. At the moment it can be changed by changing the animation. (very powefull). But a sprite is not an object. The basename of an object is "sprite",
and it this "leakes" into the events sheet editor. Thats confusing.
There are 3 kinds of events. And the conditions you use (in practice) with those events are very specific.
There (1) are events that dont pick objects (system events, keyboard events ... ) Lets call them the "flow events" IN practice the conditions paired with those, dont filter in the "picked objects", or should not. Doing so makes no sense.
There (2) are events that "pick objects" and feed them to the actions. Conditions paired to those events filter in the "picked group", or should do so.
There (3) are loops. At the moment u can pair up any condiion with a loop, wich i think makes no sense, less u can show me differend.
I really think this should be reflected in the way the wizzard picks objects and in the way u add events and conditions to the sheet.
An example of a nonsense .cap u find here ..
https://dshop.diino.net/getafile/ANGZIZ ... /onzin.cap
This makes no sense, because u can start every blok events with whatever. I personal thnk every blok of events can only start with a "flow event".
You take this as " lowering the possibiltys". And that is not true. Its like ...
Driving conventions say: drive on the road ! Thats not "lowering of posibiltys" (probaly bad english), because there are roads enough. Just like your concept has roads enough.
Restrict the start of a new bloks of events to "flow events" sure take out some unexpected bugs, and lowers the changes for bugs. The caps will be better readable.
And maybe more importand, they say now: the sheet runs "top down".
Wich would mean that a "On mouseclick" dont work as an interrupted? Thats a question. But if the answer is "yes" then i have my doubts by the whole concept of the sheet. Does a mouse event, a keyboard event, a system-object based collision dedection and all those "interrupts" really have to wait for the next "tick" to be "in account" and to be executed ?
If you think this trough, then the only logical aproach is to start each new event blok with a "flow event" ... where "top down" is the mainway of running it, with exeptions to events that need a inmediatly interrupt, as mouse events do. Those last events can be placed everywhere in the sheet then, but can be executed inmediatly.
Hope you see what i mean.
Ty fro reading.