[0.16.27] Circuit opened train signal lets train with lowest ID always drive first

[TheOnefinn]

I was playing around with a prospective stacker design and noticed that in the version built around chain signals only I ended up with some trains that always lost the race for a spot at the real station opening and sat there waiting forever in the stackerwhilst newer trains arrived and jumped the queue in front of them. I’d kinda expected them to operate on a FIFO (first in, first out) queue system but maybe that would make things too easy (?)

Instead I’m having to design a circuit network to do that for me (I’ve got a working messy proof of concept,but I’ve already thought of a better way I think for mark2) as I want the option of using different train schedules and want to ensure everyone gets their turn.

So does anyone know what the actual priority order is? is it lowest train ID or something?

See later posts for conclusion

[Deadly-Bagel]

I think this is one of those obscure things where there's too many hidden variables to try to work out. I think there was a half explanation somewhere by one of the devs but if so it's deeply buried now.

Just assume that it's random, I don't think there's any usable logic behind it, and have fun designing a solution =P

[Loewchen]

I am pretty sure the is a mechanic in place that gives longer waiting trains priority over just arriving ones, it certainly is not "entrance X always goes first". I can not find a source for this though. If you can provide a save in which one train waits for just arriving ones, post it please.

[Aeternus]

From observation: Trains queueing up for a block enter it at the order they arrived into the waiting queue. (I have trains queuing up at a stacker frequently and observed this a bit out of curiosity)

[TheOnefinn]

I always end up with 2 trains that sit and wait in stacker forever.

The left station is unloading the petrol, the top 2 stations are just fillers to test the setup.

The bottom circuitry is a simple latch to hold the red signal closed unless petrol < 30k IIRC, the top circuitry is just to prioritise the lanes closest to the station first, it can be disabled by setting the higher constant combi on (in which case all lanes will go green), it doesnt make any difference whether I run this circuitry or not.

There is also a constant combi controlling entrance into the stacker, if you toggle it on it will lock the signal closed and stop new trains entering the stacker, do this and you can observe the stuck trains leaving fine when they dont have to contend with other trains for a slot.

Save requires creative mode fix for .16 and was made in .16.25

[Loewchen]

Removing the circuitry on the bottom fixes it.

[TheOnefinn]

Removing the circuitry on the bottom fixes it.

Yup, I confirm that, also I just noticed that the 2 trains that get stuck have the highest train IDs for them all.

So is this a bug? Shouldn't the train that gets picked be the same whether the signal is circuit controlled or not? (I'm only controlling the exit signal, not any of the chains which to my knowledge cant be controlled)

[TheOnefinn]

Ok after doing some more testing with a constant combi hooked up the that bottom signal and manually toggling it on and off, it seems like when a signal goes green from a circuit change the train with the lowest train ID is released. When the signal goes green "naturally", the longest waiting train is released.

[Loewchen]

[...]it seems like when a signal goes green from a circuit change the train with the lowest train ID is released. When the signal goes green "naturally", the longest waiting train is released.

I can confirm this in 16.27, attached is a simple loop that can either be manually controlled or normally.

[TheOnefinn]

Why is this considered not a bug?

[ShitHappens1992]

Technically speaking not a bug, as it's working right now per design. So it's a design flaw in the train prioritising calculation for circuit-controlled signals.

[TheOnefinn]

Technically speaking not a bug, as it's working right now per design. So it's a design flaw in the train prioritising calculation for circuit-controlled signals.

A bug isn’t only when the implementation doesn’t match the design, the design can be “bugged” too.

Right now it’s inconsistent, unintuitive and not obvious to the player, there is no expectation that setting the exit condition on a rail block should break train prioritisation going into a block, logically these 2 things dont seem like they should be related.

I’ve searched high and low both on the forums and in the general web for an explanation and can find none, my only conclusion is it’s a deliberate nerf to circuit controlled trains for some reason, I can think of no practical use for selecting the lowest train id, so it just seems like something the player has to work around, rather than a feature that’s useful.

So you either have to circuit control all the entrances to the block, or (I haven’t tested this one, I only thought of it last night) have a single train waiting bay after the stacker that’s circuit controlled, allowing the stacker exit signal to work without circuits and let a train out of the stacker whenever the circuit controlled waiting bay is free of a train.

The former needs a considerable amount of fairly complex circuitry to do, the latter needs more space and personally I find less satisfying, for me I prefer the aesthetic of seeing a single train leave the stacker moments before the main station is free and seeing it slot into station right behind the old train leaving.

[fiery_salmon]

Why is this considered not a bug?

Because this issue is apparently on edge between "Won't fix." and "Not a bug". I would classify it rather as "Won't fix.", but impact of this classification is minor.

[TheOnefinn]

Why is this considered not a bug?

Because this issue is apparently on edge between "Won't fix." and "Not a bug". I would classify it rather as "Won't fix.", but impact of this classification is minor.

I dont understand. I dont understand why its been deemed that the FIFO behaviour on trains is necessary only if you don't want to control the signal with a circuit. If the behaviour is required in one situation why isnt it required in the other?

I mean the use case I tried seems like a perfect example, you want to trigger the next train to move into station just before the old train leaves and suddenly most of your outposts stop getting serviced because their trains are stuck in the stacker, it makes no logical sense why hooking a signal up to a circuit breaks the FIFO queue.

Its just this bizarre limitation that affects circuit network setups for no good reason, you cant use circuits "lightly" but must re-engineer a replacement for the entire chain signal system just because you want to trigger on a circuit? Its like the game is punishing you for trying to be more efficient.