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...

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.

Thanks for the reply. However I'm certain this is not the way it should work. F-I-F-O is the way to go. Since trains are bringing resources, sometimes different ones, it's necessary that the order be respected. I hope you fix this soon.

[Selvek]

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.

Because, as mentioned above, we are all total nerds, can you give us some insight into what the deterministic order is based on? Train ID or most/least recently built? X/Y coordinates?

[Rseding91]

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.

Because, as mentioned above, we are all total nerds, can you give us some insight into what the deterministic order is based on? Train ID or most/least recently built? X/Y coordinates?

I'd rather not. It's not a simple "this line of code controls it" but the entire logic around updating trains and that's some 2400~ lines across multiple files. Even if it was easy to explain I don't want people relying on it and then complaining later if we change it on purpose or as a side effect of refactoring/changes.

[gaucho_tche]

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.

Because, as mentioned above, we are all total nerds, can you give us some insight into what the deterministic order is based on? Train ID or most/least recently built? X/Y coordinates?

I'd rather not. It's not a simple "this line of code controls it" but the entire logic around updating trains and that's some 2400~ lines across multiple files. Even if it was easy to explain I don't want people relying on it and then complaining later if we change it on purpose or as a side effect of refactoring/changes.

Things should be more straightforward. I would like to rest assured that you put in the to-do list a F-I-F-O for train parking please. There's no reason for it working otherwise.

[Selvek]

Because, as mentioned above, we are all total nerds, can you give us some insight into what the deterministic order is based on? Train ID or most/least recently built? X/Y coordinates?

I'd rather not. It's not a simple "this line of code controls it" but the entire logic around updating trains and that's some 2400~ lines across multiple files. Even if it was easy to explain I don't want people relying on it and then complaining later if we change it on purpose or as a side effect of refactoring/changes.

So, in conclusion -
Trains have a clearly defined "pseudo-random" priority system, and if you don't like it, learn to circuit network

[gaucho_tche]

Because, as mentioned above, we are all total nerds, can you give us some insight into what the deterministic order is based on? Train ID or most/least recently built? X/Y coordinates?

I'd rather not. It's not a simple "this line of code controls it" but the entire logic around updating trains and that's some 2400~ lines across multiple files. Even if it was easy to explain I don't want people relying on it and then complaining later if we change it on purpose or as a side effect of refactoring/changes.

So, in conclusion -
Trains have a clearly defined "pseudo-random" priority system, and if you don't like it, learn to circuit network

It's impossible or at least very annoying to fix this using circuit network. It is so much easy for developers to make it work like it should: FIFO.

[coderpatsy]

It is so much easy for developers to make it work like it should: FIFO.

It's not a simple "this line of code controls it" but the entire logic around updating trains and that's some 2400~ lines across multiple files.

If Rseding can't even describe the current order because of the complexity, what makes you think it would be easy to change it?

[gaucho_tche]

It is so much easy for developers to make it work like it should: FIFO.

It's not a simple "this line of code controls it" but the entire logic around updating trains and that's some 2400~ lines across multiple files.

If Rseding can't even describe the current order because of the complexity, what makes you think it would be easy to change it?

For them it's easy. Must just identify when an array of tracks forms a "parking lot" and then read the id of the incoming trains and set it in order of FIFO.

[tehfreek]

When a train should enter a block but can't, push it onto a FIFO associated with the block. When the block empties, pull a train from the FIFO and let only it in.

[phi Seeker]

I just wanted to post this exact thing as a bug as well. Though I understand that add something like stacker priority for leaving trains is not actually easy to do through game design.
Also I realized through some experimenting that any changes made to the train while in stacker make it actually go later altough it would go first otherwise.
I will probably experiment a little with managing the stacker through circuitry in the future, although I use the chain signal at the exit, which makes things a somewhat more challenging.

[robot256]

I did some more thinking on this.

When a train should enter a block but can't, push it onto a FIFO associated with the block. When the block empties, pull a train from the FIFO and let only it in.

Adding a generic behavior to do this is actually very complicated, especially to make it reliable, intuitive, and more useful than the system we have now.

What if the block has more than one exit, and the first train in the queue wants to go to a blocked exit while the second train in the queue wants to go to an open exit? The game has to go down the list every tick to see the highest-priority train that can move.

What if there is more than one block between the stacker and the station, and more than one train trying to use both blocks? Is there a separate queue for each block, and each train is added to both queues?

What if the block has more than one exit and a train could use either exit to get to a valid destination, but both are blocked? Is the train added to all possible queues, then removed from the extras when it travels one of them?

In either of those cases, what if two trains are vying for the same pair of blocks, and somehow end up in opposite orders in the two queues? Each will be stuck in second place for one of the two blocks, and neither gets to go.

And what if the game automatically enables the FIFO functionality only for blocks with a single exit? How does the behavior change enough to be noticeable, and how would the player know it was active?

The current system handles all of these cases better than the FIFO system would. Whichever train has a free path goes, and there's no complicated logic in the priority because there is *no* logic in the priority. Not "smart", but easy to understand. In fact, the only case where the FIFO behavior is more intuitively predictable is the simple stacker.

-------------------------

The specific goal of a FIFO stacker can be accomplished with circuits and rail signals, assuming all exits are treated alike. It becomes much harder if there is a communal stacker for multiple stations, and certain trains only want to go to certain stations. I thought about adding a signal with a mod that could be used on the output of a stacker to enforce FIFO behavior in more complicated cases, but it basically requires closable chain signals to keep from blocking a new train to station A with an old train waiting for Station B. The devs have said even a minor change like closable chain signals would require a massive rewrite of the pathfinding code. So that gives you a sense of what is possible with what we have.