Let's overhaul smart belt!

[mmmPI]

you need a key for "force smart belt" maybe ? do not attempt to underground those unless shift is pressed when dragging, then i expect the smart belt to try and make the undergound at the max lengh, possibly removing the yellow belts in the process, but it should stop at the splitter and not jump over nor remove it. Continuing to drag should place a underground entrance right after the splitter and resume mentionned behavior

( from someone who doesn't use smart belt a lot because i don't lke it "yet )

[pantabo1]

130603

i think this post from anti might be relevant

[GlassBricks]

Special Splitter Shenanigans Survey

TL,DR; Which of the behaviors pictured below makes sense to you? How far down the rows do things make sense?

Some spec details
1. Running directly into a curved belt will fail with "curved belt in the way"
- Justification: in absence of failures, smart belt should not change existing belt lines; and we always integrate belt segments we "directly run into"
2. Dragging past a splitter, even with belt after it, will integrate it
- Justification: This is the behavior in previous versions. In the current version, smart belt tries to underground over this, eventually failing due to "underground too long". From surveys it seems people really don't like this new behavior.

09-19-2025, 00-17-02.png (190.5 KiB) Viewed 159 times

MAIN PROPOSAL
3. If a curved belt follow a splitter, try to underground over it, like in the side balancer example below. It's this case, from educated guessing and the grapevine, that I think kovarex wanted to support (but implemented poorly).
- Justification: if you tried to integrate the splitter instead, from item (1) this will fail at the curved belt. This is a rather common case; as such, might be better to underground past it.
Details:
- This only applies if the splitter didn't previously have a belt input (the current game implementation does this).
- To avoid long-distance dependencies, the lookahead is limited to how far the belt might underground over.
- If it doesn't match conditions exactly, the special case does not apply, and we default to integrating the splitter and possibly failing later.

09-19-2025, 00-17-27.png (64.48 KiB) Viewed 159 times

Extension: belt weaving
4. Also look through undergrounds of a different tier (since they're possible to underground over)
5. Possible weird consequence of (4), if there's empty spaces.

09-19-2025, 00-17-37.png (128.54 KiB) Viewed 159 times

Extension 2: blocked underground outputs
6 & 7. Also consider at blocked undergrounds (of a different tier) as eligible for undergrounding over.
- Justification: This is trying to generalizing to ALL cases, where integrating the splitter will fail: In new spec, trying to drag past a blocked underground will fail with "entity in the way".

09-19-2025, 00-20-25.png (115.94 KiB) Viewed 159 times

I'm was originally in favor of behaviors 1-7, but given how convoluted the later ones are, I'm leaning toward 1-5 or 1-3.
What do you think?

[ameateye]

I think that all of these are examples of the same dilemma.

When you have an obstacle - smart belt is trying to go under it, and if it failed - it results in error.

The question is what happens when you face an obstacle after integrating into an existing line.

For this - I believe that.
(1) If you can get over the obstacle while continuing the existing line (without breaking it) - do it.
(2) If it breaks the line - try to go under it from the integration point.
(3) If you can't pass the obstacle - don't connect to the line and send an error sound.

One case that I am not sure about is what to do when connecting to a lane that hits an obstacle with the exit of an underground, but you can go under it by cancelling the underground or pushing it back in the line. This will probably be considered as breaking the line