A new prototype type to describe compound entities?

[mrudat]

It could be useful to have a new prototype that can encode the components of a compound entity (one where a proxy object is built, and immediately replaced with a set of other entities).

As an example use-case, it is not possible to create a Battery powered Cargo Ship without explicit support from both mods (bug report on how Battery Pack doesn't work with Cargo Ships).

Battery Pack needs to know that a Cargo Ship consists of the visible cargo ship (a wagon) and a Ship Engine (an invisible locomotive) and that it is placed by a proxy entity so that when deriving battery-powered locomotives, it knows that it needs to also create a new proxy entity, to which the recipe it creates is associated.

Cargo Ships needs to know that a new proxy entity has been created and that it consists of the regular cargo ship, and a battery-powered ship engine.

At present, the only way to do this is to encode specific knowledge about Cargo Ships into Battery Pack, and about Battery Pack into Cargo Ships.

If there was a method to describe a compound entity that is shared between data and control stage, it should make doing something like the above significantly simpler.

I figure something like:

Code: Select all

data:extend{
    {
        type = "compound-entity",
        name = "battery-powered-cargo-ship",
        control_script = "cargo-ships",
        proxy_entity = "battey-powered-cargo-ship",
        components = {
          {
            name = "battery-powered-ship-engine",
            amount = 1
          },
          {
            name = "the-visible-cargo-ship",
            amount = 1
          }
        }
    },
    {
        type = "compound-entity",
        name = "gun-turret-with-piercing-rounds-magazine",
        control_script = "LoadedTurrets-0_18",
        proxy_entity = "gun-turret-with-piercing-rounds-magazine",
        components = {
          {
            name = "gun-turret",
            amount = 1
          },
          {
            type = "item",
            name = "piercing-rounds-magazine",
            amount = 10
          }
        }
    }
}

• proxy_entity - the proxy entity that the player places
• control_script - an arbitrary string to associate a given compound-entity with the control script that implements it.
• components - an ingredients list that accepts entities (by default), but also items and fluids (if explicitly specified).

control-code usage would be something like:

Code: Select all

local my_compound_entities = game.find_compound_entities_filtered{ control_script = 'my-tag'}

local my_entity_filter = {}

local my_entity_lookup = {}

for _,compound_entity in pairs(my_compound_entities) do
  local proxy_entity_name = compound_entity.proxy_entity
  table.insert(my_entity_filter,{
    type = "entity-name",
    name = proxy_entity_name
  })
  -- determining which components of compound_entity go where, and recording them for later use goes here.
  my_entity_lookup[proxy_entity_name] = compound_entity
end

local function build_compound_entity(event)
  local entity = event.entity
  local entity_name = entity.name
  local compound_entity = my_entity_lookup[entity_name]
  if not compound_entity then error() end
  -- magic (creating and configuring entities) goes here.
end

script.on_event(defines.events.on_player_built_entity, build_compound_entity, my_entity_filter)

[eradicator]

+1 for compound entity support in general.

But i don't think it'll solve the battery-ship problem. And i don't think it needs a new type. It'll need to inherit base behavior anyway, so all i really want is build-in automatic handling of simultaenous build/destroy.

Code: Select all

{
  name = 'my-fake-loader',
  type = 'simple-entity',
  children = {
     {name = 'inserter, offset = {1,1}},
     {name = 'chest', offset = {1,0}},
     -etcpp
     },
  }

Seeing that wube's stance on wire-in-blueprints changed, maybe there's now a tiny tiny chance of the "no compound entities" stance changing too...

[mrudat]

I think you would basically need the equivalent of, or perhaps precisely, a blueprint string to make that work, including the ability to specify sub-tile locations, circuit connections, etc.

[Rseding91]

This along with the other request seem too much like a hack than a proper or even partial solution for compound entities. At their core compound entities don't work; I don't want to tack on some bits and bobs without thinking through if it's actually going to help the situation.

[eradicator]

I don't want to tack on some bits and bobs without thinking through if it's actually going to help the situation.

Does that mean you *will* think it through?

From my perspective - i.e. even without the need for cross-mod-compatibility - the biggest headache is making sure that the different entities of a "compound" are never destroyed/created independantly. As far as i can tell Miniloader had the same problem at least at the beginning - other mods destroying the parent or whatever and leaving (invisible) orphaned children on the map. So from my POV a guarantee that parent/children can't be created/destroyed/teleported/rotated/etc independantly would be a huge step forward in engine support. Ofc ideally the children wouldn't even be api-accessible as independant entities (UI/UX still needs to be independant) and would have to be accessed via the LuaParentEntity.children = {list,of,LuaChildEntity} or something.