Page 1 of 1

[Solved] create_entity behavior - preserving inventory and filters

Posted: Mon Oct 12, 2020 5:52 pm
by rookhaven
Does anyone have any ideas why the surface.create_entity function would preserve inventory and filters on one deep copy, and not on the other? In a script, I am using surface.create_entity to replace an entity with an 'upgraded' version. The upgrade just has double inventory.

I'm doing this same process for two different entity upgrade sets. The entities I'm beginning and replacing with are deep copies of logistic requester chests as follows:

Code: Select all

ent = util.table.deepcopy(data.raw["logistic-container"]["logistic-chest-requester"])
ent.name = "k2cp-resort"
...
ent = util.table.deepcopy(data.raw["logistic-container"]["k2cp-resort"])
ent.name = "k2cp-resort-mk2"
...
ent = util.table.deepcopy(data.raw["logistic-container"]["logistic-chest-requester"])
ent.name = "k2cp-city"
...
ent = util.table.deepcopy(data.raw["logistic-container"]["k2cp-city"])
ent.name = "k2cp-city-mk2"
...
My create_entity logic looks like this and is used for both.

Code: Select all

	local new_entity = old_object.state.entity.surface.create_entity
		{ name=new_object
		, target=old_object.state.entity
		, position=old_object.state.entity.position
		, direction=old_object.state.entity.direction
		, force=game.forces.player
		, fast_replace=true
		, player=player
		, raise_built=false
		, create_build_effect_smoke=false
		, spawn_decorations=false
		}
The issue I'm having is that in the case of one building upgrade (resort to resort mk2), the replace preserves inventory and the logistic filters are carried over correctly using the logic above - which is what I want to happen. In the case of the 2nd building (city to city mk2), the replace destroys the inventory and does not carry over the logistic filters even though it's using the same logic.

I tried to use this in the create_entity function to carry over the filters, which worked slick as u please, but then it seems to invalidate the entity itself which causes issues downstream?

Code: Select all

request_filters = old_object.state.entity.get_logistic_point(defines.logistic_member_index.logistic_container).filters
Any ideas? If I need to paste the full entity definitions or other code, please let me know. Thanks.

Re: create_entity behavior - preserving inventory and filters

Posted: Mon Oct 12, 2020 6:09 pm
by eradicator
Did you set the fast_replaceable_group correctly on all entities? Typos?

Re: create_entity behavior - preserving inventory and filters

Posted: Mon Oct 12, 2020 10:49 pm
by rookhaven
eradicator wrote: Mon Oct 12, 2020 6:09 pm Did you set the fast_replaceable_group correctly on all entities? Typos?
  • I hadn't explicitly changed it, so it should have copied over as "fast_replaceable_group = "container"," from the original.
  • So I added that in explicitly and left it as container - no change in behavior.
  • Then I tried it with the crafting category that makes them - no change in behavior.
  • I also tried explicitly setting the next_upgrade attribute. No change.
The results are consistently reproduceable so there must be something I can't find. If I could just get the filters to copy consistently I'd be good with it.


Here are the full entity copies.

Code: Select all

-- City Center
ent = util.table.deepcopy(data.raw["logistic-container"]["logistic-chest-requester"])
ent.name = "k2cp-city"
ent.minable = {hardness = 0.2, mining_time = 0.5, result = "k2cp-city"}
ent.max_health = 400
ent.collision_box = {{-2.2, -3.4}, {2.2, 3.4}}
ent.selection_box = {{-2.3, -3.5}, {2.3, 3.5}}
ent.icon = "__CityPeeps__/graphics/icons/city.png"
ent.icon_size = 64
ent.animation =
	{
	  filename = "__CityPeeps__/graphics/entities/city.png",
	  width = 228,
	  height = 228,
	  scale = 1,
	  shift = {0, 0}
	}
ent.inventory_size = 60
ent.order = "c"
ent.next_upgrade = "k2cp-city-mk2"
data:extend({ent})

-- City Center Uprade MK2
ent = util.table.deepcopy(data.raw["logistic-container"]["k2cp-city"])
ent.name = "k2cp-city-mk2"
ent.inventory_size = 120
ent.max_health = 2400
ent.order = "d"
ent.next_upgrade = nil
data:extend({ent})

-- Resort
ent = util.table.deepcopy(data.raw["logistic-container"]["logistic-chest-requester"])
ent.name = "k2cp-resort"
ent.minable = {hardness = 0.2, mining_time = 0.5, result = "k2cp-resort"}
ent.max_health = 1200
ent.collision_box = {{-2.4, -3.4}, {2.4, 3.4}}
ent.selection_box = {{-2.5, -3.5}, {2.5, 3.5}}
ent.icon = "__CityPeeps__/graphics/icons/resort.png"
ent.icon_size = 32
ent.animation =
	{
	  filename = "__CityPeeps__/graphics/entities/resort.png",
	  width = 214,
	  height = 214,
	  shift = {0, 0}
	}
ent.inventory_size = 24
ent.order = "g"
ent.next_upgrade = "k2cp-resort-mk2"
data:extend({ent})

-- Resort Upgrade MK2
ent = util.table.deepcopy(data.raw["logistic-container"]["k2cp-resort"])
ent.name = "k2cp-resort-mk2"
ent.inventory_size = 48
ent.max_health = 2400
ent.order = "h"
ent.next_upgrade = nil
data:extend({ent})

Re: create_entity behavior - preserving inventory and filters

Posted: Mon Oct 12, 2020 11:03 pm
by DaveMcW
rookhaven wrote: Mon Oct 12, 2020 5:52 pm

Code: Select all

	local new_entity = old_object.state.entity.surface.create_entity
		{ name=new_object
		, target=old_object.state.entity
		, position=old_object.state.entity.position
		, direction=old_object.state.entity.direction
		, force=game.forces.player
		, fast_replace=true
		, player=player
		, raise_built=false
		, create_build_effect_smoke=false
		, spawn_decorations=false
		}
I don't like the hard-coded force. You should use force=old_object.state.entity.force

Re: create_entity behavior - preserving inventory and filters

Posted: Mon Oct 12, 2020 11:16 pm
by rookhaven
DaveMcW wrote: Mon Oct 12, 2020 11:03 pm I don't like the hard-coded force. You should use force=old_object.state.entity.force
I changed it. ;)

Re: create_entity behavior - preserving inventory and filters

Posted: Mon Oct 12, 2020 11:41 pm
by rookhaven
Figured it out. I was scripting my cities as non-minable and the replace was putting the new version on the old and leaving the old there. Wasn't aware that was even possible. Thanks all - marking solved.