Factorio Forums

Rseding91 wrote: ↑Sat Aug 29, 2020 6:16 pm I could add an event when a player manually connects 2 entities but doing so for all the ways things can be connected vs disconnected isn't likely to happen. Sending Lua events during those times is incredibly annoying because any time any Lua event is fired Lua has global access to change/destroy/create anything it wants in the world.

Virtually all of the code is written with the assumption that we don't shoot ourselves in the face and delete/destroy/invalidate the stuff we're currently working on. Lua doesn't care at all about that and runs wild with invalidation. In the end that means any time we dispatch a Lua event we have to re-validate literally everything we're using to still be valid. This 'lua invalidates everything - re-validate' logic has become known as "Lua event cancer" because of how annoying and bloated it makes writing any code that has to deal with it.

So any new events have to get past that 'how much work, bugs, code smell, confusion, and mental load is this going to forever add', then get past 'what's the performance impact of doing this', and then have someone sign up to maintain that code for the rest of their Factorio career.

So, after that wall of text; I don't see this request happening.

mrvn wrote: ↑Sun Aug 30, 2020 11:01 pm Firing off events while things get constructed would be bad. Compound entities like LTN stops or mini loaders will create and connect entities from events so this would call the event multiple times for each stage of the construction. And who knows what other mods will do in those events, e.g. destroy then newly created entity and BOOM.

You should record changes in connectivity and then when everything else is done fire off a single event. The event should have a table containing all the circuit networks that where modified. If it contains intermittent circuit networks that don't even exist anymore that's perfectly fine. That should keep the pain at a minimum as well as keep the event count lower.

Rseding91 wrote: ↑Mon Aug 31, 2020 12:45 amIf part of the stuff gets invalidated part way through the end event is near useless; the connecting could be at the start of a tick, then some logic happens during the tick, and by the time it would fire who knows what the state of anything is. That system just doesn't work.

Rseding91 wrote: ↑Mon Aug 31, 2020 12:45 am

mrvn wrote: ↑Sun Aug 30, 2020 11:01 pm Firing off events while things get constructed would be bad. Compound entities like LTN stops or mini loaders will create and connect entities from events so this would call the event multiple times for each stage of the construction. And who knows what other mods will do in those events, e.g. destroy then newly created entity and BOOM.

You should record changes in connectivity and then when everything else is done fire off a single event. The event should have a table containing all the circuit networks that where modified. If it contains intermittent circuit networks that don't even exist anymore that's perfectly fine. That should keep the pain at a minimum as well as keep the event count lower.

That makes it even more complex because now it involves saving and loading data outside of the logic, migrations, and still it all has to be validated when the event fires. If part of the stuff gets invalidated part way through the end event is near useless; the connecting could be at the start of a tick, then some logic happens during the tick, and by the time it would fire who knows what the state of anything is. That system just doesn't work.

for _,id in ipairs(events.network_ids) do
  local stops = global.stops_by_network_id[id]
  for _, stop in ipairs(stops} do
    ...
  done
done

mrvn wrote: ↑Tue Sep 01, 2020 3:34 pm As sparr says how is one event handler triggering another event any different for circuit network connections events compared to any other?

You eigther already have the code in place to save/restore events to be dispatched for the next tick or you do the potentially infinite loop by dispatching events till things settle down. Either way there is nothing new for the discussed circuit network event.

From what you said earlier I thought your fear was that during e.g. a entity_built event mods would change circuit networks which would cause circuit network events to dispatch imediately while the entity_built event is still running. Now you say the total opposite that events would be carried over into the next tick because infinite event loops are being avoided. Which one is it?

Rseding91 wrote: ↑Tue Sep 01, 2020 3:44 pm

mrvn wrote: ↑Tue Sep 01, 2020 3:34 pm As sparr says how is one event handler triggering another event any different for circuit network connections events compared to any other?

You eigther already have the code in place to save/restore events to be dispatched for the next tick or you do the potentially infinite loop by dispatching events till things settle down. Either way there is nothing new for the discussed circuit network event.

From what you said earlier I thought your fear was that during e.g. a entity_built event mods would change circuit networks which would cause circuit network events to dispatch imediately while the entity_built event is still running. Now you say the total opposite that events would be carried over into the next tick because infinite event loops are being avoided. Which one is it?

Both, and more. It's not just 'more events to fire' it's all the invalidation that mods can cause: from destroying the blueprint item held in the cursor to any entity in the world or any combination of things.

Additionally every bit of info saved is special and has its own saving and loading logic; it's not just 'oh I can save X, so it's handled everywhere'; every time any load function is called it has to handle migrations, it has to only load when the right map version is being loaded, it has to account for everything.