[Dominik][0.17.31] Underground belt direction inconsistent

[AntiElitz]

See video:

https://youtu.be/weKemN7Rtv8

When dragging an underground belt, the direction can be in 2 different states, but look the same to the user, so the behavior appears inconsistent.

[Dominik]

Hey, thanks for the nice report.
When I do what you do, it is not happening to me. But it might have been fixed by a fix of different bug that I did recently. So please, try it again with the next version and let me know if it is still happening or not.

[boskid]

[0.17.34], tested what @AntiElite did. Not fixed.

It looks like there is hidden variable with underground belts that is not reset when changing item from underground or to underground. After overdragging this hidden variable (after 3 toggles) is set so effective underground build direction is opposite to basic direction. Then Anti rotates twice to compensate for this hidden variable being in different state to build underground in correct rotation but inadvertently he changes basic build direction so when changing back to normal belts, they are rotated 180 degrees

[boskid]

Longer description:
- In columns we have "basic build direction"
- belts are built straigt with build direction
- underground belts have hidden variable, "underground build in progress, flip direction for exit" that selects between second and third row

First building direction is north

ub-step-0.png (85.39 KiB) Viewed 2965 times

Then he builds underground up

ub-step-1.png (88.27 KiB) Viewed 2965 times

ub-step-2.png (91.08 KiB) Viewed 2965 times

but then overdrags, and this sets hidden variable "underground build in progress; flip"

ub-step-3.png (95.38 KiB) Viewed 2965 times

removing not shown here because it does not change anything.

To compensate for flipped direction, he rotates twice to restore underground build direction

ub-step-4.png (95.4 KiB) Viewed 2965 times

With this he builds second underground path. This is odd, becuase entrance is built when hidden variable "build in progress" is set, so formally he places exit, but it is drawn with belt going into

ub-step-5.png (96.11 KiB) Viewed 2965 times

Second part of underground is built with hidden variable "build in progress" reset, so formally he builds underground entrance, but it is drawn with belt going out because it connects with other underground part

ub-step-6.png (97.5 KiB) Viewed 2965 times

Then he changes to belts, but he has his basic build direction rotated and belts are opposite direction

ub-step-7.png (94.08 KiB) Viewed 2965 times

Possible solutions:
- reset hidden variable "build in progress" when changing from underground or to underground. This may be not effective if he removes overdragged underground and removed it without switching to belts. This would require resetting this flag also when deconstructing underground (or maybe when manually rotating)
- instead of hidden variable, just use "build direction": every underground flip build direction, so after dragging, build direction would be south so when he compensates for underground being in opposite direction, he would fix belt direction himself

-- edit:

best solution i can find is to not affect build director nor use hidden variable. If player is placing belts in north direction, undergrounds should be always shown as north-entrance except if underground in opposite direction would connect with existing underground-entrance (not if other part is underground-exit pointing south as this would mess with intended north build direction - only entrance below that is same direction as "build direction").
This way:
- after overdragging, placed underground would not affect player state in any way. This would prevent anti to compensate for flipped underground in first place so undeground entrance in second lane would be oriented properly
- normal dragging would still work as all intermediate tiles also connect to underground entrance and can be used for dragging logic
- it would allow horizontal drawing: building north it would be possible to place many underground entrances left to right and then finish all of this by placing exits above, for example from right to left
- it could be used to seamlessly tap underground belts: having blue underground going north[map], when having underground with north direction[cursor] and building within existing underground belt, cursor would first show underground exit and moving cursor up, it would switch back to underground entrance

[DaleStan]

There is no "underground build in progress" variable.
Underground belts are built as entrances unless they, as an exit, would connect to an entrance.

Every time you build an underground, the orientation flips 180 degrees, but it remains an entrance by default. Test this by building a north-bound entrance, and building another one one tile east. Then continue to build more undergrounds in a line to the east. The mouths will flip between facing north and facing south, but every single one of them will be entrances.

Notice that the east-facing-mouth underground in your middle row is an exit, because it connected to the west-facing-mouth entrance. Similarly, all of your third row is entrances, except the south-facing-mouth, which is an exit because it connected to the north-facing-mouth entrance from the middle row.

[boskid]

There is no "underground build in progress" variable.

This is placeholder name for hidden variable. I know that you will always build entrance except if it connects to already placed entrance.

There is however hidden variable that flips "mouth" of underground belt to opposite direction. Because of that, if you build second UB that does not connect to previous one, it will have "mouth" flipped (180 degree, what i called "formally building exit") and it will be entrance giving you belt going in opposite direction of "player build direction" - this is why there is this bug

In my example in "state visualisation", direction of belts within UB is not important - i was not even offseting them to prevent from connecting. Important part is what you called "mouth direction" and to show how it is affected by "ub flip hidden variable". In both cases, if UB does not connect, it will be entrance.

-- edit:

More clearly: issue is based in fact that building UB needs two things changed when building exit: first "mouth" has to be rotated 180 degrees (here lies hidden variable tied to user state), second it must be exit (map state as it will connect to UB-entrance). When you break this sequence by not placing exit, you start to build entrance but it will be 180 rotated against your build direction (that can be seen by switching back to plain belt) - user state rotates UB, but map state does not make it exit (as there is no connecting UB-entrance).

Proposed solution is based purely on this: to move all dependecies to map-state: if you are building north-UB-entrance (belt going north, "mouth" points down/south) but there is already north-ub-entrance below(south), assume this is second part of building UB pair and 1/flip and 2/change to "exit" - this will show(and build) north-ub-exit(belt going north, "mouth" pointing up/north). By removing dependency on user state, there will be no issue when build sequence is broken partway like after overdragging

[DaleStan]

If player is placing belts in north direction, undergrounds should be always shown as north-entrance except if underground in opposite direction would connect with existing underground-entrance (not if other part is underground-exit pointing south as this would mess with intended north build direction - only entrance below that is same direction as "build direction").

I'm tentatively in favor of this. My first reaction was "horribly confusing", but you've clearly thought it through, and I couldn't actually come up with a common situation where it really would be confusing.


Given the following repro, I think you're asking either that the 12-18 behavior does not happen, or that there are some automatic triggers that will switch back to the 2-8 behavior.

1. Put both transport belt and underground belt in your quickbar. (I'm guessing this step can be skipped, but it makes the remaining steps easier.)
2. Put a transport belt in your hand and observe that it transports items to the north.
3. Either with or without clearing your hand, put an underground belt in your hand and observe that it transports items to the north.
4. Rotate the underground belt in any direction.
5. Without clearing your hand, put a transport belt in your hand, and observe that the transport belt moves items the same direction as the underground belt.
6. Rotate the transport belt in any direction.
7. Without clearing your hand, put an underground belt in your hand, and observe that the underground belt moves items the same direction as the transport belt.
8. Repeat steps 4-7 as often as you like.
   ----------
9. Build one underground belt. (Not one entrance and one exit; one entrance and zero exits.)
10. Press the appropriate key to clear your hand. (Q on a English keyboard with default keybindings.)
11. Mine the underground belt, or move your mouse to a location where subsequent experimentation will not be affected by the existing underground belt.
    ----------
12. Put a transport belt in your hand and observe that it transports items to the north.
13. Either with or without clearing your hand, put an underground belt in your hand and observe that it transports items to the south.
14. Rotate the underground belt in any direction.
15. Without clearing your hand, put a transport belt in your hand, and observe that the transport belt moves items the opposite direction as the underground belt.
16. Rotate the transport belt in any direction.
17. Without clearing your hand, put an underground belt in your hand, and observe that the underground belt moves items the opposite direction as the transport belt.
18. Repeat steps 14-17 as often as you like.

[boskid]

Given the following repro, I think you're asking either that the 12-18 behavior does not happen, or that there are some automatic triggers that will switch back to the 2-8 behavior.

Almost right. For completing ub-pair, there must be a condition that will flip UB to form exit when dragging. This flipping (what you call "12-18" behavior) should happen, but only when building exit for UB-pair and should stop as soon as build sequence is not completed (like moving cursor out of line where ub would form exit for just placed ub-entrance). My solution just gives precise condition "when" to flip UB.

my proposed solution does not behave as "12-18" because it has no state related to player (other that build direction and cursor position) - it would decide to flip UB on the fly based on test if flipped UB would form ub-exit with existing ub-entrance

[Dominik]

Hi everybody. I am sorry this is the first response from my side, but I have read all the ideas and we have ran through many considerations here at the office.
Unfortunately it seems that with the underground belts there is not one solution that would work perfectly in all situations - with every solution there is some situation that does not work right or a setup that is impossible to build where it should be.
I really liked the idea to drop the flipping state altogether (yes, there is a variable for it) and only flip the belt when on the cursor is an ub in the same direction as the existing connection and in position from which it can connect. It would allow the independent building of entries and exits which is nice. But it was a close call as there are weird setups it would allow. But then I realized there is a situation where you have two already connected ub (therefore they are in the same direction), you want to build another ub in the same direction in between - what should it connect to, the entrance or the exit? Such unpredictable situation is a no-no.
So I am only doing a small fix somebody proposed that will fix it partially - to drop the flip variable when the cursor item changes. So if you build an ub entrance and then want to start build elsewhere, it will still be in the wrong 180° rotation, but this stay will not persist forever as it does now.

[Dominik]

Hi, sorry for another long delay. There were more crash bugs in the way and more discussing too.
Finally, we have agreed to put this to ice for now. Even the solution I described in my last message (and already wrote too) has it's issues. But more importantly, the building code is very complicated and from history any changes in that lead to ugly bugs. Since this issue is not that big (it definitely is an issue though) and we don't have a perfect solution, it is not worth the risk. It can be addressed if a bigger refactoring of that code happens.
I am sorry if this is disappointing. Thank you all for your help though.