Implement several new ghost-related events

[dandrestor]

TL;DR

Add several new events to the game to enable mods keeping an up-to-date list of ghost entities.

What ?

I suggest adding the following events to the game:

1. on_post_entity_created - an event triggered always after a new entity was created, irrespective of the way it has been created (by the player, by robots, by blueprint, whatever).

2. on_post_entity_removed - an event triggered always after an entity is removed, irrespective of the way it happens (destroyed, mined, deconstructed, player builds something else over a ghost, whatever).

3. on_item_requests_updated - an event triggered each time the `item_requests` dictionary is updated.

4. one of the following, which would again happen regardless of the way a ghost is revived (player built, robot built, whatever):
4a. ensure that reviving a ghost generates a `on_post_entity_removed` event for the ghost entity, and a `on_post_entity_created` event for the new constructed entity; or
4b. on_ghost_revived - triggered every time a ghost is revived

5. (bonus) on_neighbour_connected and on_neighbour_disconnected - triggered each time an entity's circuit network neighbours are updated

Why ?

Currently there is no reliable way to keep a list of ghost entities that are in range of a logistic network, in an event-driven way. Mods must find_entities periodically, which is bad for performance. Having these events would enable better mods in this direction, which would in turn enable some very interesting things, such as a roboport that outputs on the circuit network the currently missing items, that triggers LTN trains to deliver construction materials to a remote outpost.

[Rseding91]

Currently there is no reliable way to keep a list of ghost entities that are in range of a logistic network, in an event-driven way. Mods must find_entities periodically, which is bad for performance. Having these events would enable better mods in this direction, which would in turn enable some very interesting things, such as a roboport that outputs on the circuit network the currently missing items, that triggers LTN trains to deliver construction materials to a remote outpost.

That's how the base game does it as well. There's also the part where a logistic network can move by teleport a roboport, destroying, or building a roboport as well as the player walking around.

I'd love to add the events you're talking about but it's simply not feasible time wise due to mods doing unpredictable and unsafe things during events.

Example: during the entity died event some mod was killing other entities and as a result when a biter would execute it's "run" logic the run logic would detect the biter is stuck on something, attack it, and fire the entity died event. The mod killed the biter and then when the game got back to the "run" logic it crashed because it was never expecting that telling a biter to run would remove the biter.

That's a super simple example. It gets more and more complicated as events are added in for different scenarios and adding in all these safety checks isn't free. By not adding the event we don't have to do the safety checks and we can know the logic will perform quickly and without errors.

[dandrestor]

Curses! It felt a little too good to have been omitted for no reason.

That's how the base game does it as well.

Do you mean by iterating through the entities periodically? In that case, would you consider exposing a table of all the ghost entities? Ideally along with information which would readily associate them to the logistic networks in the coverage area of which they are located? I'm thinking since the game already does it, the mods could re-use the information and save some on_tick performance. Edit: Alternatively, would you consider enhancing the roboport circuit network behaviour to report the information (which would obviate the need for a mod)?


What about the neighbour connected/disconnected and item_requests update events? Would that be feasible?

[Rseding91]

The game doesn't know which ghosts are in what networks. It does know which ghosts are on what force - and that I can add to the API.

The "what ghosts are in what network" is part of what the dispatching of robots each tick handles and why the game self-limits at 600 failed attempts showing at a maximum in most cases.

The "what network is this in" check is O(N): iterate each logistic network and iterate each roboport in that network to see if the entity collides with the logistics area.

[dandrestor]

It does know which ghosts are on what force - and that I can add to the API.

That could definitely help. Would that be faster than doing surface.find_entities_filtered{ghost_type="entity-ghost"}?

[Rseding91]

It does know which ghosts are on what force - and that I can add to the API.

That could definitely help. Would that be faster than doing surface.find_entities_filtered{ghost_type="entity-ghost"}?

Yes.

[dandrestor]

What about the events for connecting or disconnecting a neighbour? Would that be feasible?

[bobingabout]

You know what I think would be brilliant for ghosts?

The ability to change the entity name. It would still have to be the same type, such as an inserter can only be changed into another inserter, or an assembling machine to another assembling machine.

The main reason why I bring it up is related to my inserter migration script. I pretty much have to delete the ghost, and recreate it, and in doing so it loses information, such as what filters are set, and what wire network it's connected to.

[hreintke]

@bobingabout

That leads back to the issue that the is no mod_data option in an entity to save/provide that info.

I asked for that in this thread "viewtopic.php?f=28&t=57684#p342092

[Omnifarious]

While this is out of scope...

When I encountered the 'thing might be destroyed in the process of handling an event it generated' issue, I decided that all destruction requests should go on a queue that was processed at a level that could handle the destruction of any of the things that could be destroyed on that queue.