Would it make more sense for LuaSurface::create_entity() and LuaEntity::destroy() to raise events by default?
Right now they default to running silently, and I've noticed a lot of mods create or destroy things without raising events. This makes it hard to keep track of which entities exist without resorting to searching every now and then, and results in a lot of defensive programming.
My guess is that most calls to these functions should raise events in order to let other mods know what's going on. The only time you might want to suppress events is if you handle creation and destruction of a given entity entirely internally, and don't want other mods messing with your stuff.
Raise events by default
-
- Long Handed Inserter
- Posts: 95
- Joined: Thu May 18, 2017 2:22 pm
- Contact:
Re: Raise events by default
Also LuaEntity::revive(), while we're at it.
Miniloader — UPS-friendly 1x1 loaders
Bulk Rail Loaders — Rapid train loading and unloading
Beltlayer & Pipelayer — Route items and fluids freely underground
Bulk Rail Loaders — Rapid train loading and unloading
Beltlayer & Pipelayer — Route items and fluids freely underground
Re: Raise events by default
They events specifically are not raised by default because otherwise every single mod out there would have to care about other mods messing with their state when they perform what is supposed to be a non-intrusive operation.
Nobody would expect that calling entity.destroy() on a tree would cause their container entity to become invalid but if it raised an event then anything is possible.
So, my answer is: no.
Nobody would expect that calling entity.destroy() on a tree would cause their container entity to become invalid but if it raised an event then anything is possible.
So, my answer is: no.
If you want to get ahold of me I'm almost always on Discord.
-
- Long Handed Inserter
- Posts: 95
- Joined: Thu May 18, 2017 2:22 pm
- Contact:
Re: Raise events by default
I guess my question is what you mean by “non-intrusive”? The entities on the surface are shared state. Unless you are temporarily creating and destroying, or otherwise keeping entities to yourself, then they will end up potentially messing with other mods.
As it stands, calling destroy() silently feels far more intrusive to another mod’s state. The state changes, there is no notification, and it becomes difficult to handle every case where your data appears or disappears without warning.
The case you raised indeed sounds like no fun to handle, but at least that incompatibility shows itself at a clear instance in time. The reality is that mods have the potential to interfere with one another all the time, and right now they default to doing so silently.
Re: Raise events by default
In that case, how about raising an event after the current event handler is done?Nobody would expect that calling entity.destroy() on a tree would cause their container entity to become invalid but if it raised an event then anything is possible.