Check collisions on all layers when underground_collision_mask used

[LazyManiac13]

Currently underground_collision_mask used in underground belts and pipes check collisions with tiles only and colliding_with_tiles_only is ignored.
My request is to allow underground_collision_mask checking for collisions on all layers if colliding_with_tiles_only setting in prototype is explicitly set false, having colliding_with_tiles_only = true by default in underground_collision_mask

I already reported this as a bug, but it woks as intended. Now I repost it as a feature request.

Code: Select all

  {
    type = "pipe-to-ground",
    name = "test-pipe",
    fluid_box =
    {
      pipe_connections =
      {
        { direction = defines.direction.north, connection_category = { "default", "test-pipe" }, position = {0, 0} },
        { direction = defines.direction.south, connection_category = "test-pipe", position = {0, 0} },
        {
          connection_type = "underground",
          direction = defines.direction.south,
          position = {0, 0},
          max_underground_distance = 10,
          underground_collision_mask =
          {
            colliding_with_tiles_only = false,
            layers = 
            {
              object = true,
              -- is_object = true,
              -- is_lower_object = true,
              water_tile = true,
              empty_space = true,
              lava_tile = true,
              -- ground_tile = false,
              -- floor = false,
              -- transport_belt = true,
            },
          },
        },
      },
      hide_connection_info = true
    },

[boskid]

No. This feature was added specifically for tiles only because we do not want to include entity searches for underground connections collision checks.

There are two sides of the underground collision mask thing and they both must agree: when a pair of undergrounds is placed they check for colliders in between, but there is the second side: when a tile changes in between, it needs to find undergrounds that could be affected by that tile change and possibly disconnect them. Both of those pieces of logic must be done correctly otherwise a desync may happen: underground belt connections for example are not save-loaded so if a change in tiles would not break the connection then a server could see undergrounds as still connected but a client joining would try connect undergrounds, would see a colliding tile, connection would not be made and a desync would happen. Its not just adjusting the connection logic to reject a connection, it is the other end that is more critical here: making sure that changes in the world are able to break existing connections. If a flying robot would be set to have a collision mask that is able to block an underground connection, then every time such robot moves around it would have to perform 2 critically important entity searches for a relatively large areas of the surface to find if there are pipes and undergrounds possibly having their connection affected by it and for each of them do another connection check to verify if connection should be kept or disconnected. To make it even worse, previous position where a robot was would also need to be checked to find undergrounds because they could be in a state where they need to reconnect again. If all flying robots would have to search surface multiple times in large areas every time they move just because there could be an underground connection possibly affected by it, the performance of them would just go down, same with any other entities that can move around (like biters).

underground_collision_mask was specifically implemented for tiles and we will not extend this feature to also account for entities.

[LazyManiac13]

Thank you for the explanation, boskid.

But... what stops me from making such flying robot now? If I set it's collision mask to have lava_tile for example.

[boskid]

Nothing stops you from doing that, but it will be simply ignored: flying robots will not cut the undegrounds when flying, and undergrounds when checking for connection will not see flying robots because underground collision check only checks tiles - both sides of this feature agree in ignoring entities.

[LazyManiac13]

If I understood you correctly the said check traverse only tiles and adding any other layers to underground_collision_mask is just pointless. And you used underground_collision_mask on build time because with base underground belts and pipes it is the same.
Can we then have another collision mask which will be checked on build time only?

Or, preferably, the sane way to cancel build of the object in runtime if it fails collision or any other checks. And to signal player that is will not build. But that is another topic.

[boskid]

Can we then have another collision mask which will be checked on build time only?

No. You seem to be not understanding what i said about non save loaded connections and desyncs.

[LazyManiac13]

Another collision mask I asked for is completely unrelated to undergrounds. I currently writing long-pipe mod and try to use as much from game engine as I can. Pipe-to-ground building interface seems to fit my needs. My mod will build actual entities between pipe-to-ground ends, and on mining all pipe will be deleted. So I don't care about underground connection, I can even replace entities on pipe ends in on_built_entity to one that don't have underground connection at all. Unfortunately, I can't get this interface if I remove underground connection from pipe-to-ground prototype.

What I actually need is a user interface I can use in my mod to build compound objects, with collision checks and all this stuff. Maybe it already exists, and I just don't know about it?

[robot256]

What I actually need is a user interface I can use in my mod to build compound objects, with collision checks and all this stuff. Maybe it already exists, and I just don't know about it?

You can always hand code placement visualizations that only appear when the players cursor stack is your item. We do that in Cargo Ships to show where pumps can be placed.

[LazyManiac13]

What I actually need is a user interface I can use in my mod to build compound objects, with collision checks and all this stuff. Maybe it already exists, and I just don't know about it?

You can always hand code placement visualizations that only appear when the players cursor stack is your item. We do that in Cargo Ships to show where pumps can be placed.

Quoting myself

... try to use as much from game engine as I can. ...

Now I use my own pipe-to-ground item in hand to utilize game engine pipe-to-ground build interface.
But it seems that it gives more problems than it solved. Now I will have to hand code visualization as you suggested.