adding collision layers

[ownlyme]

For modders adding special functionality based on collision layers, it's a nightmare retaining compatibility with other mods.
Can you allow us to add more collision layers so each mod can add its own layer if he needs it?

[Rseding91]

Collision masks are defined using a bitmask on a unsigned 16 bit integer. The 0 value is "none", the 0xFFFF value is "not defined" so that leaves 14 possible values for collision masks.

To make that bigger means every collision mask in the entire game is now bigger - even without mods using any of them.

I know there was talk of doing this but if we ever did increase it, it would only ever increase to a maximum of an unsinged 64 bit integer making for 62 possible collision masks.

[ownlyme]

if you increase it, can you please allocate it from a mod-specified string to a bit in the integer so mods don't have to guess which one is free?
(i suggest doing it in the form of a really simple prototype?)

Code: Select all

{type="collision-layer", name = "modxyz's-layer"}

64 should be more than enough, even 32 would do the trick.
if a mod tries to create a collision layer that would exceed the limit, just throw an error at the user

[Adamo]

For modders adding special functionality based on collision layers, it's a nightmare retaining compatibility with other mods.

What is it you're trying to do? Maybe I could help you come up with a solution that approaches it from a more compatibility-minded angle. There are always options!

if a mod tries to create a collision layer that would exceed the limit, just throw an error at the user

I think I've observed a similar behaviour when mods add too many tiles.

[ownlyme]

- trees that are only plantable in non-desert with the normal "cannot build here" functionality ( https://mods.factorio.com/mod/robot_tree_farm )
- https://mods.factorio.com/mod/CanalBuilder
- https://mods.factorio.com/mod/Hovercrafts
and many more...

[DaveMcW]

An API to request a unique collision layer would be useful even with the 5 layers we have. If more than 5 mods using the API are installed, the last mod shuts down with a warning instead of randomly breaking other mods.

[Adamo]

I noticed that collision_mask can also include "collision options" that are strings but don't correspond to the layers. I tried but I couldn't find an event that perfectly fits this case in which you could easily check for the collision options as the player or bot or whatever attempts to place the tree entity. The only thing I have thought of is that you could do a small control code that kills trees after they are planted in the desert. Sorry couldn't be more helpful. I do know a code we could use that checks all the other mods for existing collision masks, and so you could at least ensure that way you're not racing another mod for the same collision mask. But I assume you have already thought of that, and it would not solve the problem in the case where all existing vanilla-unused layers are used by other mods.

[eradicator]

An API to request a unique collision layer would be useful even with the 5 layers we have. If more than 5 mods using the API are installed, the last mod shuts down with a warning instead of randomly breaking other mods.

+1

I think i've called the current implementation "completely unusable" on several occasions already. The problem is that because every mod author just randomly decides to use any of the free layers (most use the first or the last it seems) i can not guarantee that my code works *at all*, because i have no knowledge or control of other mods layers. Worst case i remember was a mod that wanted to add one of the "free" collision layers to 90% of all ground tiles so that one of their buildings can only be built on sand. (I've wanted tile-type-based placement restrictions since years ago too btw.)

If custom layers were named prototypes then it'd be unlikely enough that mods conflict with each other accidentially while still allowing cross-mod-compatibility if the participating authors so desire.

[Adamo]

In case it is helpful for anyone, here is a bit of code. I confirmed that it doesn't cause a crash, but I haven't integrated it into a mod that uses layers, yet. But it should work fine. If it doesn't, it'll just be because of a typo or simple thing we can fix. For simplicity, it checks far more than just entities for collision_mask (in fact, it checks everything), since there are many data.raw.type types which refer to different types of entities. This shouldn't be a problem.

Code: Select all

function find_unused_layer()
	local unused_layers = {
		"layer-11",
		"layer-12",
		"layer-13",
		"layer-14",
		"layer-15",
	}
	for i,data_type in pairs(data.raw) do
		for j,data_obj in pairs(data_type) do
			for k,layer in pairs(data_obj.collision_mask or {}) do
				for l,unused_layer in pairs(unused_layers) do
					if layer == unused_layer then
						unused_layers[l] = nil
					end
				end
			end
		end
	end
	for _,layer in pairs(unused_layers) do
		return layer
	end
	return nil
end

Run the function in your data_updates.lua or data_final_fixes.lua. It will return the lowest layer which is as yet unused. Then apply that layer to your entities. Something like

Code: Select all

local layer_to_use = find_unused_layer()
if layer_to_use ~= nil then
	if not data.raw.entity["my-entity-1"].collision_mask then 
		data.raw.entity["my-entity-1"].collision_mask = {}
	end
	table.insert(
		data.raw.entity["my-entity-1"].collision_mask,
		layer_to_use
	)
	if not data.raw.entity["my-entity-2"].collision_mask then 
		data.raw.entity["my-entity-2"].collision_mask = {}
	end
	table.insert(
		data.raw.entity["my-entity-2"].collision_mask,
		layer_to_use
	)
	...
	And so on for any entities you want to mask with the layer
else
	-- You're screwed because there are no free layers, act accordingly.
	-- Pick one at random and hope for the best?
	-- Make a forum thread where we share what layer we're using?
end

Not a perfect solution, but it'll get the job done, unless the layers are all used.

[slippycheeze]

To make that bigger means every collision mask in the entire game is now bigger - even without mods using any of them.

...and that'd be an in-memory representation concern, not an on-disk one, wouldn't it? I was trying to work out why, eg, a variable length representation for the value would be a problem since, as long as the collision mask space was dense, you would have the minimum number of bits required.

Then I worked out that you don't want a variable length encoding at runtime, since bitmask comparisons of the encoded values would probably be costly enough to not be worth it. Either you pay for decoding a variable length value first, which isn't super-cheap, or you pay for masking out the tag bits, which again isn't super-cheap. (Though I've not checked the cycle-cost of those, compared to memory latency.)

Yes?

In case it is helpful for anyone, here is a bit of code.

Also, wube staff, if you can, is having "standard" code like this in multiple mods, and/or some sort of reusable library for same, a convincing argument for getting something done? I wonder some if having a proof of the concept is useful or not to convincing y'all to accept something?

[Bilka]

In 1.1 there are now a total of 55 collision masks available to mods.

[ownlyme]

too late, too few.
send me a mail when you let mods add overlays for your game guis.
btw anybody have 0.18.25 for me?

[Klonan]

send me a mail when you let mods add overlays for your game guis.

Overlays, or you mean, like attachments to the game GUIs?
We added the relative GUI system not too long ago:
https://lua-api.factorio.com/latest/Lua ... i.relative
https://lua-api.factorio.com/latest/Lua ... ent.anchor
https://lua-api.factorio.com/latest/Con ... #GuiAnchor

[ownlyme]

send me a mail when you let mods add overlays for your game guis.

Overlays, or you mean, like attachments to the game GUIs?
We added the relative GUI system not too long ago:
https://lua-api.factorio.com/latest/Lua ... i.relative
https://lua-api.factorio.com/latest/Lua ... ent.anchor
https://lua-api.factorio.com/latest/Con ... #GuiAnchor

ah i see, you also implemented "luaguielement.bring_to_front()" ... thank you