[Patch] Yellow Path Signals

[Karn]

Guyz, it's real! Yellow color on train signals!

This patch allows trains to reserve 3 (instead of 1) blocks ahead. Based on number of reserved blocks, there are different colors on signals (since v3, yellow is yellow ).
Each passable color has different maximum speed - green is unlimited, double yellow is 100km/h, yellow is 40km/h (or you can change that in settings).
It helps trains to reduce unnecessary stopping (behind other trains) and allows them to better join the main lines. Also it's more like in real life

yellow_pbs.png (788.58 KiB) Viewed 2165 times

v8.1 changes:
- fixed 2x maglev speed in forgotten cases
- fix - trains in tunnels/on bridges can look ahead too

v8 changes:
- fixed inconsistend behavior between reservation and extending, when block signal placed behind station.
- code cleanup
- added setting for watching next signal -> train can accelerate before passing next signal (default off)
- added setting for not slowing down in stations. Old behavior is more real, but slow trains in stations can be annoying and can create huge traffic jams.. It's up to players what they want. (default is slowing down)

v7 changes:
- when train design speed is lower than double yellow speed and yellow speed, it extends only 2 blocks and 1 block
- settings check to forbid double yellow speed value lower than yellow speed value
- speed limits for maglev are multiplied by 2 (idk.. maybe this should be configurable too, but 3 settings in this patch are enough for me...)
- when loading "old" savegame, converting pbs states into new format, no more green/random colors on every pbs after loading trunk/stable saves.
- fixed same overflow bug when yellow pbs disabled

v6.01 changes:
- fixed byte overflow bug causing 255 reservations in some cases

v6 changes:
- lost trains can extend their paths too
- on pbs - block signals interface trains don't slow down anymore. It was pointless and it would force players to use only block signals or only path signals. However keep in mind, that both way PBSs make their surrounding "PBS blocks", which slow down trains entering the block from block signal (they are then forced to make reservation from non-pbs, which leads to entering this as from yellow signal).

v5 changes:
- orders should be fixed. Generally they act as expected, it will need testing though.
- some refactoring a.k.a. let's crash the game where it previously worked fine

v4 changes:
- drawing yellow state(s) part 2 - replaced every pbs sprite with supermop's sprites

v3 changes:
- drawing yellow state(s) part 1 - electric signal variant
- block signals aren't influenced by this patch anymore (except when u make weird intersections combining block and path signals, but it's a feature, not a bug)
- fixed some bugs causing game crash

v2 changes:
- setting for turning it on/off; setting for custom speeds other than 40/100
- checking/fixing savegame compatibily
- it works with both acceleration models

KNOWN BUGS/TODO LIST:
- when using normal signals with reservation, maybe consider it??
- not yet reported bugs


OPEN QUESTIONS:
- is there better place for extending reservation than CheckNextTrainTile function?
- should be there speed limits setting for basic railtypes? [Normal+electric+unknown/monorail/maglev] Or is sufficient regular and 2x maglev?
- does it matter that "ExtendYellowReservation" and "FindExtendPbs" are recursive functios? Should they be while cycles instead?
- should be "ExtendYellowReservation" function merged with "ChooseTrainTrack"? (which will make "ChooseTrainTrack" a bit more complicated)
- has this patch noticable effect on game performance? Only performance problem can in theory appear in CheckNextTrainTile->FindExtendPbs function. However I have no idea, if it can make big enough difference to be noticable.


Here are windows binaries, linux binaries, patch files and grfs in one zip file. Please report bugs. I'm not aware of any bugs, which can crash the game. On the other hand, autosave is never bad idea

[Wahazar]

Good idea, but maybe it would be sufficient and easier to have block signals with such feature?

[Eddi]

Good idea, but maybe it would be sufficient and easier to have block signals with such feature?

au contraire... it would be way easier if there were no block signals at all...

[Wahazar]

Good idea, but maybe it would be sufficient and easier to have block signals with such feature?

au contraire... it would be way easier if there were no block signals at all...

Probably you mean, that it is ambiguous situation with block signal prior to the junction with many other block signals.
In such situation, it can give plain green signal or green+yellow, practically I presume that it is nowadays rather uncommon situation,
PBS are used instead. Block signals are used where they are supposed to be (single line).

[Eddi]

still, block signals are "dumb" and cannot provide an interface for making them look ahead like this.

or they would stop being block signals.

[Karn]

I agree with Eddi. People (including me) use block signals almost everywhere. Maybe it would be possible to solve that one straight line case. But there are infinite more cases with intersections, self cycled signals etc.

Btw. version 2 available.

[Karn]

Does anybody know, if there are somewhere painted sprites for old style path signals with yellow state? Or is here someone, who would like to draw them?

Btw. version 3 available.

[supermop]

I'll do something - can't promise it will be good. Give me a couple hours.

EDIT:

Here are some quick dirty 4 aspect, UK styled colorlight signals. Still need to add a distiction for one-way, and the semaphores.

Pixels taken from OGFX, so released under GPLv2



EDIT 2:

I've done a UK styled distant semaphore version - with the distant (yellow) semaphore showing 3 positions to get the 4 total aspects; horizontal (next signal stop), 45 degrees (next signal caution), and vertical (next signal clear). The distant semaphore is on top mostly to give room for the vertical position. The home signal (red) has two positions; horizontal (stop) and 45 degrees (clear).

The shading is crude because I just flipped sprites to get the drive on left / drive on right variants. I am not sure if the base set needs to include the German style semaphores as well, but for now I would just use these for both.

4 Aspect PBS UK Semaphore.png (6.81 KiB) Viewed 9871 times

EDIT 3:

Added one-way signs to color light signals.

4 Aspect PBS Colorlight.png (4.89 KiB) Viewed 9865 times

[Karn]

Big thanks supermop It looks awesome I'm currently working on .nfo files. Let's hope there will be version 4 in the evening with your sprites.

[Karn]

Sprites are in game. Reordering 192 sprites via .nfo with 3 different patterns was quite big challenge. Does this time of the day count as evening?

[supermop]

I'm sure the sprites were a pain to position! I wouldn't want to do it.

It counts as evening where I am!

Edit: I noticed one of the signals is missing lower semaphore in one indication, so I will fix that tonight.

[Karn]

I already noticed and copied that missing piece from neighbor signal during the pain process (It was missing 4x ). Well.. I wrote application to position these sprites automatically, but I'm not sure if I didn't spend more time on debugging than I would spend on doing it manually

[dequire]

This is a really great idea - when you have a lot of trains running, it would be excellent to see this type of logic executed in-game vs. the current situation. Meaning, currently trains run in an 100 pct on, 100 pct off state, with the only variable being the game's acceleration model applied to the train's base stats under load (forgive me if my description is a bot over-simplified). Any logic that can be applied to have a train slow down instead of stop when able to is a very good thing! Keep up the good work.

[Karn]

Version 5 available. Last major thing to do before posting binaries is doing something about lost trains. I guess then it should be ready for massive bugreports

And it looks like supermop's electric signals (4 Aspect PBS Colorlight.png) would need improvement. Only one pixel light for most rotations isn't enough. On my standard 1920*1080 screen on normal zoom is most of the time almost impossible to tell, which color displays on signal.
UK style semaphores are fine, there is big visible difference between aspects.

[supermop]

I'll work on increasing the "shine" around the the lights, but some rotations the lights do not face the player at all

[Karn]

That would be nice Yea, and 1 of 8 rotations is hidden. Thing is, in baseset signals have only 2 states and one of these states is red, which has 2 lights shining quite bright. Green on the other hand isn't that clearly visible (from not facing point of viesw), but I can be always sure it isn't red (if it isn't that 1 of 8 case).

Binaries posted in first post, let's test this!

[supermop]

4 Aspect PBS Colorlight Shine.png (4.97 KiB) Viewed 9346 times

Hi Karn,

See if the attached looks better on your screen.

Best,
Daniel

[Karn]

Perfect, thank you very much!

[Clemo56]

Is there a compiled game that includes this patch for linux? Been waiting so long to find a patch like this

[Karn]

I thought linux users won't trust my binaries and would compile it themselves I'm not sure, how things work on linux.. I included sth compiled on ubuntu in the package. If it doesn't work, let me know, so I can remove it and don't give people false hope.