How I can see that my mod was already registered before control.lua runtime etc?

[ZwerOxotnik]

I want to know more about the state of a mod before any call of defined.events in order to sync variables/events.

on_init, on_load, on_configuration_changed from LuaBootstrap works if the mod isn't registered to the save file yet, or it's another version of the mod.
However, in other cases, I don't see any way to notice that the mod won't call on_init, on_load, on_configuration_changed and thus the mod won't get access to some variables/changes before the runtime stage without workarounds like "settings".
It's the case when players will be desync if the mod changed events/variables at runtime stage, but the mod can't check "environment" without using another ways, because the mod is registered already and there's no other "events"/adaptation to other cases.

I can avoid the global table by creating settings at settings stage and operating with them through scripts at events etc thus it'd be a possibility for the mod in order to check changes... or I might even use event filters for my particular cases with events, changing them sometimes, but it'd be weird.

So, if I'm changing events/variables at runtime stage, I can sync them by using setting created at settings stage or don't change them by using event filters with additional scripts and, probably, with new events. Those ways/workarounds are kinda dirty in some cases and not always suitable.

Also, how I can know that a map initializing first time? (on_nth_tick calls immediately at runtime stage, but the global table is not initialized yet)

(such dynamic events is the only way for overloaded events with dynamic reaction/environment)

[Klonan]

I want to know more about the state of a mod before any call of defined.events in order to sync variables/events.

This just smells like you're trying to do something that you shouldn't really be doing

However, in other cases, I don't see any way to notice that the mod won't call on_init, on_load, on_configuration_changed and thus the mod won't get access to some variables/changes before the runtime stage without workarounds like "settings".

The mod will always call one of those 3, and for your case, you can use on_load to resetup the conditional event handlers, for instance you can read from global if there are any entities and if so, set up a on_tick handler

It's the case when players will be desync if the mod changed events/variables at runtime stage,

Not always the case, only if you don't do it properly. At all stages, if a player joins, the events and variables must be set up exactly the same way.

Also, how I can know that a map initializing first time?

I don't see why you need to worry

(such dynamic events is the only way for overloaded events with dynamic reaction/environment)

You can have dynamic event reactions without registering and registering event handler,
And most likely you will end up with cleaner and safer code if you don't go down this path

Dynamically registering and unregistering events is a dangerous game, and I do not know of any case where it is actually necessary.

[ZwerOxotnik]

The mod will always call one of those 3, and for your case, you can use on_load to resetup the conditional event handlers

Aha, It simplifies a lot. And, apparently, I "erased" my memory of it before.

Dynamically registering and unregistering events is a dangerous game, and I do not know of any case where it is actually necessary.

I'm trying to understand it more, and I should recheck some things later. Something is off in my code, or I didn't make something necessary/properly.

It works fine if I'm creating an event and change it during on_runtime_mod_setting_changed event but in other cases I'm getting worse performance for some reason.

So, if a mod getting a lot of same events for 1 tick (for instance: 10000 events of on_entity_damaged). I can ignore/filter them by using event filters or by changing the event or adding additional check in the event which can be changed via a setting.
I can't be sure but event filtering seems to be the best way.

Although, if a mod is still receiving a lot of events, in some cases, I can just store some limited data and after Nth ticks check the data in order to avoid computation under data overload for 1 tick.

Or I can just use random number generation to control behavior. It seems silly, but definitely works.