Include captured entity's unit_number in blueprint entity data

[Boodals]

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.)

No, the system from lua would be transparent. You'd just set the entity.tags, and then blueprints "just work". Hell you could stop using global for per-entity data altogether.

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.

It's not impossible, nobody has said its impossible. At most it'll be a day or two of work for Rseding (probably). I was proposing something entirely new that would make the blueprint-persistence problem trivial for modders, so we wouldn't need workarounds like matching unit_numbers, and storing entity data in global. It would "just work".
Of course i'm not sure how feasible it is, so who knows. Maybe ill try throwing something together and seeing if it works out (I have source access).

[eradicator]

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.)

No, the system from lua would be transparent. You'd just set the entity.tags, and then blueprints "just work". Hell you could stop using global for per-entity data altogether.

Oh so you mean a system that would also allow setting tags onto "live" entities, just without storing a pointer in the actual entity data? So that mods don't need to handle on_blueprint_setup anymore because the tags are already on the entity? That sounds pretty revolutionary (in a very positive way).

[mrvn]

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.)

No, the system from lua would be transparent. You'd just set the entity.tags, and then blueprints "just work". Hell you could stop using global for per-entity data altogether.

Oh so you mean a system that would also allow setting tags onto "live" entities, just without storing a pointer in the actual entity data? So that mods don't need to handle on_blueprint_setup anymore because the tags are already on the entity? That sounds pretty revolutionary (in a very positive way).

That sounds pretty helpful. But how would extensions work? For example mod A sets tag foo="bla" and a related mod B want's to extend that to foo="bla1" or foo="bla2" depending on other factors. Would all mods share an entity.tags namespace so they can freely overwrite each others tag? Or would each mod have their own namespace making it impossible (needs public interface) to alter another mods tags?

[Boodals]

That sounds pretty helpful. But how would extensions work? For example mod A sets tag foo="bla" and a related mod B want's to extend that to foo="bla1" or foo="bla2" depending on other factors. Would all mods share an entity.tags namespace so they can freely overwrite each others tag? Or would each mod have their own namespace making it impossible (needs public interface) to alter another mods tags?

I don't think shared namespaces would be a good idea, and its surprisingly easy to have a separate mapping per mod. So if it were made it would probably be per mod. It wouldn't cause any problems that don't already exist - if you want to modify a modded entities custom data you have to use interfaces to tell the mod that you would like to modify the data. And the probability of naming conflicts is pretty large.

But this is all hypothetical, I don't understand enough of the engine to be able to say whether or not it could even be done. I'll do some digging, maybe even try blindly implementing it and hoping it all just works out well, but I wouldn't get your hopes up unless Rseding or another dev decides to do it.

Edit: thinking about it more, I don't think a tags mapping would be a good idea to do at all. It would mean every time you wanted to read or write to something stored in the tags (which would be very frequent) it would have to call a C++ function, which has overhead. It's primary benefit is to avoid having to handle blueprint events, which is something that happens very infrequently.
It's better for performance to keep all Lua data in Lua, and only have explicit support for blueprints when blueprints are being used.

[Rseding91]

I found a way to include a mapping of the entity index to the source entity during the event and implemented it for the next version of 0.17.

If mods add or remove entities during the event it will invalidate the mapping but there's nothing I can do about that. There's the get/set tag functions which won't invalidate entities in the blueprint.

[mrvn]

I found a way to include a mapping of the entity index to the source entity during the event and implemented it for the next version of 0.17.

If mods add or remove entities during the event it will invalidate the mapping but there's nothing I can do about that. There's the get/set tag functions which won't invalidate entities in the blueprint.

Invalidate as in the removed/added entity won't map right. Or as in all / a random amount of entities will break?


I think I came up with a better solution to mapping the entities manually. Instead of figuring out the center of the blueprint (which requires going through all entities and all tiles and guessing how the game rounds) find the left_top most entity in the area and blueprint. That gives the relative offset between all entities. But hopefully rseding91s method will work and make this obsolete.

[Rseding91]

All / a random amount of entities will break.

[eradicator]

All / a random amount of entities will break.

Any way to detect this on the mod site except for...trying to compare the count and hope that they didn't change the order?

[Rseding91]

Check if the entity names are the same would be another way.

[eradicator]

Check if the entity names are the same would be another way.

Aka if a mod removes two of their entities at the beginning, and adds two at the end, and all *my* entities are shifted down because of that... there's no way to detect it? Would it be feasible to include the center position (which is different from the selected areas center) of the blueprint into the event so its easier to compare positions too?

[mrvn]

In most cases knowing the offset between surface entities and blueprint entities would be enough and the few exceptions (multiple same entities at the same position) it probably doesn't matter if they are swapped around.

So if the mapping you have is fragile like you said please add the surface coordinates of the blueprints origin to the event. That would remain valid no matter what manipulations other mods do.