Page MenuHomeFeedback Tracker

[Feature Request] New scripting commands for validating event handlers
Feedback, NormalPublic

Description

One of the biggest concerns for me and many other scripters when writing event-handler-oriented codes is that if someone removes our EHs by mistake (e.g. using incorrect ID, like how many newbies just remove 0) or intentionally (many newbies doing removeAllXXXEventHandlers), our design could fail entirely.

Thus, I would like to ask for scripting commands that allow us to detect and counter these problems.

This command checks if the event handler still exists and has not been removed yet:

isEventHandlerValid [entity, "name", ID]
entity: can be NAMESPACE (maybe only missionNamespace? for mission/user EHs)/OBJECT/GROUP/CONTROL/DISPLAY
name: event handler name
ID: number: EH ID

returns: number:
1: Still exists
0: Was removed
-1: Invalid (never added, which happens if ID >= nextID, or ID is negative)

Alternatively, for mission/user EHs the syntax can be:

isEventHandlerValid ["name", ID]

or

"name" isEventHandlerValid ID

Details

Severity
Feature
Resolution
Open
Reproducibility
N/A
Operating System
Windows 10 x64
Category
Scripting

Event Timeline

Leopard20 updated the task description. (Show Details)
Leopard20 updated the task description. (Show Details)Jun 25 2022, 10:42 AM
h- added a subscriber: h-.Jun 25 2022, 9:18 PM
Leopard20 updated the task description. (Show Details)Jun 26 2022, 7:55 AM
Leopard20 updated the task description. (Show Details)Jun 26 2022, 8:03 AM
Leopard20 updated the task description. (Show Details)

Get next event handler ID:

what for?

Leopard20 added a comment.EditedJun 26 2022, 1:23 PM

Get next event handler ID:

what for?

I wanted it for Intercept mostly. It allow creating a custom callback (C++ function/lambda) with an "ID" which is used to call that function from the SQF EH code. e.g. "[..., " + std::to_string(ehId) +"] InterceptClientEvent [_this]"
Currently this ID is just a static unsigned variable which is incremented each time a new EH is added. But I figured if we know the event handler ID before adding it, we can use the event handler ID directly (_thisEventHandler) and not generate something ourselves.

But it's not high priority since the current implementation works fine in 99% of cases and also I'm not sure if that command will be useful outside of Intercept, so so feel free to ignore that one.

The isEventHandlerValid command alone is still fine with me.

Leopard20 updated the task description. (Show Details)Jun 26 2022, 1:30 PM

Actually I thought of a use case for that one.
Let's say you want to add handleDamage event handler, but you want your EH to be always on "top" (since only the last handle damage EH can override the damage)
So you can do something like:

if (getNextEventHandlerID [...] - _thisEventHandler > 1) then { //another EH is on top, so remove this one and readd to put it on top

}

no, the use case is extremely limited and niche for the whole new command and all eh implementation afterward, besides you can already get next id by adding/removing any eh. Knowing if eh exists is much more useful

Leopard20 added a comment.EditedJun 26 2022, 8:37 PM

Maybe you could combine both?! 😅

As in instead of returning bool, return a number:
1: Still exists
0: Was removed
-1: Invalid (never added, which happens if ID >= nextID, or ID is negative)

Then you can get the next EH ID using a bisection algorithm! And you can still check if something exists using a simple _return > 0 condition!

It sounds like a very good idea! I added it to the ticket

Leopard20 updated the task description. (Show Details)Jun 26 2022, 8:45 PM

Doesn’t work like that. Anyway if dedmen won’t grab it remind me beginning of july

Rev. 149655 https://community.bistudio.com/wiki/getEventHandlerInfo
Let me know if more EH types should be included and why

BIS_fnc_KK changed the task status from New to Feedback.Jul 6 2022, 5:01 PM
Leopard20 added a comment.EditedJul 6 2022, 8:16 PM

Rev. 149655 https://community.bistudio.com/wiki/getEventHandlerInfo
Let me know if more EH types should be included and why

Thanks!
Well it would be nice if it also supported mission event handlers (e.g eachFrame) as well (as unary command). Maybe group EHs too.

The reason is the same as before: knowing if an EH is still valid. I'm willing to spawn one loop that always checks all my EHs are valid. Because if any of them is removed the whole thing breaks.

dedmen set Ref Ticket to AIII-55258.Jul 7 2022, 4:28 PM

rev 149660 added support for mission and music EHs

Very cool. Maybe it could be also useful to include display and control eventhandlers added with displayAddEventHandler and ctrlAddEventHandler ? Just for perfection of this new command. But only if it's achievable.

BIS_fnc_KK removed BIS_fnc_KK as the assignee of this task.Wed, Jul 27, 9:40 AM