configuration data of blueprinted entity

[hreintke]

Hi,

I am working on a mod that alows for (lua) scripted combinators.
That means that every scripted-combinator can have a different functionality, depending on the loaded script.

When blueprinting the scripted-combinator, I would like to keep that script/functionality.
I know of the on_player_setup_blueprint and get_blueprint_entities() options.

But is there a way that I can I store/save the (mod) configuration data of the blueprinted entity that I then can use when there is a on_robot_built event ?

[DaveMcW]

Use type="constant-combinator" to store data.

[eradicator]

No. There is no proper method to store additional data in blueprints. You have to abuse existing prototypes to hackywacky store your data and hope it works. The speaker can supposedly store some medium length strings, not sure how flying text works with blueprints.
I'm having the exact same issue currently, and the only semi-acceptable way i could come up with is to store a UID in one of the BP entities and store the actual script in LUA, which ofc means that BPs created that way only work in the savegame they are created in. :x

[hreintke]

Thanks for the info.

Bad luck that this also needs hacking.
Would be nice if there was some kind of custom data possible in several parts of the modding interface.

[golfmiketango]

This is causing me all sorts of pain too.... I think, based on crash-dump-spew-based evidence I happen to have stumbled across, that there is an interface in C++ that entities can override, as needed, to specialize their representation in blueprints.

It's not hard to think of good reasons the devs might not be ready to expose that interface to lua just yet, but it's reasonable to hope that in the fullness of time some kind of enhancements in this area will emerge. Just a single "mod_metadata" string that could persist with nontrivial Entities could make a world of difference -- I'm sure some sort of convention could be quickly worked out between mods to cooperatively share such a thing without messing up each other's secret sauce. But even that might be a pretty big ask since, for example, various hard-coded tables could be completely full meaning even just adding one pointer requires a total rewrite of some huge codebase (and being so focused on optimization I'd bet there is indeed stuff like that lurking in the code).

[hreintke]

I've been looking whether a kind of module approach could help.

Tried to :

Code: Select all

local sce = table.deepcopy(data.raw["constant-combinator"]["constant-combinator"])
sce.name = "scripted-combinator"
sce.minable.result = "scripted-combinator"

sce.module_specification = {
        module_slots = 2
      }
sce.allowed_effects = {
        "consumption",
        "speed",
        "productivity",
        "pollution"
      }
data:extend({sce})

This doesn't throw an error when loading but when running

Code: Select all

/c    for name, prototype in pairs(game.entity_prototypes) do
        if prototype.module_inventory_size  then
            game.player.print(name)
        end
    end

It doesn't show up.

Are modules limited to specific types or did I miss something in the definition ?

[golfmiketango]

Are modules limited to specific types or did I miss something in the definition ?

Don't know for 100% sure but I'd expect them to be limited to specific types.

[eradicator]

You can't add arbitary new properties to prototypes. Every prototype can use exactly the properties it is already using. Also not sure what you expect to be doing with modules but if you want modules just use a beacon.