TEDERIs

I also saw an error `C2065: 'ZoneScoped'`, but the solution is trivial I guess(add missing headers to PCHs).

**onElementDataChange** may look better but must be avoided due to the performance impact. ElementData is often used as a high frequency synchronization conduit and Lua events will make it slower....

And the better argument name is **authoritative** which is more common in this context.

`setElementDataProtected` can do two things (simultaneously): - send a lock signal to clients so clients won't be able to send element data changes - forbid incoming from client packets

How about enabling cancelEvent() for this new event?

Fun fact: **80%** of the `setElementData` execution time is `on(Client)ElementDataChange` event processing with just one simple event handler.

> > Fun fact: **80%** of the `setElementData` execution time is `on(Client)ElementDataChange` event processing with just one simple event handler. > > lol. I would understand it for an event...

I think function `setElementDataSilence(element, key, silent)`(suggest the better name) can be added for blocking element data events. Because in most of the cases those events are not needed but they...

Apart from Lua events (see notes about their performance above), the element data is as fast as possible now.

In theory `google::dense_hash_map` may give even better results but I'm afraid it will consume too much memory