0.15 entity type additions

[Rseding91]

I wanted to know what kind of entities would work best to facilitate what your mod does through the base game instead of having to do the majority of the logic through the Lua API.

Specifically I was thinking of adding something like these into 0.15:

• An item type that can store any nested arbitrary basic Lua types: number, boolean, table, string and when used to build an entity that data is passed to the entity-built handler.
• Some system for cross-surface fluids
• Some system for cross-surface belts
• Some system for cross-surface power

There are a few ways I could do the last 3 items (they're pretty much all the same concept):

• A new entity type that can be set as input or output and has to be connected through script to the other end at which point it teleports the resource to the receiving end
• Some system that would take 2 of a given entity type and teleport the resource from one end to the other (no new entity type - just managing the teleport connections)

Both methods have an advantage but maybe there's something else that would work even better that you might have in mind.

[MagmaMcFry]

Oh wow, that's awesome! I would appreciate those things a lot!

That first option would help a lot regarding collected factory buildings (see my reply to your other comment). I guess there's a bunch of choices for implementation details with pros and cons though. I suppose you've thought about this already, but here's my thoughts about this:

• To avoid a bunch of potential issues with stacking and unstacking, and to discourage mods from just smacking data onto every item, I would suggest making items with data unstackable, or even better simply adding a new item-with-data item prototype class that doesn't even have a stack size attribute. You could then give the item-with-data some bonus features like labels or grids or inventories or blueprint icons as well, so modders can make the data visible on the item.

• Mods push around items a lot, so more caution needs to be taken not to lose item data. There will need to be more API methods that return LuaItemStacks (especially for transport belts), or as a faster and cleaner option there could be API methods that simply push item stacks around between inventories (LuaInventory::move_items_to{target = [other_inventory | other_control], [source_slots = {from = 1, to = 10}], [target_slots = {from = 1, to = 100}], [respect_filters = yes|prefer|no]}). Without these methods, mods may simply lose or wipe the item data by negligence.

• Of course there should also be a way to put data into the item that drops when a building is mined, or generally be able to specify additional mine results in the on_*_mined events. I've run into a lot of issues while trying to make that happen in on_robot_pre_mined, and the only solution I've found so far is to change the entity type as soon as the entity is marked for deconstruction.

Regarding the cross-surface teleporters: I'd personally prefer the second option, because it's easier and cleaner to Lua-code the first option using the second than vice versa. Here's how I would attempt to implement it:

I'd add internal features to transport lines, fluid boxes and electric poles that allow you to add virtual connections from one transport line to another, or between two fluid boxes (allowing to select between balancing and one-way connections), or between electric poles (maybe also allowing to specify the transfer direction, if that even makes sense with electric networks).

These features could then be exposed in the API, and the API methods could return a Lua object acting as a handle to the connection, providing a disconnect() method for the modder.

[Rseding91]

•To avoid a bunch of potential issues with stacking and unstacking, and to discourage mods from just smacking data onto every item, I would suggest making items with data unstackable, or even better simply adding a new item-with-data item prototype class that doesn't even have a stack size attribute. You could then give the item-with-data some bonus features like labels or grids or inventories or blueprint icons as well, so modders can make the data visible on the item.

At the moment I made an "item-with-tags" item type that includes the label functionality. It works similar to the item-with-entity-data type in that it can stack unless the tags differ then the game won't stack them.

•Mods push around items a lot, so more caution needs to be taken not to lose item data. There will need to be more API methods that return LuaItemStacks (especially for transport belts), or as a faster and cleaner option there could be API methods that simply push item stacks around between inventories (LuaInventory::move_items_to{target = [other_inventory | other_control], [source_slots = {from = 1, to = 10}], [target_slots = {from = 1, to = 100}], [respect_filters = yes|prefer|no]}). Without these methods, mods may simply lose or wipe the item data by negligence.

There already exists LuaItemStack::set_stack which can take other LuaItemStacks and will clone them fully. I extended most places that take the simple variant to also take the LuaItemStack variant so in 0.15 you can do something like: entity.insert(entity2.get_inventory(...)[2]) and it will clone the item in slot 2 of entity 2 and insert it into entity 1.

I also added the ability to read LuaItemStacks from transport lines with some conditions: changing the transport line will invalidate any references to the transport line items. That includes the belt moving the items or inserters taking/adding items so really it's only useable in the immediate instance you get the reference - but it still works.

•Of course there should also be a way to put data into the item that drops when a building is mined, or generally be able to specify additional mine results in the on_*_mined events. I've run into a lot of issues while trying to make that happen in on_robot_pre_mined, and the only solution I've found so far is to change the entity type as soon as the entity is marked for deconstruction.

This is a problem we have in the core game as well. There's currently no good way to say "when this entity is mined the result item should include X data about the entity" - everything we do now is what I'd call "hacks that work". I'll have to put more thought into this one.

I'd add internal features to transport lines, fluid boxes and electric poles that allow you to add virtual connections from one transport line to another, or between two fluid boxes (allowing to select between balancing and one-way connections), or between electric poles (maybe also allowing to specify the transfer direction, if that even makes sense with electric networks).

The way it would have to work would be completely external from the entities so it wouldn't impact normal entity performance. Probably something stored in the force data that does the teleporting between given entities. I'll need to put more thought into this one as well before I do anything.

[Rseding91]

I spent some time today and got a working system that should fix the mined-entity problem: eventing the result items from mining any given entity allowing anyone listening to the event to modify the items as they see fit and then when the event finishes the items are transferred into the player.

[MagmaMcFry]

Neat! Does this work for robots too?

[Rseding91]

Yes