Discussion Disable/Enable any event for objects/instances

[GMWolf]

We need a suggestion label.

Often when working with GM, I would like to keep the clicked evevents, etc, But use my own code to trigger the event - This is used a lot in GUI design, etc. This is already possible, but the problem remains that the event will still be triggered by GMEngine.

The solution so far was to register scripts as events, Perhaps using a naming scneme and reflection to automate the process. But this defeats the point of having Objects with events.

What I suggest is that we have the ability to disable some events for objects and instances. This way, the code will only run when called using event_perform or event_perform event.

This has many advantages over current solutions:

• We get to keep the interface GM offers,
• easier to port from GM event triggerin to custom event triggering,
• prevents cluttering the resource tree with loose scripts
• makes it much easier when dealing with inheritance.

 

[Mike]

Outside of user events, this isn't something we're currently looking to expand on.

 

[GMWolf]

I would love this to be reconsidered.
Im working on yet another project where some of my objects have no sprites, (drawing them myself) because i dont want the mouse events to trigger.
A very common scenario, when avoiding clickthroughs: i am distributing the event myself to avoid clicking on objects behind interfaces.
Is this really something so trouble some to implement it outweights the many advantages it presents?
a simple functions would suffice: event_disable(object/instance, type, number)

 

[Mike]

I don't understand why mouse event are an issue. If you don't want clicked-on events, use the global mouse ones and then detect whatever you want.

Or don't have mouse events in that object.

Or use a parent with events on some, and a child where you override and disable on others

Or simply put an IF at the top of the code and a user variable and disable yourself.

I can see LOTS of ways to avoid this in the cases where you think it may be an issue.

 

[GMWolf]

I don't understand why mouse event are an issue. If you don't want clicked-on events, use the global mouse ones and then detect whatever you want.

Or don't have mouse events in that object.

Or use a parent with events on some, and a child where you override and disable on others

Or simply put an IF at the top of the code and a user variable and disable yourself.

I can see LOTS of ways to avoid this in the cases where you think it may be an issue.

Yes, I am doing ok without this funcitonality.

If you don't want clicked-on events, use the global mouse ones and then detect whatever you want.

I do want clicked on, But i would like to be able to stop them from happening if i click on an object 'above' it.

don't have mouse events in that object.

Its a shame to have a beutiful event system in GM, to just not use it because i have clickable UI elements. (like many games).

Or simply put an IF at the top of the code and a user variable and disable yourself.

Well, not quite: i dont want to outright disable an event, I want GM to stop triggering them. I want to trigger them myself with event_execute. Now i could have global.mycall = true; event_execute(..), global.mycal = false. But really?

I can see LOTS of ways to avoid this in the cases where you think it may be an issue.

And i can see a very nice feature YYG could implement
I get that there are workarounds. In fact, there are workarounds to GM entirely... But it would make our lives quite a bit easier to have this feature, the same way GM already offers data structures, on top of arrays, and plenty of drawing functions, on top of vertex buffers and textures.

 

[Mike]

I do want clicked on, But i would like to be able to stop them from happening if i click on an object 'above' it.

Okay, I see what you're after. Because processing of mouse events isn't done based on depth, this wouldn't work anyway. Only rendering is done based on depth.

To do this properly your mouse event should set the current "top" clicked depth/id of the object, and then each new event look to see if it's below this, and if not don't over write the ID/Depth. Then process the result in the step event. You will have issues with overlapping instances on the same layer, as you'll have no idea what's "on top" until the draw (when one is drawn before another one)

 

[GMWolf]

Okay, I see what you're after. Because processing of mouse events isn't done based on depth, this wouldn't work anyway. Only rendering is done based on depth.

To do this properly your mouse event should set the current "top" clicked depth/id of the object, and then each new event look to see if it's below this, and if not don't over write the ID/Depth. Then process the result in the step event. You will have issues with overlapping instances on the same layer, as you'll have no idea what's "on top" until the draw (when one is drawn before another one)

No no no, you do not understand me...

What i would want to be able to do, utimately, is disable the click event, so that GM engine will never call it on my UI object.
I would then have a heirarchy of UI elements (windows, panes, buttons, etc).
On the global left click event, I would multiplex the event to the first root of the UI tree.
It would then recursivly call the event on each of the children.
If an element 'takes' the event (If you click on a button), then i percoalte that up the tree so that other branches are not called. This means that if two elements overlap, I can only click on one.
It also reduces my collision checks and matrix manipulations (as coordinates are defined in parent space) as I can only click on a button if my mouse was within the window it belongs to.
Im doing this now by not assigning sprites, and using a scripts and macros to return values from events.

This is a very standard way of doing things. I have seen this pattern in quite a few UI systems. A great example is LibGDX scene 2d's ui.

Another example is when i have a grid of instances. When i click in the room, It checks the Grid to find what instance is there, and uses event_execute to trigger the left press event on it.
The unit itself has its X and Y coordinates as grid coordinates, not room corrdinates. So i wouldnt want the event to be triggered when i click in the top left corner, where GM thinks they are. (current solution is not to give them a sprite.)
Further more, there is a focus system such that if a menu is up, you cannot click on other elements. I could go through the game and add iff statements everywhere, but it would be much nicer to simply disable the left click event on all my unit objects.

The second example is probably a more common scenario. But the first is a problem i have seen many UI assets have trouble with. All ended up not assigning sprites and doing their own multiplexing.
I think its a shame to have these nice interfaces provided by GM, but to have to avoid using them and 'fight' against the engines with hacks, or by implementing our own interface.

Essentially, this would be an event specific instance deactivation.

 

[xDGameStudios]

+1 for the request (not that it matters a lot though xD)

 

[xDGameStudios]

Outside of user events, this isn't something we're currently looking to expand on.

What about more user events?!
There are so much workarounds that use them that 15 events is not that much

 

[GMWolf]

So now in my project i found that disabling the step event would be tremendously usefull to chain ActionObjects one after the other. Going to use an "active" variable for now, but would be much neater with this functionality.
my other option is instace_change -> but thats even worse for me than just having varialble checks.

 

[xDGameStudios]

So now in my project i found that disabling the step event would be tremendously usefull to chain ActionObjects one after the other. Going to use an "active" variable for now, but would be much neater with this functionality.
my other option is instace_change -> but thats even worse for me than just having varialble checks.

I suggested this in another post... but I think the answer I had was towards the "no"... yes, chaining events is not that easy in gamemaker, as we can't fully control events. I would love to have more control over events... disabling then is a great option... my reason was to control performance...
the hidden update logic is ran every frame and sometimes I may not need that... for example a window (in a UI system) I don't want to set it's speed, direction, xprevious, yprevious, angle... every frame!! but it does happen... and we can't disable it.

I know not every hidden update logic can be disabled because I think there is where the builtin events are triggered (just guessing here) but never the less it would be great to disable the unwanted part of the logic. If GM used a component approach (it would be great) we could get access to the logic and remove or disable that component

object components:
{
position // this would add the x, y
movement // this would add the speed, angle... and would add the update logic during the update
appearance // this would add the sprite, image_angle, image_..., color..... and add the logic to draw during rendering (only if position was also a component)
...and so on...
}

 

[YellowAfterlife]

I can see LOTS of ways to avoid this in the cases where you think it may be an issue.

I believe the only case where toggling events would have been helpful would be collision events.
They are faster for taking care of multiple overlapping objects than doing the same with code (collision_ functions can't return you all overlapping instances at once), but result in collision checking running for as long as object exists (even if no longer needed - e.g. collision checks against static objects while the object is standing still).
Being able to toggle instance' collision checking against the chosen object type would have allowed to make better use of this without taking compromises.

To say, this also already [partially] exists in form of object_set_collisions function. Unfortunately, the function was never documented, enables/disables all collisions for an object type, and generally shows no evidence of ever being tested anywhere outside of Nuclear Throne's Vita port.