Permitting a number for ForceIdentification

[Honktown]

ForceIdentification
force_index was recently added to allow a lightweight version of force.index everywhere modders only cared for the index... but without ForceIdentification allowing the index, this results in it not being useful in some cases.

create_entity can't use it
thing.force_index is a read-only value, so it can't be modified after, which is less convenient/performant than creating with the right force, anyway
player / entity .force = index can't use it

In principle, the index shouldn't be stored and used again without making sure the force is valid and the same, but for local and immediate use it would be alright. I began writing a simple script to test something:

Code: Select all

/c
if not global.inventory then
	local player = game.player
	local surface = player.surface
	local x = player.position.x
	local y = player.position.y

	local chest = surface.create_entity{
		name = "linked-chest",
		position = {x + 5,y},
		force = player.force_index,
	}

	local inventory = chest.get_main_inventory()
	if inventory then
		global.inventory = inventory
		chest.destroy()
	end
end

and Error: Given force is not valid, it must be a string (name of the force) or a LuaForce.

This fits with how the API describes ForceIdentification, which got me thinking "well why doesn't it support an index, anyways"

[lyvgbfh]

It's also worth noting that concepts like SurfaceIdentification and PlayerIdentification already behave in this fashion.

[FuryoftheStars]

I agree with this suggestion, especially considering there are other concepts that already allow the int value.