Implement "on Mouse over" and "on Mouse out"

Currently, these are the available triggers:

On object Clicked:

You get to choose "Left", "Middle" or "Right".

You get to choose "Clicked" or "Double-clicked".

You get to choose the Object to click on as opposed to "On click".

Cursor is over object:

This will trigger continuously when you are over a specific object.

On mouse wheel:

You get to choose "down" or "up".

One time trigger unless you keep on scrolling.

Mouse button is down:

You get to choose "Left", "Middle" or "Right".

This will trigger continuously until that specific mouse button is no longer down.

On any click:

Trigger once, on any click.

On click:

You get to choose "Left", "Middle" or "Right".

You get to choose "Clicked" or "Double-clicked".

But you don't get to choose which object to double click on.

You have to use "On object Clicked" for that.

On button released:

You get to choose "Left", "Middle" or "Right".

Trigger once.

==================================================

Feature request:

"on Mouse over":

Trigger once only the minute mouse is over a specific object, very common usage in Flash.

As opposed to "Cursor is over object" which trigger continuously.

"on Mouse out":

Yap, no explanations needed.

I understand that this could be accomplished easily by monitoring "Cursor is over object", but this way of reasoning would also be along the line of someone saying why would we need "On collision with another Object" for Sprites that triggers only once when we already have "Is overlapping another object" and all we need to do is monitor the "Is overlapping another object" trigger.

On any condition that fires continuously, like the "is over object", you can use the system's condition "trigger once while true" (add it as a second condition on the same event).

This way, in essence, you convert it into a trigger event.

Toddler ,

You are right, it seems like there isn't a difference between "on collision" and "is overlapping+Trigger once". I don't feel like this makes the "on collision" superfluous", I find it to be just an other way to reach the same goal.

Thinking like this, I find the onMouseOver/out triggers a logical request.

eli0s the good thing about adding these as triggers rather than using conditions is that it would help improve performance as well, because triggers aren't checked every frame.

Yes eli0s, we both agree that OnMouseOver and OnMouseOut trigger is a logical and consistent step

Sumyjkl , up until now I've naively assumed that adding the "Trigger once while true" somehow "converts" the event in to a trigger! Can you please confirm that adding the "Trigger once while true" condition into an event doesn't affect how often the system checks if the conditions are met and that it does indeed update/calculate every tick?!?

Sumyjkl , up until now I've naively assumed that adding the "Trigger once while true" somehow "converts" the event in to a trigger! Can you please confirm that adding the "Trigger once while true" condition into an event doesn't affect how often the system checks if the conditions are met and that it does indeed update/calculate every tick?!?

a trigger just happens (the on collision being the black sheep of the list, as it stil requires quite a lot of work), where an event with trigger once requires to check every tick if the conditions are true or not.

also, you can put a triggered everywhere, the result will be the same (unless you have two of the same trigger), while an event with trigger once still depends on its place inside the event sheet. Triggers can happen multiple times per tick(function object being the all time representant of that, on created and on destroyed too), trigger once cannot (Is overllaping with trigger once will not work if multiple overlaps exists, as the event will be read only once in total for this tick).

triggers are almost always better than their cousins "check but trigger only once" when you can use them, as they do not check things every tick, they just happen (and can happen outside of the every tick logic, like you press a button, it should fire even if you are not currently reading the event sheet.)

So Aphrodite, it seems you would agree for performance reasons that we should add this also for consistency sake then

Aphrodite , thank you very much for your detailed and thorough answer! That explains a lot and now I understand that there are significant differences between the two methods. This makes Toddler's request even more logical!

'On collision' and 'Is overlapping/Trigger once' don't work the same way. If Sprite1 collides with 5 instances of Sprite2 then the 'on collision' event will trigger 5 times with a different Sprite2 picked each time. The 'Is overlapping/Trigger once' event would only fire once with all 5 Sprite2 objects picked.

> they just happen (and can happen outside of the every tick logic, like you press a button, it should fire even if you are not currently reading the event sheet.)

>

I doubt that they "just happen". There is obviously work being done behind the scenes. I suspect there isn't much difference- triggers must be checked in some form every tick, otherwise how else would they know to fire when they're suppose to. Where do you get your information from?

Prominent

"However, triggers are an exception. See the green arrow to the left of Keyboard: On Space pressed from the previous example:

Note the trigger.

This indicates the event is triggered. Rather than running once per tick, this event simply runs (or "fires") upon something actually happening. In this case, the event runs when the user hits the Spacebar key on the keyboard. It is never checked any other time. Since triggers run upon an event happening, they aren't checked in top-to-bottom order like other events. This means the ordering of triggers relative to other events is not important (except relative to other triggers of the same type, since triggers still fire top-to-bottom)."

https://www.scirra.com/manual/75/how-events-work

and yes, there may be work behind the scene to make sure the trigger actually occurs, but in their essence, they rely on something happening rather than on state checking.