[Patch] Yellow Path Signals
Moderator: OpenTTD Developers
[Patch] Yellow Path Signals
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
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
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
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
- Attachments
-
- openttd-yellow_pbs_r27505_v8_1.zip
- There are 2 versions of signal graphic "shiny" (default) and "original". If you like the original more, you can copy it from "PBS_4_Aspects_NEWGRF\original\PBS_4_Aspects.grf" and paste into baseset folder
- (13.24 MiB) Downloaded 407 times
Last edited by Karn on 19 Feb 2016 15:48, edited 11 times in total.
Re: [Patch] Yellow Path Signals
Good idea, but maybe it would be sufficient and easier to have block signals with such feature?
Re: [Patch] Yellow Path Signals
au contraire... it would be way easier if there were no block signals at all...McZapkie wrote:Good idea, but maybe it would be sufficient and easier to have block signals with such feature?
Re: [Patch] Yellow Path Signals
Probably you mean, that it is ambiguous situation with block signal prior to the junction with many other block signals.Eddi wrote:au contraire... it would be way easier if there were no block signals at all...McZapkie wrote:Good idea, but maybe it would be sufficient and easier to have block signals with such feature?
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).
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Re: [Patch] Yellow Path Signals
still, block signals are "dumb" and cannot provide an interface for making them look ahead like this.
or they would stop being block signals.
or they would stop being block signals.
Re: [Patch] Yellow Path Signals
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.
Btw. version 2 available.
Re: [Patch] Yellow Path Signals
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.
Btw. version 3 available.
Re: [Patch] Yellow Path Signals
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.
EDIT 3:
Added one-way signs to color light signals.
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.
EDIT 3:
Added one-way signs to color light signals.
Re: [Patch] Yellow Path Signals
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.
Re: [Patch] Yellow Path Signals
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?
Re: [Patch] Yellow Path Signals
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.
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.
Re: [Patch] Yellow Path Signals
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
Re: [Patch] Yellow Path Signals
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.
Re: [Patch] Yellow Path Signals
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.
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.
Re: [Patch] Yellow Path Signals
I'll work on increasing the "shine" around the the lights, but some rotations the lights do not face the player at all
Re: [Patch] Yellow Path Signals
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!
Binaries posted in first post, let's test this!
Re: [Patch] Yellow Path Signals
See if the attached looks better on your screen.
Best,
Daniel
Re: [Patch] Yellow Path Signals
Perfect, thank you very much!
Re: [Patch] Yellow Path Signals
Is there a compiled game that includes this patch for linux? Been waiting so long to find a patch like this
Re: [Patch] Yellow Path Signals
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.
Who is online
Users browsing this forum: No registered users and 42 guests