Prerequisites

• [x ] I am running the latest alpha version of MineColonies and Structurize for my Minecraft version.
• [x ] I checked the MineColonies/Structurize wiki and made sure my issue is not covered there.
• [x ] I made sure that this issue is not a duplicate of any existing issue.

Context

• Minecraft Version: 1.18.1
• MineColonies Version: 1.18.1-1.0.328-ALPHA
• Structurize Version: 1.18.1-1.0.319-BETA
• Related Mods and their Versions:

Expected behavior

all mine nodes would connect to each other as intended

Actual behavior

The first node from the mineshaft is always built as a straight node. I think the name is minerx2top. Occasionally the miner will build a node off the side of this node, even though it may not physically connect (depending on the schematic). So the actual root node is a minerx2top node, but the internal logic of how the mine interconnects must think it is a minerx3topleft or minerx3topright or minerx3leftright. (Sorry, the naming convention and how the nodes actually connect make no sense to me.) I think it is usually, perhaps always, the version that has a node connecting to the left as you are facing away from the mineshaft.

So the miner will create another node that, depending on the schematic, can't even be reached. I have manually fixed the connection in my game, but I shouldn't have to. Maybe the node physically built in-game is hard-coded to be minerx2top, but connection-logic thinks it could be something else?

This could result in a section of mine that isn't accessible to colonists.

Steps to reproduce the issue

0. Create a mine that uses minerx**** schematics that are all unique so you can identify which schematic was built. Also, it is best if you use a schematic that has a mechanism that points towards the root (mineshaft). For example, torches always placed away from the root/mineshaft.
1. Instruct your miner to mine on a fresh floor.
2. Let you miner mine for a while. Enough that the nodes diagonal from the mineshaft are mined out.
3. Check to see if one of the diagonal nodes from the mineshaft "thinks" it is connected to the side of one of the minerx2top nodes directly connected to the mineshaft.
4. If the bug didn't occur, start over at step 1 above.

Logs

No logs...

Notes

Could someone explain the naming logic of the minerx**** schematics? Maybe explain how to orient, modify, and save them in creative mode? This would be nice to have in the wiki. I got a set to work but it was by trial and error and took a long time. Since there are no anchor blocks, it's difficult to determine how to orient and save them.

Viewers

• Add a thumbs-up to the bug report if you are also affected. This helps the bug report become more visible to the team and doesn't clutter the comments.
• Add a comment if you have any insights or background information that isn't already part of the conversation.

About the naming convention: If you have the exit (back to the mine shaft) at the bottom of the schematic, then the "entrances" (if you get into the node, back to the mine shaft) on the respective sides, top means facing away from the bottom (i.e. straight), left is on the left side (you need to turn right to get to the exit on the bottom) and right on the right side (you need to turn left to get to the exit on the bottom).

INCLUDES STEPS TO REPRODUCE

I was directed to this issue from Discord bugs channel. Not sure if its the same exact problem, because I don't fully understand original description but I definitely found occasional mine node connection error and I'm able to provide steps to reproduce it and most likely explain reasons why it happens (or at least narrow down cause to very small piece of code).

MineColonies Version: 1.18.1-1.0.415-ALPHA
Structurize Version: 1.18.1-1.0.341-ALPHA

• Instead of changing schematic themselves, I've followed the miner for few hours and marked every node entrance and possible exits for few hours. After around 70 nodes queued including 42 fully built and 28 awaiting I've concluded that the problem always happens In 3 way intersections with significant chance (possibly 66,6(6)% as in 2:3) and only there.
• After further investigation I've noticed that ACTUALLY there are no 3 way left-right ┳ or 3 way top-right ┣ intersections. Every three way intersection BUILT in the mine has left turn and path straight ┫ (looking from place parent node to child node). It is hard to notice without keeping track of entrances as the paths often intersect and give false idea of "top-right" or "left-right" intersections (┳ or ┣).
• Here I would like to strongly highlight "BUILT". Every 3 way junction was BUILT to look "left-top" ┫ but is not data-wise. Even though corridor might look like it should connect to the left and top part, miner will queue any 2 out of 3 available exits (entrance direction not included). Data-wise one of all three valid 3-way intersection variants is being picked but it it always built to look like "left-top" 3-way ┫.
• The above will in most cases lead to one of new child nodes of 3-way intersection being built "through the wall" of right turn that was never dug as a proper exit, for example: ┫┛
• Tunnels might still connect later on though other nodes and end up with something looking like ┳ that is actually ┫ that started from right side and went to the left. Example (Fig. 1 and Fig. 2 below), a tunnel that looks like this (first entrance from bottom):
  ┳┓
  ┫┛
  which data wise is actually one of the following:
  ┻┓ ┳┓
  ┳┛ ┣┛
  order of construction:
  4 3
  1 2
  3-way without connecting to the right queues next node to the right, two right turns and another 3-way. Looking from node 1 to 4 it looks like its ┳ junction but its not.
• There is another problem that removes some valid positives and makes it harder to reproduce reliably: if the node to the right of 3-way intersection is already taken, in case of ┳ or ┣ it will take only one of two valid exits and leave second one unused as it was going to be in a place that is already occupied and got skipped. Result will look like ┫ that was for some reason abandoned by the miner and one of the exits was unresolved (Fig. 3)

Solution:
Check is all three variants of 3-way intersection have proper schematic of is just one is used if it is rotated properly while being placed.

TL;DR;
I have never seen miner build ┳ or ┣ tunnel looking from his entry point.
Miner always builds ┫ but expands them into any of ┫, ┳ or ┣
Data-wise all T intersections are fine. NBT and job queue.
Schematic needs proper rotation or 2 more variants.

Testing:
I was able to reproduce exactly the same behavior in the second mine. It was way harder to spot as I just left it going for a while before checking up on it. Reason or pattern would be almost impossible to notice without knowing what I'm looking for.

Reproducing:
It reproduces itself but over longer period of time might be hard to notice as it tends to look like it fixed itself though further connections. Very problematic in shorter period of time though as it often leads to unreachable corridors and forces miner to teleport which might end up under water or in dark cave.

Figure 1
Expected node no. 10 in front was dropped in favor of actual node no. 10 being placed through the wall to the right. Later on tunnel from node 10 meanders twice to the left and into 3-way again.

Figure 2
The same situation from Fig. 1 seen from deeper into the meander. Parent of node 10 hidden in the back behind the corner piece "opens up" to node -32/30 (queued no / executed no) that was supposed to be node -10 (on the right side of the screen, not right side of the tunnel) meanwhile on the left side of the picture the actual node 10 curving in front of its parent.

Figure 3
Parent node opens up to child -54/-37/35 to the left but miner leaves "forward tunnel" untouched (visible to the right on screen). Reason is: second exit should go to the right of entrance (behind the back of player) but space there is already taken by other node (visible on map) and its skipped.

The issue seems to be at

I had tested these individually to make sure each of the cross-roads would align right. I had it differently at first (based on the names) but had to adjust it then

In that case, could it be an orientation issue with one or multiple of those minerx3 schematics? That the orientation of a node is different than the miner expects?

Moobien, Joriom and I did a bit of testing, and it definitely is an orientation issue.

It is already apparent from the way the tunnels are oriented by default, and I could notice the same (wrong) orientation from the way the miner placed the nodes.

The inconsistencies in the nextNode list are also visible in my tests

The torches indicate from which side the miner came when building the node (placed by me after the miner was done with that node), and the red side of the nodes is the way out (pointing towards the shaft, according to the schematic)
It is visible that the minerx3leftright is rotated 90º clockwise from what it should be, and the minerx3topright is rotated 180º from its intended orientation.
The next node code inconsistencies are visible as well, as the miner built straight and to the right of a minerx3leftright node. I haven't seen how the next nodes will connect to the other minerx3 schematics yet

Edit: The minerx3topleft has the next nodes working correctly, the minerx3topright has them on the left and right (coming from the way the miner was building them). So the minerx3topright and the minerx3leftright have the connections to the next nodes reversed.

To solve this, either the schematics need to be rotated 90 and 180 degrees and rescanned, or they should be rotated those amounts in the code (which doesn't seem very easily doable).

WARNING: ALL THINGS LISTED UNDERNEATH WERE TESTED ONLY IN "WOODEN" STYLE

There are bugs in two places: both schematic and code. Both can be patched at the same time by rotation two schematics (minerx3topright 90CCW/270CW & minerx3leftright 180) either in blueprints OR code but it will just mask the bugs with inconsistency. Fixing one will work - but will be nightmare in case it needs looking into in the future. For best results - please fixall.

There is also bug in schematics minerx2left & minerx2right but its already "patched" with inconsistency like one mentioned above so "it works". For best results - please fixall.

Explanation
Problem 1:
All minerx3___ schematics currently are built and scanned facing exactly the same direction: they will all produce look of "topleft" when used by miner in game but nodes queued most of the time will not align with physical looks. According to Moobien: "the fact that they are aligned this way is how its always been and need to be for code to work".
Possible fixes 1:
a) blueprint contents (minerx3topright & minerx3leftright) should be rotated to align with file names
b) blueprints stay missaligned but are rotated in the code (quick bandaid that doesn't require rescanning blueprints possibly for all styles). Inconsistency: file names don't make sense anymore but it works.

Problem 2:
When fix 1a is applied for structures to match the blueprint file name, second bug surfaces.
Whenever minerx3topright file is used, miner places next nodes to the left and right.
Whenever minerx3leftright file is used, miner places next nodes to the top and right.
Possible fixes:
a) code needs to be fixed for new nodes queued to match the used schematic file name
b) quick bandaid: put fixed topright blueprint in minerx3leftright file and fixed leftright in minerx3topright - file names will not match contents, but it "will work" even though inconsistent.

Problem 3:
Whenever miner decides to build right turn (minerx2_) he uses minerx2left blueprint that has right turn schematics in it.
Whenever miner decided to build left turn (minerx2_) he uses minerx2right blueprint that has left turn in it.
Possible fixes:
a) Ask builders to rescan those two with proper rotations and update code to use correct file in correct cases.
b) Use correct file names for each case without rescanning and apply required rotation through code.
Solution a) is preffered as it removes inconsistencies and makes it easier to teach future builders how to make those blueprints. Please read addendum below.

Addendum:
Looking at set of all minerx___ schematics, pattern emerges. They were all designed to be scanned with specific direction in mind: while standing to the west and looking east - player should be looking through entrance inwards into the node. Over time and code changes that rule must have been forsaken or simply forgotten and fixed "that work" were applied without giving it a second thought. Using this occasion to realign four problematic schematics according to the rule would allow giving future builders simple rule to follow: when scanning TOP is EAST. As long as during scanning entrance is from the WEST pointing to the EAST and something doesn't work - it means code problem. If entrance is not to the WEST - its schematic problem. This rule also makes sense coordinate wise, as EAST (TOP) increases X coordinate and SOUTH (RIGHT) increases Y coordinate, so with this positioning carthesian directions stay closely aligned with generally accepted convention about coordinate systems where top-right increases both coordinates.

Thanks to:

• Moobien and his initial schematics modification and slightly foggy and confusing explanations whats the proper direction to scan and use my own schematics in game;
• Train and his extremely valuable input about schematics and code;
• Raycoms for being only slightly inconsistent;

Figure 1
minerx3leftright (where I put "top-right" content) is used to build proper top-right intersection and exit nodes are built in top-right configuration;

Figure 2
minerx3topright (where I put "left-right" content) is used to build proper left-right intersection and exit nodes are built in left-right configuration;

Figure 3
File minerx2right used to make proper left turn with connecting child node to the left

Figure 4
File minerx2left used to make proper right turn with following child node to the right.

All signs visible in the pictures are part of the schematics and were not put by me but by the miner himself.
File used: marks name of the blueprint file;
Facing direction: denotes which direction back of the sign (or front of the player reading it) is facing in the blueprints before they have been scanned