add support for element types for ``addEventHandler``

[PlatinMTA]

Is your feature request related to a problem? Please describe.

Right now (as an example) if you want to add an event that checks when a random vehicle streams in, you need to attach it to root, unless you know which vehicles are expected to be streamed in. This happens also if you want to check when a player changes an element data, or when an object hits a collider.

This is usually not a big problem, you just do a simple if statement checking the element type and move on, but it's just wasted performance. For events like onElementDataChange when you want to only check on players you can just check onPlayerJoin or onPlayerQuit and add the players manually to a table, but for vehicles or objects you really don't have a way to check on them unless you already know they are on your resource.

Adding a element type check instead of adding the events on root might be a net positive in performance gain.

Describe the solution you'd like

bool addEventHandler ( string eventName, element attachedTo, function handlerFunction [, bool propagate = true, string priority = "normal" ] )    

attachedTo should be able to take string elementType as a value, so the trigger is only executed for those element types, saving performance on checks like

if getElementType(element) ~= "vehicle" then
    return
end

Describe alternatives you've considered

#218
This, in combination with the already existing event on(Client)ElementDestroy would make it possible to create new handlers for all the element types you want. I actually don't know if adding 200 event handlers vs having one on root is faster or not, I believe it is faster but I haven't really looked into the event system to confirm.

The main issue and discussion back then was that the event system performance was (and still is) trash. Tons of events are being called for things some servers don't even use, like onClientWorldSound, onClientPedStep, onClientPlayerWeaponFire, heck even ``onClientElementDataChange`. Adding another event like that would make the issue worse.

That being said, thats an argument to fix the event handler system, not an argument against the event itself.

Additional context

#2173 was a PR by Pirulax that aimed to fix the performance of the event system in MTA, maybe if a refactor is planned in the future this could be an important addition.

Again as I said before I didn't read the code for the event system... but how trivial would it be to not fire events that havent been added by a Lua VM?

Security Policy

• I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.