Can't lay parallel tube in techage

[gd2shoe]

There's some sort of bug preventing laying of parallel tubes in techage... at least, not without difficulty. Tubes placed will often immediately disappear. (This also occasionally occurs when trying to place a tube that bridges a gap in a line of tubes, where the new tube placement should be obvious -- but there are indications that this is probably a separate issue).

I think this is a tubelib2 problem, but it could be a techage problem. The issue affects techage pipe, tube, steampipe, cable, and powerline (at a minimum).

I downloaded the latest github techage modpack and added to it the latest github techage and github tubelib2. From there, I added minetest.log calls to try to pick out where the code is flowing.

Since I'm focused on pipes at the moment, I've traced the problem through techage/liquids/liquid_pipe.lua. I assume similar code must exist in the electrical and item transport files. This is what's removing the pipes, when they really should be left where they are:

    after_place_node = function(pos, placer, itemstack, pointed_thing)
        if not Pipe:after_place_tube(pos, placer, pointed_thing) then
            minetest.remove_node(pos)
...

_(Commenting out the removenode line causes less trouble, but some weirdness remains. Pipes placed this way are reluctant to connect to their neighbors.)

This happens because of tubelib2/internal1.lua:

function Tube:update_after_place_tube(pos, placer, pointed_thing)
...
    if dir1 == nil then
        return false
    end
...

Which, in turn, is caused when tubelib2/internal2.lua Tube:determine_tube_dirs exits at the end of the function without returning anything.

I don't know the codebase well enough yet to determine which of these 3 is the problem, or to decide what solutions might be employed without unintended side-effects. _(Reading the context, it seems that techage is relying on certain behavior from tubelib2, and it's not getting back a satisfactory response. It tries to fail safely by removing the offending node and backing out. To me, that says that tubelib2/internal2.lua Tube:determine_tubedirs is probably the culprit. But that's purely a guess.)

[gd2shoe]

Ignore the second issue mentioned. It is completely unrelated, behaving as intended. Turns out to be the deliberate limit on the length of steam pipe. I lost track of that while trying out as many pipes as I could quickly reach. (I suggest a chat message to the player trying to lay a 13th section of steampipe to let them know. It is documented, but it is also an easy thing to overlook.)

The main issue outlined above does apply to steampipes.

[joe7575]

It works for me, but it depends on the direction. You can't place a tube/pipe at 90 degrees to an existing tube. But that's intentional.

https://youtu.be/oHqkTUOOoQo

[gd2shoe]

Hmm. In that case, this is no longer a bug report, but a feature request.

I don't see why the pipe needs to be removed. But if it somehow messes with the pipe network, then I propose that this condition should cause the newly laid pipe to be turned horizontally or vertically so that it is no longer in conflict. Removing it without explanation is confusing and frustrating. This would also make it easier to run overhead piping, or to connect things back behind an obstacle.

---

Oh, and because I forgot up above, I'm enjoying techage. Thank you. There are issues, but I can tell that a ton of work went into this project. It's distributed as a modpack, but it's practically a game all on its own.

[joe7575]

Can you please add the following code after line 328 and try if this patch works for you:

    -- dir1, dir2 still unknown?
    if #tbl < 2 then
        -- Try to turn the node by 90 degrees
        local dir1 = fdir < 5 and (fdir + 1) % 4 or fdir
        local dir2 = dir1 < 5 and Turn180Deg[dir1] or dir1
        if dir1 ~= dir2 and allowed[dir1] and allowed[dir2] then
            return dir1, dir2, 0
        end
    end