[2.1] Let a script-only linked-belt opt out of self-collision so several can share a tile

[Techrocket9]

TL;DR:
In 2.1's transport-belt-connectable collision mask validation, please allow a linked-belt prototype to waive only the "must collide with itself" half of the check, for example by honouring the existing not_colliding_with_itself flag, while keeping the pairwise "must collide with every other belt-connectable" requirement exactly as it is.

Background:
I'm the author of Better Belt Balancer. boskid posted an exact writeup of why it loads on 2.0: the validation's already-checked cache compared collision masks by layers only, ignoring flags, so my linked belt (default belt layers plus not_colliding_with_itself) skipped the check while the flag was still honoured at runtime. The 2.1 CollisionMask rewrite fixed the compare, and on 2.1.14 the mod fails data-stage validation with:

Code: Select all

entity prototype "bbb-linked-belt" (linked-belt) collision_mask(Modifications: Better Belt Balancer) must collide with entity prototype "bbb-linked-belt" (linked-belt) collision_mask(Modifications: Better Belt Balancer).

Fair enough: the 2.0 behavior is a loophole, not an API. This thread is the request for a sanctioned way to do this.

In 2.1.14 the validation requires every belt-connectable to collide pairwise with every other one, so disjoint custom-layer variants fail against each other, and neither create_entity nor teleport will place a second belt-connectable on a tile at runtime -- there doesn't seem to be a feasible workaround.

The use case:
The mod compiles balancer clusters at build time into networks of real splitters and belts on a hidden surface, so the steady state runs no Lua at all; the engine does all the work. Each edge (a player's belt adjacent to a balancer part) gets a hidden, script-placed linked belt standing on the part's own 1x1 tile, crossing to the hidden surface. A part with an input belt on one side and an output belt on another therefore needs two linked belts on its tile, and the worst case is four (one per side). This is the common case for a belt balancer mod: the smallest balancer, one belt in and one belt out through a single part, already needs two.

The ask:
Honor not_colliding_with_itself in the validation: waive only self-collision, keep the pairwise requirement. This is exactly what 2.0 de facto allowed, turned into a declared opt-in, and gating it to hidden or otherwise non-player-placeable prototypes would fully cover this use case. Alternatively, provide a new explicit opt-in property. Linked-belt only would be enough; I don't need it for belts, splitters or loaders.

Thanks to boskid for the heads-up; it's the reason I know exactly what to ask for.

[boskid]

This check exists for a reason: we do not save belt to belt connections, which means when a save file is loaded all belts must connect to correct neighbours in order for the game to not desync nor explode on inconsistent transport line groups. Right now loaded belts connect to correct neighbours because there is only one belt connectable allowed at each tile. If multiple linked belts were allowed on the same tile it would be possible for the mentioned problems to appear. For this loophole to be reopened as an officially supported feature the entire logic of how belts connect to each other would have to be changed by saving connections and revisiting all bits of code if they account for presence of multiple belt connectables at one tile. In your mod if linked belts were at any point rotated such that overlapping pair of them would have belt connection on the same side, it would explode, and this includes player rotations as well as script rotations.

I wont reject this interface request but it has no priority for me because of complexity to make it properly supported feature.

[Techrocket9]

Understood. I have reworked the mod around the one-connectable-per-tile invariant for now (and tested/released for 2.1); if this API is ever implemented, I will restore the original functionality.

Btw, in case it would make the API request more palatable: the mod would be equally well served if the engine simply refused any placement or rotation that would give two overlapping connectables a belt connection on the same side — per-side uniqueness was a constraint my mod already enforced on itself, which is the case you identified as the one that explodes.