Hey, love the mod, but I am wondering if I am doing something wrong or misunderstanding the mod. The left click to upgrade works exactly as expected, where it stops at each neighboring splitter. However, not sure if it's because of the setup of my base, but whenever I hold shift so it upgrades past the splitter, it seems to be too permissive and tries to upgrade almost the whole base. For example, if I have a iron belt line and the copper belt line, upgrading the iron with shift click also upgrades the copper line. I have default settings on. What could be causing this? I can send some screenshots if needed.

That means that the iron line and the copper line are connected somehow -- shift-click will follow the belt all the way. If, for example, your ore lines end up at smelter stack and have the same coal line connected with splitters, then it'll upgrade both on shift+click. If you are sure the two lines are not connected, then yeah, that shouldn't happen and I'm confused how it could happen. You can send screenshots here or upload them directly on Github.

Not at home right now, will do some further debugging when I can. I have a question though: if I merge line A and line B by splitting off of each with a splitter, and then having each side load a belt (such that the result belt is half A and half B), does marking A for upgrade with shift click mark all of B as well? Shouldn't the "upgrade all" only go downstream and not upstream in the event of a merge like this?

Each belt entity (regardless of type) can have inputs and outputs. I build a graph of connected belt entities when the user calls for an upgrade, and this can consist of multiple paths (e.g., upstream and downstream, or both sides of a splitter). The graphbuilding ends at splitters, when there are no direct feeds (e.g., sideloading), or when there are no more nodes to explore. These default heuristics were determined in initial betatesting from users, and I think I added settings for all the heuristics. If you found a case that isn't, let me know and I'll see if I can make it an option. Shift+click will only end when all nodes are explored and will therefore create a graph of all belts connected to the selected one, which will follow all sideloading belts and splitters in both directions, yes.

So, the use case that I would like to have is the following:

https://i.imgur.com/ePG58O3.png

Having the setup on the left, shift+left clicking (or maybe some other combination) should upgrade all upstream and downstream belts of the main belt line (not stopping at splitters), but not sideloading belts or upstreams of other sides of splitters (as pictured in the right).

I run into this issue frequently when trying to upgrade one specific "lane" of the main bus (eg: upgrade iron lanes but not copper) since I have frequent splitters branching off. Currently, the only way to accomplish this is to manually go through each splitter to mark for upgrade, but this is a bit cumbersome. Shift+left click is instead trying to upgrade my whole base, since most lines connect at one point since I do a lot of half-half belts

I'll have a look to see if I can get a setting to work as you want it here, though it probably won't be before the end of the month. I think it'll probably be a stop on side loading belts, as well as an option to only go downstream from a splitter, but I'm not sure if that'll be what you want. At minimum, I cannot distinguish between input belts for an upstream splitter, i.e., either neither input belt gets upgraded, or both (assuming there are two input belts). It would be easier (and quicker) to implement if you can explain what algorithm you envisage for your use case, i.e., the decisions made in each direction (i.e., upstream and downstream) for a belt and a splitter. I'm assuming that the underground belts would just be treated as a normal belt.

I see, that makes sense. Now that I think about it, regarding upgrading through splitters, I can't think of a clean way to decide which is the "main" line that should be upgraded vs the off-branch that should be ignored. I have some ideas for the algorithm and how to solve this. Would you prefer I raise a PR or something similar with a possible implementation?

You don't have to implement it, pseudocode (or even just a text description) here or as an issue on the git repo is perfectly fine.