displayRemoveEventHandler doesn't clear index

[phronk 898]

In my addon-free Arma radio script project, I have a bunch of display EHs, each assigned a global variable. For example:

 

kpDn=(findDisplay 46)displayAddEventHandler["KeyDown","call r_dn"];

 

And naturally, I add and remove eventHandlers within functions to prevent spamming the functions and so on. Pretty standard. The script/functions work as intended (As far as I can tell, no adverse issues) but I noticed that when I add an eventHandler and remove it, the ID of the EH continues to go up.

 

If I create an EH in the debug window once I'm in the mission, the ID is 36. After pressing my PushToTalk key a few times and then create another display EH, the ID of that EH is in the 40s or 50s. This number goes up as I add/remove display EHs.

 

Is it an engine "bug"? @genesis92x guessed that the EHs are likely stored in an array, including removed EHs, possibly to keep the EH's ID from changing, since it seems to be based on index. Any ideas?

[genesis92x 810]

Another interesting behavior to add on with this, if you use displayRemoveAllEventHandlers it does clear the index's of the EHs. If you individually remove an eventhandler it does not remove the index from display handler list. However, if you remove all the indices manually, it does eventually return the index count back to 0 when adding a new event handler. This behavior exists when using local variables for eventhandlers as well.

 

My guess is that this is not really a big issue...the only potential concern would be that during a long running mission, a players total index number for displayhandlers could potentially reach the thousands or higher. Although I still do not see how this would really cause any FPS or script lag issues - as ArmA seems to handle large numbers decently well...however that is only if the displayeventhandler index storage is not actually a giant array. I am not sure how Bohemia stores those into memory. 

[7erra 629]

On 3/4/2020 at 8:56 PM, genesis92x said:

My guess is that this is not really a big issue...the only potential concern would be that during a long running mission, a players total index number for displayhandlers could potentially reach the thousands or higher. Although I still do not see how this would really cause any FPS or script lag issues - as ArmA seems to handle large numbers decently well...

Quote

The largest positive number that can be archived is 3.4028235e38 [...].

https://community.bistudio.com/wiki/Number

 

Yeah no concern there. Unless the engine uses another datatype for EHs.

 

Bonus: Quick maths: Assuming an onEachFrame EH adds a new EH and engine limitations are the same you could run the script for

3.4028235e+38 / 60 (1/s) / 60 (1/min) / 24 (1/h) / 365 (1/d)
= 1.7983804e+29 years
= 179,838,040,000,000,000,000,000,000,000 years

ACUTUAL ENGINE LIMITATION (int32):
2,147,483,647 / 60 (1/s) / 60 (1/min) / 24 (1/h) / 365 (1/d)
= 68 years

So basically a decent A3 weekend.

If you still fell uncomfortable with large numbers, why not check in the eh itself if a condition is met and exit if not instead of adding and removing the eh? My guess for the origin of the bug is that with a consecutive counting style it is less probable to overwrite any exisiting ehs and also less resource intensive bc the engine does not have to check for unsused numbers.

Edited March 6, 2020 by 7erra
Corrected math according to @Dedmen's info

[Dedmen 2716]

On 3/5/2020 at 2:26 AM, 7erra said:

Unless the engine uses another datatype for EHs

it does.

int32, 2.1 million (2147483647) max.