There's a bug in the train's parking

[gaucho_tche]

I've observed that the trains in a waiting station with 6, 8, 10 lanes, are not following the order they arrive in the "block". So sometimes a train with rocket fuel gets there first, but keeps waiting for hours all the other trains join and leave, not respecting the order they arrived there. This should certainly be fixed cause it compromises the reception of materials since a necessary one can keep eternally in the waiting while the others come and go...

[tehfreek]

Are all these trains going to the same single station?

[Selvek]

Sounds a whole lot like not a bug. If you want the trains to "respect the order they arrived", you'll have to do it using circuit network.

[gaucho_tche]

Sounds a whole lot like not a bug. If you want the trains to "respect the order they arrived", you'll have to do it using circuit network.

Of course it should respect the order they arrive. What else would it respect?

[TruePikachu]

Probably NaB, but just out of curiousity, what are the train ID numbers? I'd expect the one with the lowest number to get priority in this sort of situation.

[gaucho_tche]

Probably NaB, but just out of curiousity, what are the train ID numbers? I'd expect the one with the lowest number to get priority in this sort of situation.

well, the train ID number is certain not a good choice for prioritizing it. The arriving order is what it should take in account, so to me IT IS a bug that it is not working that way.

[golfmiketango]

I have spent many hours -- probably many 24-hour days -- working on circuit logic to solve this problem in general. I still don't have anything I'm happy with.

Admittedly, I've piled several additional design objectives on top of this so that I end up wanting an infinitely tile-able FIFO capable of holding arbitrary circuit-network data in each memory cell, with an addressable delete operation across the full array. Oh, and I seem to want it to accept a new input and a new delete every tick.

I'm 100% sure such a thing can be made. And 99% sure it doesn't need to be completely ridiculous unplayable monstrosity. But it's a pretty hard problem. Even once I have such a thing, there are still open questions pertaining to situations where the data flows in faster than one-datum-per-tick (but I think they are solvable by chaining such FIFO's together and implementing a FIFO-merging apparatus, something I also have working prototypes for, so long as the average rate does not exceed one datum per tick).

Point being, if this is not a bug, "you can just solve it with the circuit network" is a pretty extreme form of hand-waving. Sure, if we have two or four stations or something, there are some kludges that will do the trick. But once we start wanting an infinitely tile-able solution that works efficiently, this can get scary-hard.

[dewiniaid]

It isn't so much "Trains are prioritized by ID number" as much "There is no natural prioritization of trains and all trains are evaluated in a deterministic order."

Presumably, Factorio does not track when a train arrives in a station or maintain any sort of queue. This is not a bug, though it's not a terrible idea for a feature.

Assuming that this is a "waiting" station/stacker before an actual station:

It's not hard to implement your own prioritization with the circuit network. The general idea is to have a pair of counters -- one increments when a train arrives and determines which signal is allowed to be green for entering the stacker, the other does the same for trains leaving on the exiting side.

[gaucho_tche]

I have spent many hours -- probably many 24-hour days -- working on circuit logic to solve this problem in general. I still don't have anything I'm happy with.

Admittedly, I've piled several additional design objectives on top of this so that I end up wanting an infinitely tile-able FIFO capable of holding arbitrary circuit-network data in each memory cell, with an addressable delete operation across the full array. Oh, and I seem to want it to accept a new input and a new delete every tick.

I'm 100% sure such a thing can be made. And 99% sure it doesn't need to be completely ridiculous unplayable monstrosity. But it's a pretty hard problem. Even once I have such a thing, there are still open questions pertaining to situations where the data flows in faster than one-datum-per-tick (but I think they are solvable by chaining such FIFO's together and implementing a FIFO-merging apparatus, something I also have working prototypes for, so long as the average rate does not exceed one datum per tick).

Point being, if this is not a bug, "you can just solve it with the circuit network" is a pretty extreme form of hand-waving. Sure, if we have two or four stations or something, there are some kludges that will do the trick. But once we start wanting an infinitely tile-able solution that works efficiently, this can get scary-hard.

I certainly agree with you that it must be hell to make such a circuit. So I will say again, to me this is a bug, since it affects the general play-ability of the game.

[golfmiketango]

Around here there's a convention that such things are not considered bugs. So even though in casual speech we might say "it's a bug," the only thing that properly belongs in the "Bug Reports" forum would be situations where the developers intended for things to work a certain way, and they don't. Otherwise it's a "proposal" or, in cases like this where we aren't proposing a specific solution, but rather observing something about factorio that we find inconvenient or difficult, perhaps we would call it a balancing problem or an open question.

Posting it here will often result in a response along the lines of "not a bug, topic closed," even if your idea/point was a good one.

Also, you don't need anything nearly so complicated as what I described above to fix this in most cases. My solution described above is sort of a general solution for regulating the flow rate of items between a large stacker and a small train station, which isn't really the problem you're describing (although such a thing could be repurposed to solve that too).

[Selvek]

Sounds a whole lot like not a bug. If you want the trains to "respect the order they arrived", you'll have to do it using circuit network.

Of course it should respect the order they arrive. What else would it respect?

I would say the most natural choice would be whichever train is closest. But it could also be, say, the train with the lowest train ID. The point is, parking bays aren't a special case from the standpoint of train routing logic, and the trains don't know what you're attempting to accomplish. For example, the goal of getting as many trains as possible through the intersection would require different logic than the goal of getting trains through the intersection in the order they arrived.

[Selvek]

Instead of a parking bay, consider an intersection where two tracks combine into one. Imagine a never-ending stream of trains is coming in on each track.

If priority is given to whichever train has been waiting the longest, the two input tracks will alternate, meaning the streams of trains will both have to stop every couple seconds. It will be "fair", but the throughput will be very low.

If the goal is to get as many trains through the intersection as possible, one track will block indefinitely while the other runs trains at full speed. The trains on one track will never have to stop, so far more trains will make it through.

Without a high level understanding of what the player wants to accomplish, the game has no way of knowing which of these is "better".


Fortunately, even without the circuit network, the game gives you plenty of tools to solve this problem. In the case of your parking bay, if you want a FIFO queue, wouldn't the easiest solution just be to use a long serial track as your parking instead of parallel ones? Or to build separate parallel parking bays to different kinds of trains so no single kind ever gets blocked?

[dewiniaid]

In the case of your parking bay, if you want a FIFO queue, wouldn't the easiest solution just be to use a long serial track as your parking instead of parallel ones?

This has the drawback of extending travel time for a train that it wouldn't otherwise need when the queue is empty, and takes more space.

That said, I've been effectively nerdsniped and will make a simple combinator-implemented FIFO in a bit.

[gaucho_tche]

In the case of your parking bay, if you want a FIFO queue, wouldn't the easiest solution just be to use a long serial track as your parking instead of parallel ones?

This has the drawback of extending travel time for a train that it wouldn't otherwise need when the queue is empty, and takes more space.

That said, I've been effectively nerdsniped and will make a simple combinator-implemented FIFO in a bit.

Where will you post it? I just want that the first train to arrive in the parking lot is the first to leave. EDIT: well, I believe that's exactly what FIFO means

[robot256]

This has the drawback of extending travel time for a train that it wouldn't otherwise need when the queue is empty, and takes more space.

You might be able to make one long track with multiple "bypass" points that open up if there are not many trains in it. Similar to how airport security takes down some of the cordons when the lines are short.

[dewiniaid]

After trying a bunch, I came up with something that sort of works but not entirely. So I'll post my write-up here and maybe it can serve as a foundation for someone else.



Alright, here's a FIFO stacker. It took a bit longer than planned to complete since I had to resolve some issues where a train would reserve a path to a signal just before the signal was able to close.

Blueprint String

Code: Select all

0eNrtW9tu4zYQ/ZVAj621EG+6BEWBPnTRAAEWaB+LhaHIjEOsLBmUFGwQ+AP6F/22fkkp+aJEIq0ZNWi3iF+SODKPSJ4zw+Fw+Ozd5Y3calXU3vWzp7KyqLzr35+9Sq2LNG//Vz9tpXftqVpuvIVXpJv2k05V7u0WnipW8qt3TXafF54salUruW/ffXhaFs3mTmrzhVPLrNGPcuV3AAtvW1amTVm0LzI4PhEL76n9TQz4SmmZ7Z+Gu8UIk0IxCRyTnTCr2sCtH2onanBApa9RqQWVA3sawTsqwB2N4f0MwaAhHDQCDp7BBx+D+8nh/UzAoBQO2qoEMnqERAmBdhShUEKhoJjBg60JQRPhUFCERgnYnBDWRMDmhPElBGhPLk/KbJhwgyKHCYhfo0Y2VLhFEQ5GpQHaRUNQCdb1QUAp1qVAQNmrRdg/LNRjk/pwFEDwQQy8ysIz63yty3x5Jx/SR1XqtlGmdNaoepnlZSWXxwDgPs0ruTg91DJdnZ7VujGPSp0Wa7ksm3rb1MtR4PCodN10PTzORfcN/1MbP6y1lMWcprtuDMV+SFXbhrQ/OryXAYhaGclHu8+7nW0ue1/S8lP4VV1u3TYfDKxzYWhN9397P+UqU03l2d4Cdi4O4yI20BC4rNLD0iIAmNClmkRwzBgmV5+ER8HGQ70KjF73mrTKdSBlg7k6deFe6Qor3kq2EPBGt16n2s021WndjsH7648/nVLWcjUUMg/aONuq8faRXeMJlFQGJpUFUFLphdRJUombVOIglUH3UwmcUwrkNL5QOkkpc1PKXJQyIKUCTikHUsovlE5SKtyUChelAjj/wWX+p6M47oriGDAU6iMhG0gf+2zkSjUbX+amW1pl/rbM5Zn4WnScgYdBX27Auug06XlpP5PBcxG7xt2HViuZqZXUvpnhO1V0Mzzq8GF5Z8DdwAGyl0o1QysyzR72zBcmVG5zjMFABj+aNtjwv0fdPpn+NUW9vNflZqkKA3PQOsK0hwRQp6WPqfpsXkPdkrV838pkH6OlWtUPG1kb3QHI5EAye9S34fNg/j2tvrGtciv1cTv03WxasTu7gTHFToZszMcwfniAdA4+SU7bb6d7sHSIxoPxcDrU5uvnoVusYyxiaWwfL0GPV8waLwsmxjvsMucT8+FepsfvGv2DWdDsE0SxBuuTQ96I/ssme2u114G5fj/DXG/dturY5ZyxROf2lTO0FMk8KdIJqY2kGE5IMXZLkU6Zpokpx2j2CeJ4KdL3LUV2XorOVUBgpRjNUyKfUNpILPF5JUbuDMP4XUMfyCMLmn1+QrQS4/ctRHFeiK5UAcfuVdqgf4YQ+Tg8cslITPkvnkxolLsGG6NVxd+3qqLzqnLGNMmc7ST9b7eTYrCd/OHtt5NtVgUz/fDd5Mhtn+UtgRqjM1Ei+m3MyWHIQur1k6+KWur7NJPO06/B0TS34RNYvosGL92RDYjiDrcYoG8Md7YFgeS4kxUIpEDl9SGIISqtDEGMUOm2AaKwIcYzc28Ml3obZQtEMlyFXFG2eFHLsEnz3M/TzdbdMX7smDtz+w8ysDdTKTVUDsWZXwwDbFVIOM11iKwETKYrIkKKPWIOh4sW+/bS7Df/mxPmkGHrfCA64bjqTohOBPbU+qKTtzy0DkNs5RZEJxGqthYikxh5EH5RyVueg4cJshIPIJIoQNUgA0QSEeTR+kUkb3myHmErKyEiYZhSbYhGOPL4/6KRGaf/kUDVQyeACwshsl4znK6wjiJQpeneo8WjjEpfZ/pLWX5ZN6qwFZpGwJXrmJYeVZvQb6Iw+GZ+YfDNG219ogQbqoyKg23XVgLkpR0QKLZyHQRKkTdsQKAM6bRBoBx3GwaEKXCXYUCYIe4uDAgzwl2FAWHGuJswIMwEeRFmDGoihO4C4vWL+4oLL0/vpHEL3q8G7Oq3Os2+SH318ebjp6ufv6abbZc6epS62i/RLCCC0yiI2G73NxHKRr8=

EDIT: After doing all the above, I realized the bottommost signal should probably be a chain signal otherwise things may fail when a new train arrives and all lanes are full.

Explanation:

The top signal in the loop is the stacker's exit. The bottom is the stacker's entrance.

While those signals are green (or yellow), they output "O" (for Out) or "I" (for In). These signals connect to a pair of combinators (top and middle) which form a rising edge detector -- in short, it sends a 1-tick-long pulse whenever one of those signals increases. This pulse is then suitable for feeding into a counter (bottom combinator) -- here implemented as "Each < 5" combinator. 5 corresponds to the number of lanes in the stacker.

This counter is then connected to the entrance/exit signals for each lane. Each lane has a number (between 0 and 4, "L") and signals are closed if the value of I/O is not equal to the lane number.

The line of arithmetic combinators is used so that new lanes can be created just by copying and overlapping that part of the blueprint so everything connects -- and then the only adjustment needed is to the counter to signal the correct number of lanes.

The net effect of this is:

The first train to arrive enters bay 1. The second train to arrive enters bay 2. Even if the first train has since left, the third train will enter bay 3.

Each time a train leaves, the next bay is permitted to leave. This preserves the arrival order and thus allows FIFO-like behavior.

Note that there are some issues: since there's a small delay before signal changes occur, a train may start routing to a lane just before the signal changes and get stuck there. The station after the entrance signal is intended to be a countermeasure for this to force the train to reroute, but simply ensuring the entrance signal is far enough away from any junctions may prevent this from occuring as well.

This should work with multiple entrances and exits, as long as all entrances and exits are connected and configured correctly.

The exit must be the ONLY way in to the next rail block. If it is not, the signal may change as a result of other traffic which will prematurely advance which bay is allowed to leave and this may deadlock the system. The fix here is easy: have another signal immediately after the exit signal.

[golfmiketango]

That said, I've been effectively nerdsniped and will make a simple combinator-implemented FIFO in a bit.

Heh, see you in a couple of months

Never saw that xkcd before, holy crap, that guy really has me pegged -- undoubtedly a lot of us factorians are similarly prone.

[golfmiketango]

It isn't so much "Trains are prioritized by ID number" as much "There is no natural prioritization of trains and all trains are evaluated in a deterministic order."

That sounds pretty plausible... I'm inclined to believe something like this is the case, but can't resist asking: what is known of the precise game mechanics leading to OP's complaint? Can we make it more precise? To wit, my uneducated guess would be: s/a deterministic /build-/, so that, all things being equal, either the oldest or the newest trains tend to win these battles (which probably means that ordering trains by increasing ID does indeed order them from most-favored to least-favored?)

It's worth mentioning that there are more straightforward factors which can lead to the sort of situation described by OP: placement of signals and track merges, for example. If we have a train on a curved track behind a signal trying to merge onto a heavily-loaded segment of straight track with no signals for example, heck yeah, the signalled train might be there for a good long while waiting for his chance to merge, maybe forever. That is not a bug in any sense, I don't think. Also, if you have two trains, one behind a chain signal and one behind a regular signal, the game will tend to favor trains coming from one side over the other... but I forget which is which (my guess would be: the guy with the chain signal probably wins since the guy with the regular signal has to treat the other guy as already "virtually" occupying the contested segment of track).

Anyhow, whether or not OP is encountering those problems I think it's worth-while to consider "all things being equal" situations, i.e., trains A and B are held behind circuit-controlled signals and asked to merge in a completely symmetric manner onto the same track, and then they both get the green light from the circuit network at the same time: now, who wins a race?

[gaucho_tche]

After trying a bunch, I came up with something that sort of works but not entirely. So I'll post my write-up here and maybe it can serve as a foundation for someone else.



Alright, here's a FIFO stacker. It took a bit longer than planned to complete since I had to resolve some issues where a train would reserve a path to a signal just before the signal was able to close.

Blueprint String

Code: Select all

0eNrtW9tu4zYQ/ZVAj621EG+6BEWBPnTRAAEWaB+LhaHIjEOsLBmUFGwQ+AP6F/22fkkp+aJEIq0ZNWi3iF+SODKPSJ4zw+Fw+Ozd5Y3calXU3vWzp7KyqLzr35+9Sq2LNG//Vz9tpXftqVpuvIVXpJv2k05V7u0WnipW8qt3TXafF54salUruW/ffXhaFs3mTmrzhVPLrNGPcuV3AAtvW1amTVm0LzI4PhEL76n9TQz4SmmZ7Z+Gu8UIk0IxCRyTnTCr2sCtH2onanBApa9RqQWVA3sawTsqwB2N4f0MwaAhHDQCDp7BBx+D+8nh/UzAoBQO2qoEMnqERAmBdhShUEKhoJjBg60JQRPhUFCERgnYnBDWRMDmhPElBGhPLk/KbJhwgyKHCYhfo0Y2VLhFEQ5GpQHaRUNQCdb1QUAp1qVAQNmrRdg/LNRjk/pwFEDwQQy8ysIz63yty3x5Jx/SR1XqtlGmdNaoepnlZSWXxwDgPs0ruTg91DJdnZ7VujGPSp0Wa7ksm3rb1MtR4PCodN10PTzORfcN/1MbP6y1lMWcprtuDMV+SFXbhrQ/OryXAYhaGclHu8+7nW0ue1/S8lP4VV1u3TYfDKxzYWhN9397P+UqU03l2d4Cdi4O4yI20BC4rNLD0iIAmNClmkRwzBgmV5+ER8HGQ70KjF73mrTKdSBlg7k6deFe6Qor3kq2EPBGt16n2s021WndjsH7648/nVLWcjUUMg/aONuq8faRXeMJlFQGJpUFUFLphdRJUombVOIglUH3UwmcUwrkNL5QOkkpc1PKXJQyIKUCTikHUsovlE5SKtyUChelAjj/wWX+p6M47oriGDAU6iMhG0gf+2zkSjUbX+amW1pl/rbM5Zn4WnScgYdBX27Auug06XlpP5PBcxG7xt2HViuZqZXUvpnhO1V0Mzzq8GF5Z8DdwAGyl0o1QysyzR72zBcmVG5zjMFABj+aNtjwv0fdPpn+NUW9vNflZqkKA3PQOsK0hwRQp6WPqfpsXkPdkrV838pkH6OlWtUPG1kb3QHI5EAye9S34fNg/j2tvrGtciv1cTv03WxasTu7gTHFToZszMcwfniAdA4+SU7bb6d7sHSIxoPxcDrU5uvnoVusYyxiaWwfL0GPV8waLwsmxjvsMucT8+FepsfvGv2DWdDsE0SxBuuTQ96I/ssme2u114G5fj/DXG/dturY5ZyxROf2lTO0FMk8KdIJqY2kGE5IMXZLkU6Zpokpx2j2CeJ4KdL3LUV2XorOVUBgpRjNUyKfUNpILPF5JUbuDMP4XUMfyCMLmn1+QrQS4/ctRHFeiK5UAcfuVdqgf4YQ+Tg8cslITPkvnkxolLsGG6NVxd+3qqLzqnLGNMmc7ST9b7eTYrCd/OHtt5NtVgUz/fDd5Mhtn+UtgRqjM1Ei+m3MyWHIQur1k6+KWur7NJPO06/B0TS34RNYvosGL92RDYjiDrcYoG8Md7YFgeS4kxUIpEDl9SGIISqtDEGMUOm2AaKwIcYzc28Ml3obZQtEMlyFXFG2eFHLsEnz3M/TzdbdMX7smDtz+w8ysDdTKTVUDsWZXwwDbFVIOM11iKwETKYrIkKKPWIOh4sW+/bS7Df/mxPmkGHrfCA64bjqTohOBPbU+qKTtzy0DkNs5RZEJxGqthYikxh5EH5RyVueg4cJshIPIJIoQNUgA0QSEeTR+kUkb3myHmErKyEiYZhSbYhGOPL4/6KRGaf/kUDVQyeACwshsl4znK6wjiJQpeneo8WjjEpfZ/pLWX5ZN6qwFZpGwJXrmJYeVZvQb6Iw+GZ+YfDNG219ogQbqoyKg23XVgLkpR0QKLZyHQRKkTdsQKAM6bRBoBx3GwaEKXCXYUCYIe4uDAgzwl2FAWHGuJswIMwEeRFmDGoihO4C4vWL+4oLL0/vpHEL3q8G7Oq3Os2+SH318ebjp6ufv6abbZc6epS62i/RLCCC0yiI2G73NxHKRr8=

EDIT: After doing all the above, I realized the bottommost signal should probably be a chain signal otherwise things may fail when a new train arrives and all lanes are full.

Explanation:

The top signal in the loop is the stacker's exit. The bottom is the stacker's entrance.

While those signals are green (or yellow), they output "O" (for Out) or "I" (for In). These signals connect to a pair of combinators (top and middle) which form a rising edge detector -- in short, it sends a 1-tick-long pulse whenever one of those signals increases. This pulse is then suitable for feeding into a counter (bottom combinator) -- here implemented as "Each < 5" combinator. 5 corresponds to the number of lanes in the stacker.

This counter is then connected to the entrance/exit signals for each lane. Each lane has a number (between 0 and 4, "L") and signals are closed if the value of I/O is not equal to the lane number.

The line of arithmetic combinators is used so that new lanes can be created just by copying and overlapping that part of the blueprint so everything connects -- and then the only adjustment needed is to the counter to signal the correct number of lanes.

The net effect of this is:

The first train to arrive enters bay 1. The second train to arrive enters bay 2. Even if the first train has since left, the third train will enter bay 3.

Each time a train leaves, the next bay is permitted to leave. This preserves the arrival order and thus allows FIFO-like behavior.

Note that there are some issues: since there's a small delay before signal changes occur, a train may start routing to a lane just before the signal changes and get stuck there. The station after the entrance signal is intended to be a countermeasure for this to force the train to reroute, but simply ensuring the entrance signal is far enough away from any junctions may prevent this from occuring as well.

This should work with multiple entrances and exits, as long as all entrances and exits are connected and configured correctly.

The exit must be the ONLY way in to the next rail block. If it is not, the signal may change as a result of other traffic which will prematurely advance which bay is allowed to leave and this may deadlock the system. The fix here is easy: have another signal immediately after the exit signal.

This is what my parking station looks like. 8 Lanes for waiting and 3 to unload. Could your circuit be adapted to my design?

[Rseding91]

I've observed that the trains in a waiting station with 6, 8, 10 lanes, are not following the order they arrive in the "block". So sometimes a train with rocket fuel gets there first, but keeps waiting for hours all the other trains join and leave, not respecting the order they arrived there. This should certainly be fixed cause it compromises the reception of materials since a necessary one can keep eternally in the waiting while the others come and go...

Thanks for the report however this is working as intended: trains do not follow "first in, first out" logic when waiting at rail signals. They simply operate in what ever order the train(s) are updated where that order is deterministic.