mod_data property for entity

[hreintke]

Hi,

I'd like to revive the request for adding a mod_data property to an entity.
Could/would be "just a table" which can be read and written with arbitrary data.

My use-case is the saving of combinator information in the entity to be able to support configured combinators in a blueprint.
The only very hacky way to achieve this I found makes use of signal counts.
However, this is probably too much hack to allow proper support of a mod which uses this.

Also mods configuring other entities can then use this option.

Benefits will be a standardized way of adding info -> Less hacky solutions -> More stable mods

What is the technical/functional difficulty for this option ?

[lovely_santa]

I would like this option too

@Rseding, I was thinking about a table storing information about the ForceField emitter, this would allow to blueprint custom entities..

Greetings,
lovely_santa

[darkfrei]

It would be nice if entity.custom_table can be also defined in data.lua.
If not defined then nil.

[Rseding91]

It would be nice if entity.custom_table can be also defined in data.lua.
If not defined then nil.

What data from the data stage could you want to transfer into the control.lua stage that you can't just read in the control.lua stage?

[darkfrei]

What data from the data stage could you want to transfer into the control.lua stage that you can't just read in the control.lua stage?

You are right, almost all properties in data stage can be read in control stage, almost all of them have same names (http://lua-api.factorio.com/latest/LuaE ... e_category). What we can't get, will be added by first modding interface request.

I'd like to revive the request for adding a mod_data property to an entity.
Could/would be "just a table" which can be read and written with arbitrary data.

My use-case is the saving of combinator information in the entity to be able to support configured combinators in a blueprint.

Try to explain how it works. I think that saving some information in the entity (or prototype of it) must be defined in the data stage. For example the flag "allow_custom_data = true" will be added by the data stage and then you can add some custom (and global) data to this entity or entity_prototype. It can be "entity_prototype.custom_data.price = integer", and all mods with prices have access to this information. For nuclear items it can be "entity_prototype.custom_data.half_life = integer".

If you delete all mods, that adds flag "allow_custom_data" by data stage, then all information will be deleted.

[eradicator]

The main idea (and why this type of request keeps resurfacing) is that it's currently impossible to store settings for custom entities in blueprints. I've written this before somewhere..., it doesn't require any additional entity data, only a unique id in a blueprint that can be read by a mod via an event handler. I.e, a vanilla constant combinator can safe it's settings in a blueprint, but a mod can not store or restore data to an entity built from blueprint because it doesn not know what entity was originally used to create the blueprint.

The simplest (as in "no frills") way i can think of how this might be implemented:
1) an event is called when an entity is blueprinted, let's call it on_entity_blueprinted. The event contains:
.entity = the entity that was blueprinted
.player_index = the player that did it
.blueprint_stack = the blueprint item stack that contains the blueprint (optional frills)
.entity_number = the position of the entity within the blueprint (optional frills)

2) an additional parameter in the on_built_entity event:
.entity_unit_number = the entity unit number was stored in the blueprint, the mod can now use it to look up the original settings of this entity and restore them


Point 1) is somewhat optional if you want to let modders attempt to dissect a blueprint that contains more than one of the target entity, but it would be much more comfortable to have the info handed out via event. The only use of the data stage here might be to specify a flag "requires_blueprint_id" that must be specified on entites that need this, so it doesn't have to be called for every blueprinted entity.

The important thing is part 2)...getting some sort of id (can be anything, but unit_number already exists) to associate the new entity-ghost to some custom data the mod stored in global.

The non-"no-frills" implementation would be to allow storing arbitrary tables in blueprints so mods don't have to manage UID <-> data associations and also allow blueprints to properly work in another savegame.


What darkfrei wants...can already be implemented with remote interfaces and is entirely unrelated to the blueprint thing as far as i can tell.

[hreintke]

Hi,

I think your solution doesn't fit my usecase.

If there is only an identification, the blueprint can only be used in the savegame in which it is created.

[Senth]

I was just going to request the same feature as I just noticed that I can't save my custom combinator information into a blueprint.

Having a table that's called mod_data, or even just mod_export_data (so that it's only used for blueprints) would be awesome.


Or actually, any solution that lets me add some extra information into a blueprint that can be used when the entity is built.

[hreintke]

@Rseding91

What is your opinon on getting this in the modding interface ?

[hreintke]

Hi,

What is your opinion on this ?
Any chance that this can be added ?

[Hermios]

Hi
I agree on the issue: When native entities are blueprinted, their settings are stored in the ghots, but there is no mechanism to store settings from custom entities.
Existing suggestions seem nice, I vote for mod_data, per entity, those are stored in the saved data too
The +:
- This maintains settings the same way as for native entities
- This avoids to lists each time we have custom entities.
- This avoid to deal with events when creating/applying blueprint
The -:
No minus (Best seller ever!)
And maybe another field, to decide if custom settings should be dispatched to ghosts, when blueprinting. (I wouldn't need it, maybe other would).