[0.16.51] Integer overflow(?) in script.get_event_handler

[eradicator]

What?
So i was fiddling with script.get_event_handler(name) as a method to verify that the name of an event i get is actually a valid event.

And while trying i got some unexpected return values:

script.get_event_handler('invalid-custom-input-name') → Error: Unknown custom-input name, as expected.
script.get_event_handler(2e18) → Nil, this is unexpected as the event doesn't exist. So i expected an error.
script.get_event_handler(2e19) → A function. Not sure what function. But it's returned for any large positive or negative number.

I don't know of any other method to verify if an arbitrary integer or string is a valid first parameter to script.on_event(#1,#2).
(Additionally for custom-input there also seems to be no way to know the event.name (i.e. the integer id).)

Why?
Because i'm trying to write a (somewhat) generic wrapper around script.on_event to make complex scripting more comfortable.

[Rseding91]

Thanks for the report. The get_event_handler function will return nil if you request an event id that is out of range. Otherwise it returns the function you previously gave it in on_event. There is no way to get the associated event ID for a custom input event. Additionally you should never need those numbers as they aren't deterministic.

I'm not sure how you could get a simpler event system - wrapping it in another layer seems like it's just going to cause more problems and potential desyncs if you do things in a non-deterministic way regarding saving/loading.

[eradicator]

The get_event_handler function will return nil if you request an event id that is out of range.

Except if the number is very large.... err, or so i thought. On further investigation it looks like a bug on my end :oops:. You can close this then.

Additionally you should never need those numbers as they aren't deterministic.

I can do without, might just have looked nicer with.

I'm not sure how you could get a simpler event system - wrapping it in another layer seems like it's just going to cause more problems and potential desyncs if you do things in a non-deterministic way regarding saving/loading.

Simpler? No. But the vanilla system is somewhat unwieldy to use if you have more than one handler function per event. And it requires a lot of repetitive code like writing "local player = game.players[event.player_index]" as the first line of most handlers. And "if event.created_entity.name ~= 'my_thing' then return end" on the remaining handlers. And i'm not even talking about turning multiple tick handlers on and off during runtime. Or doing load-balancing over multiple nth tick handlers so they don't all run on the same tick.

My wrapper is written very carefully and hopefully the knowledge i've gathered over the years is sufficient to prevent any determinism issues from the wrapper itself. And no system can prevents desyncs from badly written handlers ;).

[Rseding91]

I've fixed the super large numbers not behaving as expected for 0.17.