Priority and other fancy signaling without "programmimg"

[adf88]

Programmable signals don't cover this list at all .

[Zuu]

• When two railway tracks will lead to the same station, the signals at the beginning the railway tracks should have a small train-counter internally. The two signals could devide the trains proportionally over the two railway tracks and prevents a traffic jam at one railway track while the other one is free.

That assumes that the capacity of the two tracks is the same. With uneven capacity, you don't want to split the flow 50/50.

[Mister_X]

You're right. In my example I assume that the two railway tracks are identical, which results in the same capactity.

But the current version can even avoid this problem. In the most cases the railway track layout should be improved to prevent this kind of problem, I think.
May be we need to find an other solution for this problem.

[Eddi]

there is a very limited load balancer built into the pathfinder. it looks up the state of the first 10 (value adjustable) signals, and applies a quadratic formula to calculate a penalty.

Code: Select all

yapf.rail_look_ahead_max_signals = 10
yapf.rail_look_ahead_signal_p0 = 500
yapf.rail_look_ahead_signal_p1 = -100
yapf.rail_look_ahead_signal_p2 = 5

so if the n-th signal is red, the penalty is p2*n^2+p1*n+p0 (when adjusting the parameters, make sure that this cannot be negative. test this by calculating p1^2-4*p2*p0 (must be negative or 0))

[CapnPipsqueak]

1. An "exit"-signal which will be green when the complete train could pass the signal. (For usage after switches to prevent blocking other trains.)
2. When two railway tracks will lead to the same station, the signals at the beginning the railway tracks should have a small train-counter internally. The two signals could devide the trains proportionally over the two railway tracks and prevents a traffic jam at one railway track while the other one is free.
3. When multiple trains are waiting for a junction, the light trains with more power should have a priority to heavy trains with less power automatically.
4. In the future, the trains should have a normal braking distance instead of one tile which is used in the current versions.

I won't go off-topic, but it's all related to signals.

1. Can be done with path based signals and normal block signals
2. Trains usually do this anyway because the penalty for finding a path on a different line is less than the penalty for following directly behind another train
3. How would you code this? It would have to take into accout how many locomotives are in each train, their power, the cargo they're carrying, whether or not a train is turning around a sharp bend, and it would have to calculate this for every train waiting at a junction, at every signal. It just seems too complex.
4. Already implemented. Find 'Realistic Train Acceleration' in the Advanced Options menu.

[Mister_X]

1. Yes, it could be done with these signals. But when I have trains with different lenghts, I need to have a distance of the longest train between the signals. The capacity of the railway track could be improved.
2. Indeed, it works for short distances. But when I've a mainline from north to south with a lot of signals, the pathfinder won't look further than an X number of signals.
3. In the source code, we already know the total mass and power of the train. It's easy to calculate which train will be fastest. If we do this I won't take the rail layout into account, because it cost some CPU power. But may be the CPU costs will be very low and we'll use these data also.
4. Yes, when you press the button "Reverse direction" the train will have a realistic brake distance. But stopping for a red signal will be started within one tile before the red signal. This is not realistic and the train should start braking earlier.

[3298]

3. This will cease to work as soon as the trainset NewGRF decides to make vehicle properties dependent on speed. This is currently possible AFAIK. I know of trains which have running costs dependent on speed.
4. I've seen this suggestion several times now, and it's been rejected just as many times. The explanation:
The game would need to calculate how far the train travels with applied brakes to reduce its speed to 0. But the NewGRF could mess with the parameters used in the calculation, which changes this distance. Even slopes and curves affect braking, so a simple formula doesn't exist.
Simulating the whole braking action every train movement (they move twice per tick, right?) for all trains on the map is just too much for a regular computer, let alone the poor smartphones and tablets with less processing power than your desktop.
And there could be green signals switching to red right in front of the train... how should the train behave then? Should it just crash into the other train which just entered the block beyond the signal?

[Eddi]

There was no developer who has ever given that reason as rejection.

As for your last quesstion, the current "working theory" is that the train uses path reservations, and signals within that reservation cannot change red (other nearby signals treat the reservation like a train being there, and thus cannot turn green)

[3298]

Okay, it was users familiar with coding, not official devs.
But all the changing factors of deceleration still make stuff difficult. I wouldn't want to code it nor run it on my netbook, on which fast-forward with a hundred trains still has a noticeable effect.