Re: Let's overhaul smart belt!

Asking for feedback on dealing with splitters
Here's some cases with splitters, where it might be ambiguous if want to underground over them.

- In the first row, it's reasonable to want to underground over the first bit
- In the second row, from feedback reasonable to _not_ underground over the splitter if there's an existing (long) belt going into it. And upon reaching the curved belt, it fails (doesn't underground) and notifies the user

However, the other rows get tricky, and this is where I'm asking for feedback.
- Do we need different treatment for a _blocked_ splitter, not belt ahead of a splitter?
- What if the belt ahead of the splitter is too long to underground over?

Other questions:
- Do we actually want to take into consideration if there's a curved belt in (distantly) in front of the splitter?
- If we do integrate the existing belt, what happens to the curved belt? Straightened out, or it fails and notifies the user?

The spec currently tries to underground over all rows, due to the curved belt; and fails if it's too long.
The game currently undergrounds if there's no belt in front of the splitter AND there's belt ahead of the splitter (rows 1, 5). It uses existing belt in rows 2,6 and undergrounds over the curve , which from bug reports people might consider a bug. It makes a broken belt in rows 3 and 4. Existing smart belt also doesn't care if there's a curved belt ahead of the splitter, for if it should underground over it; only that there's at least 1 belt ahead of the splitter.
Statistics: Posted by GlassBricks — Thu Aug 14, 2025 3:10 pm