3x & 5x Rail Bug & Solutions

[xxprimarchx]

The core problem with the current 3x and 5x multi‑rail “bug” in Star Rupture is that the routing and merging logic treats multi‑rails as if they were mostly single‑lane connections, which collapses their theoretical throughput and causes odd behavior after changes or reloads.

What is happening technically
The game appears to pick a single “shortest path” rail inside a multi‑rail segment and heavily prefers it, instead of load‑balancing traffic across all lanes. This leads to one rail saturating while the others are underused or idle, so a 3‑ or 5‑lane block behaves like a 1‑lane block in practice. When several inputs and outputs share the same destination (for example, a 5‑in, 5‑out setup feeding the same storage or depot), the system often merges all inputs onto a single output rail, effectively turning a multi‑out into a 1‑out and cutting advertised throughput down to a fraction (e.g., 1/5 of what players expect on 5‑rails). The routing algorithm does not consider congestion; it only cares about geometric distance. Items keep choosing the same “shortest” internal rail even when it is overloaded, instead of hopping to a free lane in the same multi‑rail, which is why you see lanes visually and functionally overstuffed while others stay empty.
​
3x rail–specific issues
Players report 3x rails working “fine” initially, but breaking once you modify nearby junctions or reload a save, at which point all traffic falls back onto a single lane or a single input of a 3‑to‑1 converter. A 3‑rail bus that should behave like a proper 3‑to‑3 or 3‑to‑many system instead degenerates into a faulty 3‑to‑1 merger: only one lane really carries the load, so any setup trying to exceed one lane’s capacity (e.g., >240/s of one item type) will stall or underperform.
​
5x rail–specific issues
The same logic scales up badly on 5x rails: a 5‑input, 5‑output layout feeding common destinations is internally treated much closer to “5‑in, 1‑out.” Only one exit rail is used consistently, and the rest act as dead lanes or occasional spillover. This means that a 5‑rail “highway” cannot actually deliver its theoretical total throughput for a single item type or for multiple items that share the same preferred path, because everything is funneled down to that one shortest‑path rail.
​
Save/load and visual “jumping”
Several reports note that before saving, multiple lanes are used (though still not perfectly balanced), but after reloading, items suddenly all travel on a different single lane (often the middle) and may even appear to swap left–right–middle then back to left while moving along a long segment. This lane‑hopping is not just cosmetic: in many cases it corresponds to the routing graph “forgetting” alternative valid lanes, leading to real throughput loss or jams, not just a visual shuffle.

Overall deduction
Putting all this together, the “3x and 5x rail bug” is not one small glitch but a systemic problem in how the pathfinder handles multi‑rails: it over‑collapses multi‑lane segments into effectively single‑lane paths, fails to load‑balance, and can partially corrupt its internal routing state after edits or reloads, which explains the lane piling, inconsistent behavior, and massive gap between theoretical and actual throughput on 3x/5x rails.

In Star Rupture right now, the 3x and 5x multirails are a whole mess because the game doesn’t really treat them like true multi‑lane highways. On paper you’ve got multiple lanes, but the routing logic usually picks one “favorite” lane and shoves almost everything down it, especially after you edit the network or reload a save. That’s why you see that lane‑swapping weirdness and why your actual throughput ends up way lower than what those rails should be able to handle.

Under the hood, the game’s pathfinding tends to lock onto a single shortest‑path lane inside any multirail section instead of spreading items across all lanes. So one lane gets slammed while the others are basically just for show. If you build something like a 5‑in, 5‑out setup feeding the same depot, the game effectively turns it into 5‑in, 1‑out, and your real throughput tanks compared to what the UI suggests. Because the code doesn’t care about congestion—only distance—items keep choosing that same lane even when it’s overloaded, so you end up with one packed track and a bunch of empty ones. With 3x rails, that usually shows up as a bus that works early on, then falls apart once you tweak a junction or reload; everything collapses onto one lane and anything above that lane’s capacity just stalls. On 5x rails it’s the same story, just bigger, so your “highways” never hit their supposed max because everything keeps getting funneled down that one preferred lane.

The save/load behavior makes it even more noticeable. Before you save, you might see items using several lanes—maybe not perfectly, but “good enough.” After you reload, suddenly everything decides to ride a different single lane (often the middle), and you’ll watch stuff hop left‑middle‑right down a long stretch. That’s not just a visual bug; the routing system can basically forget that the other lanes are valid options, which cuts your real throughput and can cause parts of your factory to stall. People playing with 3x rails say that after loading, those sections behave more like janky merger/splitter blocks: anything can go in and out anywhere, but the shortest‑path bias still forces everything onto one lane. That’s why a lot of folks see this as a deep systemic issue with how multirails are modeled in the pathfinding and pull‑based logistics, not just a little rendering hiccup.

Since you can’t fix the core algorithm yourself, the community has more or less shifted into “work with the bug” mode. The big takeaway is: don’t treat 3‑lane multirails as stable 3× throughput buses. After you save or change the network, they effectively turn into fuzzy merger/splitter zones where one lane takes over, so true 1→3 or three independent lanes just aren’t reliable yet. The usual advice is to use multirails mainly as 3→1 mergers and let dedicated splitter buildings handle the fan‑out, because those aren’t subject to the same routing nonsense. People also try to make sure each multirail output actually goes to a different destination instead of multiple outputs all pointing at the same depot, since shared targets really crank up the “everything collapses to one lane” behavior. And if a long 3‑lane run starts acting up, a common fix is to tear out the entire stretch and rebuild it in one go instead of patching a small piece, which seems to cut down on routing corruption across edits and reloads.

All of that has pushed players into bigger picture conversations about how to move a lot of items without leaning on multirails at all. The main theme is “keep it simple”: use more straight‑up rails and fewer big shared junctions. Instead of one fancy multirail bus, people are laying down two to four parallel single‑rail lines, each assigned to a specific item or tight item group, and using normal 1→3 and 3→1 splitters so nothing has to change lanes inside a multirail segment. Modular “corridors”—short straight chunks, small branches into factories, then clean merges back to the main line—make it easier to predict and test your actual throughput. Reserving at least one rail as a dedicated long‑haul line for your highest‑volume material lets that resource fully use a whole track without fighting others. On a larger scale, sprinkling in more depots as intermediate hubs and avoiding one giant “everything comes here” collector means the pull system is juggling lots of small requests instead of trying to solve one giant, tangled multirail puzzle. When you absolutely have to compact things, some players now treat multirails mostly as visual structure and mentally treat each lane as its own separate bus, while others skip multirails entirely and just duplicate their best single‑rail designs side‑by‑side.

Put together, the 3x/5x multirail bug and the ways people are working around it have turned into a good case study in how game systems and player expectations collide. The bug shows what happens when a pathfinder tuned for a demand‑driven network runs into players who assume “more lanes = more guaranteed throughput,” like in belt‑heavy factory games. At the same time, it shows how the community adjusts: instead of giving up on big factories, folks are treating the bug as another design constraint, leaning into parallel single rails, modular corridors, and distributed depots while they wait for the devs to ship a proper fix.

Anyways, that's my input, if anyone has any additional information please comment.

Cheers.

[Maxpeinas]

Yea i am putting game away until multi-rails are fixed. Sometimes they work, sometimes they
act weirdly and sometimes they don't work at all (like nothing is being transfered). Too lazy to replace all my 3-way rails and their mergers/splitters into single rails.

[xxprimarchx]

Originally posted by Maxpeinas:

Yea i am putting game away until multi-rails are fixed. Sometimes they work, sometimes they
act weirdly and sometimes they don't work at all (like nothing is being transfered). Too lazy to replace all my 3-way rails and their mergers/splitters into single rails.

I agree, It's hard to have your design compromised because of functionality. Makes you think, you're doing it wrong until you notice the glitch. Having to save/load and work around the bug is a nightmare.

[dsgnethu]

I did not encounter these issues, if I treat every lane for one specific item. So I know which item feeds into which lane, and take care that the other end also expect only the same item. This way I also do not encounter that awkward "lane switching" issue.

[Maxpeinas]

But it's so much easier just throw everything into multiple 3x and have it moved whenever it needs to go :)
Also just loaded game again and it seems to have fixed the issue (at least for now), idk why i didn't try to reload before. May be playing again until something gamebreaking happens, game is fun.

[Eihrirm]

The bug occurs while saving or loading.
When you load a savegame the game does not know anymore how to handle the 3 on 3 or 5 on 5.
The game will just connect all 6 or 10 connected lines together, thus works like a 3-3 or 5-5 merger.
If you only use one 3-3 or 5-5 you won't get any problems as long as you don't disconnect and try to connect a new line (it won't connect to any line on the other side).
If you use two 3-3 or 5-5 and connect them, they will just use a single line between them (same if you connect a 3-3 to a 5-5).

Just now i did a funny test. I connected 3 full storages with 3 empty storages with a 3-3 rail.
I just could pick the correct material connected to the line before save/load.
After save/load i could pick any material. Was funny to watch -> like a 6 way crossing at mid rush hour without traffic lights and everyone could cross over at full speed

[Douryusen]

I don't know if this is related, but I have a long train of 3 rails with single source on each rail, but multiple outputs off of each of those 3. The rails aren't operating at all. Nothing is being sent along any of them.

Is this a similar aspect to this buggy behavior? Or is my experience something completely different?

[DukeSatan]

Originally posted by Douryusen:

I don't know if this is related, but I have a long train of 3 rails with single source on each rail, but multiple outputs off of each of those 3. The rails aren't operating at all. Nothing is being sent along any of them.

Is this a similar aspect to this buggy behavior? Or is my experience something completely different?

A symptom of the 3-lane bug, usually a save and reload triggers a recalculation and everything starts moving. Typically if you have storage and make connection changes, the system does not do a route calculation and nothing moves, save and load and the routing is update.

I have hundreds of 3-lane rails in my giga-base, it stretches now over about 15 cores across most of the south of the map with multiple factories producing other products like chemicals for the sulphuric acid base.

With 8 lanes of 3-rails, moving down the base, everything shares, every reload and the 3-rails might as well be a single, the routing maths goes for the shortest distance, regardless of which rail it SHOULD be on, it will be fixed.

Edit: this is a about a week old pic now, but gives a general idea of my base, well this is just ONE small section of the whole giga factory:
https://steamcommunity.com/sharedfiles/filedetails/?id=3669001508

[stretch]

Originally posted by DukeSatan:

With 8 lanes of 3-rails, moving down the base, everything shares, every reload and the 3-rails might as well be a single, the routing maths goes for the shortest distance, regardless of which rail it SHOULD be on, it will be fixed.

I fear there is some observation bias here because I would dispute this 'shortest route' comment.
I had 5 rails all starting at different mines sending to separate depots at various distances inside another base. I followed the rails back out from the receivers quite a ways down the 5 rails and at every single junction for many junctions they would swap. The same drones would jump from one to another but if I understand your comment correctly that should not happen.
I am open to the idea that there are a few variations of the bug and it may have been so for you but it wasn't looking that way for me.

[xxprimarchx]

Originally posted by DukeSatan:

Originally posted by Douryusen:

I don't know if this is related, but I have a long train of 3 rails with single source on each rail, but multiple outputs off of each of those 3. The rails aren't operating at all. Nothing is being sent along any of them.

Is this a similar aspect to this buggy behavior? Or is my experience something completely different?

A symptom of the 3-lane bug, usually a save and reload triggers a recalculation and everything starts moving. Typically if you have storage and make connection changes, the system does not do a route calculation and nothing moves, save and load and the routing is update.

I have hundreds of 3-lane rails in my giga-base, it stretches now over about 15 cores across most of the south of the map with multiple factories producing other products like chemicals for the sulphuric acid base.

With 8 lanes of 3-rails, moving down the base, everything shares, every reload and the 3-rails might as well be a single, the routing maths goes for the shortest distance, regardless of which rail it SHOULD be on, it will be fixed.

Edit: this is a about a week old pic now, but gives a general idea of my base, well this is just ONE small section of the whole giga factory:
https://steamcommunity.com/sharedfiles/filedetails/?id=3669001508

Possible fix?
https://wilhelm-af.github.io/StarRupture-JunctionFixer/

[xxprimarchx]

https://steamcommunity.com/app/1631270/discussions/0/764059330564671290/

[PhailRaptor]

Originally posted by stretch:

Originally posted by DukeSatan:

With 8 lanes of 3-rails, moving down the base, everything shares, every reload and the 3-rails might as well be a single, the routing maths goes for the shortest distance, regardless of which rail it SHOULD be on, it will be fixed.

I fear there is some observation bias here because I would dispute this 'shortest route' comment.
I had 5 rails all starting at different mines sending to separate depots at various distances inside another base. I followed the rails back out from the receivers quite a ways down the 5 rails and at every single junction for many junctions they would swap. The same drones would jump from one to another but if I understand your comment correctly that should not happen.
I am open to the idea that there are a few variations of the bug and it may have been so for you but it wasn't looking that way for me.

I wonder if it's giving priority to the oldest rail. I had been starting a bus system when I started to notice the issues, and most of the time I connected things in the same order, but not always. I'm noticing that many of my stretches of rail, traffic gets merged onto a particular rail, say the right, but every now and then it's the center or the middle. I recall not building all of them in the same order, but not where I did which.

Might be something to test.

[[AGN] AlienX]

The problem is simple, the rail junctions do not have the correct SuperStruct, it is currently set to FMassEntity but it should be FCrMassSaveableEntity (the names escape me, but this is close enough)...

When the world saves the the drone rail junction, it also saves fragment data, things like what rails are connected to that entity and other metadata...

The data that holds what rail is connected to what socket never reaches the save file as it's not a saveable entity type.

A patch exists for it for servers only right now over at https://github.com/AlienXAXS/StarRupture-ModLoader

But it's in early stages, testing looks good though thus far.

[H Seldon]

I'm using the multi rails as two way "streets". My intersections take up two squares and then they go to the multi-rails. (I'll need to take a screenshot) So I'm only using 2 of the 3 lanes. I haven't figured out a good system for the 5 rail yet.

[JIKOSU]

What I have encountered is that the 1-3 and 1-5 splitters seem to work flawlessly so far, and my only issues are with the 3x and 5x mutlirails, but a little different to what seems the commonly observed problem.
I tried to use the 3x rails to conserve space, with each rail having a different input and output i.e. titanium bars on one, titanium plates on one, and titanium rods on the other, each direct from the fabricator to the depot for its kind. If i tried to change the destination or source of one, all of them would stop working.

My main example of this is I had a mini base making all of the calcium products, and then shipping the to my main base via rail (I didnt have the cargo transporter yet but i had start using it.) I had the calcium products condense to two slots on a 3x rail, and i had helium on the other. When the 3x rail arrived at my main base, each rail fanned out using a 1-3 splitter and went directly to the appropriate storage. Upon completion, it worked flawlessly, everything traveling correctly upon its designated rail in its tight item group, and into its storage.
I needed to increase some of my calcium production so i built a few more production buildings and hooked them up to the rail system. When I went back to my base the entire system had stopped working and wouldnt ship anything anymore. The only way to get it to work wouldve been to rebuild the whole thing which I didnt want to do (I tried rebuilding at both the source and destination, didnt work) and in the end just unlocked the cargo transporter and started using that.
I also did notice items hopping between rails, that just didnt really impact item move speed with my setup.

I have not used a single 3x rail since, they are highly unpredictable and i would risk breaking my system if i used them again. I just use the 1-3 and 1-5 splitters and more direct transfer between buildings instead of one line for everything.

Also, because of how the input/output works, using a 1-3 and then a 3x rail then back to a 3-1 for one building will not increase flow of items because the start and end can still only take one item at a time.

[Synchro]

Originally posted by Maxpeinas:

Yea i am putting game away until multi-rails are fixed. Sometimes they work, sometimes they
act weirdly and sometimes they don't work at all (like nothing is being transfered). Too lazy to replace all my 3-way rails and their mergers/splitters into single rails.

Same here, it's not worth playing until this is fixed. I have no idea why they haven't fixed this yet and sent it out in a hotfix.