Include captured entity's unit_number in blueprint entity data

[justarandomgeek]

Since we can now store entity tags in blueprints, it would be useful to have a direct way to match them up (during on_player_configured_blueprint, for example) to the entities in the real world to copy the relevant config into tags. If the blueprint captured the original unit number, this could be used to look up the relevant mod data.

[eradicator]

+ 1 Some (any) method to make correlation trivial.

[eradicator]

When thinking about how to implement this on the lua side i noticed that a reusable solution also has to work when a mod has several same-name same-position entities. I.e. Miniloader has two (i think) hidden inserters at exactly the same position. This means that neither name or position are suitable unique identifiers to try and match an existing blueprint to a find_entities_filtered result. So... doing this in lua reliably means contructing the whole blueprint from scratch in lua. :(

+10 for a native solution.

[Rseding91]

I thought of this as well when making the tags logic but I don't have a clean solution for this. Including the unit number in the blueprint itself isn't viable. If I do think of a nice solution I'll implement it.

[DaveMcW]

LuaItemStack.blueprint_offset. Contains the x and y offsets to convert from blueprint coordinates to map coordinates. It could also be returned from the event if you don't want another LuaItemStack property.

This is trivial for entities that can be identified by position, and greatly simplifies the problem for those with identical positions.

[justarandomgeek]

Was there a reason for not adding tags to live entities too? That would pretty much remove the correlation problem, as it would have already captured the entity's tags, and then we can adjust that in the blueprint if required.

[Rseding91]

Was there a reason for not adding tags to live entities too? That would pretty much remove the correlation problem, as it would have already captured the entity's tags, and then we can adjust that in the blueprint if required.

Runtime memory overhead and save file size.

[eradicator]

I thought of this as well when making the tags logic but I don't have a clean solution for this. Including the unit number in the blueprint itself isn't viable. If I do think of a nice solution I'll implement it.

The solution i thought of to implement myself was a "synchronized list" containing the unit_numbers. I.e a list that links the "entity_number" of a blueprinted entity to it's unit_number.

Code: Select all

local entities = bp.get_blueprint_entities()
local unit_numbers = magic() --a list {entity_number = unit_number}
for k,v in pairs(entities) do
  local unit_number = unit_numbers[v.entity_number]
  --dostuff
  end

This list could then be delivered with the event, and wouldn't affect anything that doesn't access it.

[mrvn]

When thinking about how to implement this on the lua side i noticed that a reusable solution also has to work when a mod has several same-name same-position entities. I.e. Miniloader has two (i think) hidden inserters at exactly the same position. This means that neither name or position are suitable unique identifiers to try and match an existing blueprint to a find_entities_filtered result. So... doing this in lua reliably means contructing the whole blueprint from scratch in lua.

+10 for a native solution.

+10 for a native solution, too. Preserving the unit_number in the blueprint entities would be enough I think.

But I think you are overstating the problem with identical, same position hidden entities:

1) you can place them at slightly different positions (+-0.001)
2) use the direction or other base property to pick the apart
3) if they are otherwise identical does it matter which one is which? You know you will have 2 identical ones at some spot. Just randomly pick one for each original entity.
4) If you have hidden entities then you probably have them hidden behind some non-hidden entity. Why not take the visible entity and on_build() where you create the hidden entities transfer the information of the tags from the visible to the hidden ones.

[mrvn]

I thought of this as well when making the tags logic but I don't have a clean solution for this. Including the unit number in the blueprint itself isn't viable. If I do think of a nice solution I'll implement it.

Why not give all blueprint entities a tag "unit_number" pre-filled with the original entities unit_number?

Or, since that would blow up blueprint size since everything then always has a tag: A field blueprint_unit_umber that is only present in blueprint entities during the setup phase.

[justarandomgeek]

Was there a reason for not adding tags to live entities too? That would pretty much remove the correlation problem, as it would have already captured the entity's tags, and then we can adjust that in the blueprint if required.

Runtime memory overhead and save file size.

Would it really be so much worse than keeping the same data in lua like we all do now?

[Boodals]

Would it really be so much worse than keeping the same data in lua like we all do now?

Yes. At the moment, if no mods are installed, there is 0 memory overhead. With tags as a property of all entities, every entity would have to have at least an 8 byte pointer, even though nothing would use it unless you installed mods.

I think an alternative system could be viable: a static map from entity to tags, essentially global.tags[entity]. The hard part is the indexing with save/load stability since not all entities have a unit_number. It could just be limited to EntityWithOwner then use unit_number, but people would complain that they cant use it for trees and rocks, etc.
From the lua API it could just be entity.tags. The blueprint tags could read/write to it so blueprinting mod entities would be easy.

[eradicator]

I think an alternative system could be viable: a static map from entity to tags, essentially global.tags[entity]. The hard part is the indexing with save/load stability since not all entities have a unit_number. It could just be limited to EntityWithOwner then use unit_number, but people would complain that they cant use it for trees and rocks, etc.
From the lua API it could just be entity.tags. The blueprint tags could read/write to it so blueprinting mod entities would be easy.

Mods would still need the unit_numer of entities to associate custom data into the blueprints though. And if you store all the data in global... how would that work with im/exporting blueprint strings? (Maybe i'm not fully understanding what you're suggesting.)

[mrvn]

Would it really be so much worse than keeping the same data in lua like we all do now?

Yes. At the moment, if no mods are installed, there is 0 memory overhead. With tags as a property of all entities, every entity would have to have at least an 8 byte pointer, even though nothing would use it unless you installed mods.

I think an alternative system could be viable: a static map from entity to tags, essentially global.tags[entity]. The hard part is the indexing with save/load stability since not all entities have a unit_number. It could just be limited to EntityWithOwner then use unit_number, but people would complain that they cant use it for trees and rocks, etc.
From the lua API it could just be entity.tags. The blueprint tags could read/write to it so blueprinting mod entities would be easy.

Could you explain why it's impossible to give the blueprint entities in LUA a unit_number matching the entity being blueprinted?

And I don't mean to include the unit_number in blueprints. Just for the duration of on_player_setup_blueprint where mods would add tags.

[mrvn]

My best guess on setting the unit_number as tag in blueprints can be seen here:

https://mods.factorio.com/mod/example-entity-with-tags
https://github.com/mrvn/factorio-exampl ... -with-tags

[eradicator]

Why not give all blueprint entities a tag "unit_number" pre-filled with the original entities unit_number?

Because if it's a tag mods can delete it, so a broken mod might prevent all other mods after it from reading the unit_number.

[Klonan]

The problem with unit number, is that it only really applies in that 1 save,
Once the blueprint is made, it can be used in other saves, exported, imported, moved around, etc.

And having it then always with that blueprint, might give people the wrong impresssion

I don't think its a good solution

[eradicator]

And having it then always with that blueprint, might give people the wrong impresssion

That's why i suggested a lookup table that's valid only during the event call. Makes the event bigger, but not the map data, nor the blueprint, and it's fully backwards compatible.

[justarandomgeek]

The problem with unit number, is that it only really applies in that 1 save,
Once the blueprint is made, it can be used in other saves, exported, imported, moved around, etc.

And having it then always with that blueprint, might give people the wrong impresssion

I guess i didn't make very clear in my OP, I was expecting a name like "original_unit_number" or "captured_unit_number" or something that makes it clear that it's just a value that got captured for reference and won't be used further by the game. I don't really expect it being useful beyond the first on_player_configured_blueprint when a blueprint is initially captured, but it would be immensely useful there. I suppose passing a mapping of blueprint entity number to captured unit_number to that event when possible (newly captured prints, but obviously not on edits of existing prints) would also cover the same need though...

[mrvn]

Why not give all blueprint entities a tag "unit_number" pre-filled with the original entities unit_number?

Because if it's a tag mods can delete it, so a broken mod might prevent all other mods after it from reading the unit_number.

1) There is so much stuff mods can do to break other mods or the whole game I wouldn't worry about that.
2) Why should set_entity_tag(index, "unit_number", ...) succeed?

The problem with unit number, is that it only really applies in that 1 save,
Once the blueprint is made, it can be used in other saves, exported, imported, moved around, etc.

And having it then always with that blueprint, might give people the wrong impresssion

I don't think its a good solution

Nobody is talking about it being useful past the creation of the blueprint. The idea is to have the unit_number during the on_player_setup_blueprint to lookup relevant information about the entities so that the right (save, export and import save) tags can be applied. That's why I think best would be for the LUA structures returned by get_blueprint_entities during the on_player_setup_blueprint event to include those numbers. At all other times it can be unavailable and shouldn't be saved in the blueprint.

Apart from just other saves, imports and exports the unit_number becomes invalid when an entity is for for example mined. Or destroyed by aliens. So preserving it past the blueprint creation really makes no sense.