Custom entity lua state handling in blueprints.

[Adil]

It is easy to come up with a modded entity, that may have some lua information assotiated to it, the recently discussed inserter with filters defined by network.
Sometimes, a certain state of such associated data may be required for the layout to work, for example a table of conditions of the above mentioned network inserter.

Thus it would be nice to have a set of events on_blueprint_created, on_blueprint_placed, on_blueprint_cleared which should provide the unique identifier of blueprint layout and the ability to inspect the entities used in layout creation, so that modders could handle the templating of their entities themselves. Or maybe other mechanism of storing the associated data in blueprints, so that it would be accessible in a special field of a ghost entity.

[Tinyboss]

Really great idea, and necessary if we want mods to be able to provide "first-class entities" in Factorio.

Maybe when a blueprint is created, on_blueprint_created could be called for each entitity in the blueprint, and the return value of that function should be a table (or nil, if nothing needs to be saved), which would be associated to that entity in the created blueprint. Then when the blueprint is placed, on_blueprint_placed would be called for each entity, with the stored table (if any) passed back as a parameter.

Actually this isn't exactly right because we place ghosts with the blueprint and we want to restore the data to the actual constructed entity, but the main idea is that each entity can decide for itself what data it wants to store in the blueprint and how to restore it upon construction.

[GopherAtl]

just the events, with a read/write copy of the entities table of the blueprint, so it metadata can be added (in create), or applied to the ghosts (in place).

For on_robot_built events, you could add a field to the event containing the ghost, assuming this isn't already the case (don't remember the wiki saying anything about it but haven't actually checked, either)

Definitely a good idea, would provide a capability we will ultimately need one way or the other (copying custom settings and states on mod entities via blueprints) and my gut says it wouldn't be too much work on the dev's end.

[TheEdenCrazy]

My proposal for the addition of blueprint custom data would be like so:

• Ghost entities have two new fields

  Code: Select all

  blueprint_id

  and

  Code: Select all

  blueprint_entity_id

• Blueprint data can not only be accessed via the item, but created blueprints can be accessed through a

  Code: Select all

  game.blueprint_data

  This is a table mapping blueprint_ids to blueprint data (name, entities, etc) - see the LuaItemStack section of the Factorio Lua APIl
• 3 new events, all with blueprint_id field:
  • Blueprint creation event: Called when a blueprint is created, this contains a field blueprint_entity_id_map, mapping blueprint_entity_ids to entities in the real world.
  • Blueprint placement event: Called when a blueprint is placed.
  • Blueprint destruction event: Called when a blueprint is deleted or modified.
• When a blueprint is placed, the ghost images get blueprint_id assigned to the bluprint_id of the blueprint they were created from, and blueprint_entity_id is assigned to the blueprint_entity_id of the entity that it was based on when the blueprint was created.

The blueprint_id and blueprint_entity_id are there so that mods can store custom data about entities in blueprints in their global tables. Then in their on_*_built event handlers could check what ID and what blueprint the objects came from, so that they could load data that was set during the blueprint creation method into the new entities.

[Afforess]

+1 to blueprint events.

[thelordodin]

+1 Up!

Workaround solution here: viewtopic.php?f=28&t=49709#p288672

[thelordodin]

Will this ever be implemented?

[Rseding91]

Will this ever be implemented?

I don't know what's really being asked for. There are several things here that conflict with each other in utility and some that just aren't feasible.

[thelordodin]

Will this ever be implemented?

I don't know what's really being asked for. There are several things here that conflict with each other in utility and some that just aren't feasible.

It's all about

It is easy to come up with a modded entity, that may have some lua information assotiated to it

A lua value field is needed on entities. This field must be preserved with the entity if it in blueprint or a ghost.

Literally I mean:
constant_combinator1.custom_data['mod1'] = ...

And custom_data is a lua table on every entity.

[Rseding91]

I see. Unfortunately something like that isn't feasible as the performance and memory usage trade off would be too large.

[thelordodin]

Lackily we now have an ability to save value in programmable speaker's alert message.
I just got this idea and tested if it's able to store 1 Mb string: yes It is!
And it's preserved in blueprints.

So now mods can really store any info in it.
I hope it wouldn't be limited in short while?

[eradicator]

I see. Unfortunately something like that isn't feasible as the performance and memory usage trade off would be too large.

How feasible would it be to have a callback when an entity is blueprinted, something like:

1. An entity is added to a blueprint and the game raises on_entity_blueprinted, containing event.entity = (the entity blueprinted)
2. A modder can register a function to on_entity_blueprinted like to any other event. But for this event the function can return a table (most likely something copied from the mods lua instance global table) that the modder wants to be saved to the blueprint for that entity.
3. ???
4. The player places a blueprint in the world.
5. The game raises on_entity_built with an additional element event.mod_data which contains the table that was originally returned by the handler function and stored in the blueprint.
6. The modder can do whatever he needs to the newly created ghost using the data from the table.

This should only have a performance impact if a mod actually registers a handler to on_entity_blueprinted right? I guess it might be supported by a prototype flag "requires_custom_blueprint_data" so on_entity_blueprinted doesn't need to be raised for tons of entities that don't need it. (Entities that could profit from this in my own mods are mostly things that even in a megafactory would only be required in small numbers (<100)).

[feasible/unfeasible] [might eventually happen/ain't gonna happen]?

[slippycheeze]

I got annoyed by my AttachNotes data not carrying over, so I point you to this post with a library to save arbitrary and unlimited data in blueprints. It uses the msgpack binary format to encode (a limited subset of) data compactly with bit swizzling, and then stores it 32 bits at a time in a constant combinator with signals.

This allows a reasonably unlimited amount of data storage - it defines a 500 slot combinator, or 2000 bytes of data. msgpack overhead is pretty close to zero - 1-2 bytes for a single string - and this allows arbitrary tables, not just strings. Trivially extensible to unlimited data with the addition of a "sequence" and/or "entity" label in signals.

If you wanted to make regrettable life choices you could apply the same thing to simply encode a string in one-or-more combinators.

Also potentially applicable is the fact you can export an item stack entity (eg: blueprint, item-with-tags) as a blueprint string (ie: zlib compressed, base64 encoded) so you could use that to pack your arbitrary (or string) data prior to injecting it into the signal fields.