Now well Ashy,
sorry to disappoint you, sorry to sound disappoint.
But in my eyes, its not a bug, not even an error.
Its a inevitable result of the way the events editor is organised.
Its organised from your perspective, from the inside out.
The constructor (the person who constructs in construct) looks outside in.
I would like the events editor to reflect the following in syntax, work flow and especially in the limiting of combinations.
*events
the detectors of situations. they general start with "on". so i will refer to them as "on's" too.
- keyboard events (on key pressed)
- system events (on object out of view)
- object events (on end of animation)
- step events (on always)
- plug in events (on step - bullet)
- mouse events (on left click)
- timeline events (on start layout)
*conditions
conditions are always paired up with events. They decide to run the actions/loops in the current event or to skip to the next event.
they are the "when's"
- object related (when on layer (x), when visible)
- system related
- plug in related (when gravity is lower the (x) )
Conditions are as general as possible. Because the object is picked in the event already.
Conditions are meant to speed up things by detecting conditons met/not met, before the system looks into the actions/loops.
Another reason why conditions need to be as general as possible and handle as less code as possible.
*comparing
the "if's"
-object related (if objects local variable = true)
-system related (if global variable is true)
- plug in related (if variable x in behavior y is true)
*loops
*and actions the "do's"
At the moment u find if's and when's and on's every where and not organised and overlook able in an easy way.
At the moment u can combine if's with when's, leading not working constructions
At the moment u can when's combine with loops, and the when's pick objects, disturbing the object pickings in the loops
At the moment u can combine if's with events, and the if's disturb the object pickings of the events
really don't sound familiar ?
now to go a little deeper in the concept of an event.
Events you can visualize by:
A fisherman trowing his fish line in the water. Waiting for a snap on the line. As sign that there is something on the hook.
He then pulls the line up, examines whats on the hook, and decided to keep it or not. He will keep a good fish, and trow back a bad fish.
And that's all. To bring this to construct.
In general, an event is meant to detect the situation defined in its event line. It should then record the Info about what happened in an easy accessible way.
Accessible by the conditions (the when's) , the actions (the do's) and the loops
More specific. Lets bring this to the collisions detection events.
""on object collisions detected""
lets assume it returns 'true' and the execution is now passing to the condition ..
but where is the info to feed the condition with ? Especially when its about instances created on run time. They can be anywhere and be anything.
It could be easy though (and not only for conditions).
just let the event make a faceless family object containing all the objects involved at the moment of detection.
Faceless, similar to the keyboard object, the system object ......
Now when constructing the conditions, the actions and the loops all you have to do is what you always do. This object can be read-out as every other object.
It cant be more elegant and construct alike ... especially in dealing with objects created on run time.
Now ashy, give me permission to answer all the nasty kiddie comments. plz ?
ty ?