Some identifier linking mined entity events with mined item events

[sparr]

When on_player_mined_item fires, there seems to be no information available about the entity that was mined because it is gone. I would like for there to be some identifier in on_player_mined_entity and on_player_mined_item that allows them to be matched up, so that I can save some info about the entity while it still exists, to be referred to shortly afterward.

[Bilka]

Use case?

[sparr]

After the entity is removed I need to check the game state for changed belt connections, changed pipe connections, changed rail segments, etc.

[sparr]

Still wishing for this as I work on rewriting a mod.

[Rseding91]

Just don't use that event. The https://lua-api.factorio.com/latest/eve ... ned_entity event contains a LuaInventory with all the things that are going to end up in the event anyway.

[sparr]

Yes, but when that event fires the entity is still in the world, so none of my checks are valid yet. I need to run my checks after the entity is destroyed, and on_player_mined_item seems to be the only event that triggers at that point.

[curiosity]

Can sequences of these two events be interleaved? Doesn't seem so. Then it seems simple to match the events: all you need is a stack and a tick number.

There is also on_entity_destroyed.

[sparr]

Are you suggesting that when I mine two entities in the same tick I will always get the mined entity event for one, then the mined item event for the same one, then the mined entity event for the other, then the mined item event for the other? I'm not sure how to test this assumption; experiments would only be indicative, not proof.

Can the devs say (and document) this as a guarantee?

[Rseding91]

Can the devs say (and document) this as a guarantee?

That is currently how it works and I don't see any plans to change how it works.

[curiosity]

Are you suggesting that when I mine two entities in the same tick I will always get the mined entity event for one, then the mined item event for the same one, then the mined entity event for the other, then the mined item event for the other? I'm not sure how to test this assumption
experiments would only be indicative, not proof.

Code: Select all

/c for _, entity in pairs(game.player.surface.find_entities_filtered{type = 'tree'}) do game.player.mine_entity(entity) end

Oh, it seems that you will also have to handle the mining of tiles, since that also raises on_player_mined_item.

experiments would only be indicative, not proof.

You must assume there is some internal logic to the game, other way lies madness.

[curiosity]

Hmm... maybe this isn't so doable, after all. A mod might do something crazy to interrupt the mining process (destroy the entity, ban the player etc.), the item event might never be emitted. Best is, I guess, to check the top entity on the stack to see if it has been destroyed already, since that and not a 1-to-1 event matching is your real goal.

[sparr]

To be clear, my "real goal" here is to be able to identify what entity was just destroyed as soon as possible after the entity gets destroyed.

[curiosity]

To be clear, my "real goal" here is to be able to identify what entity was just destroyed as soon as possible after the entity gets destroyed.

Is it your mod's entity or some arbitrary one? Because in the latter case another mod can always screw you over and it will be within reason. Either you don't get any event by the time the entity is destroyed or it's destroyed after you decided it's not.
So what's your actual real goal? Why are you unsatisfied with the intended ways to detect this?

[sparr]

This is for https://mods.factorio.com/mod/belt-overflow

When a belt is destroyed, I need to recalculate whether any nearby belts might now be places items could back up. All of my calculations for that depend on the destroyed belt being gone, but it isn't when the destroyed event happens, and it is when the mined event happens, so I'd really like to run my check on the mined event.

[curiosity]

No, the entity is most definitely gone by the time the destroyed event happens. So just register every belt to that event and problem solved. Not like a tick of delay will make a noticeable difference to the player.

[sparr]

Sorry, I meant on_player_mined_entity, which fires right before the entity is destroyed.

So, using on_entity_destroyed, I could register every belt, and keep a table of their locations, then when one is destroyed I'd know where it was previously located? That's a good idea. A lot of data storage that won't get used, but it would work. That event didn't exist when I created this thread. I'll look into using it!

[curiosity]

...I mentioned it in my first post here, almost two months ago.

If you are concerned with memory use, you can register belts from inside on_player_mined_entity, though of course there are more ways an entity can be destroyed. So pick your poison.