More Realistic Path Signals...
Moderator: TTDPatch Moderators
More Realistic Path Signals...
In the UK, British Railway Signals work in a way that a train can know 3 signals earlier than a stop signal that a stop is approaching.
Path signals should come in three varieties...
Green: The path ahead is clear.
Double Yellow: The next signal is a caution (yellow) signal.
Yellow: The next signal is a stop (red) signal.
Red: The path ahead is blocked. Stop!
On the whole signals will work exactly as they do now, just with the new signalling system shown above. Perhaps with an optional, trains slow to 3/4 speed when they pass a Double Yellow, and to 1/2 speed when they pass a Yellow.
Prevents trains catching up on each other, and will hopefully encourage overtaking on a second rail lane... Comments??
Path signals should come in three varieties...
Green: The path ahead is clear.
Double Yellow: The next signal is a caution (yellow) signal.
Yellow: The next signal is a stop (red) signal.
Red: The path ahead is blocked. Stop!
On the whole signals will work exactly as they do now, just with the new signalling system shown above. Perhaps with an optional, trains slow to 3/4 speed when they pass a Double Yellow, and to 1/2 speed when they pass a Yellow.
Prevents trains catching up on each other, and will hopefully encourage overtaking on a second rail lane... Comments??
- CommanderZ
- Tycoon
- Posts: 1872
- Joined: 07 Apr 2008 18:29
- Location: Czech Republic
- Contact:
Re: More Realistic Path Signals...
It is certaintly good idea. And as most good ideas, it was already suggested. And not only once ![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
Re: More Realistic Path Signals...
So why has noone done it yet ^^
Can't wait till some of these patches make it into the Release Candidate, I'm rubbish at patching lol.
Can't wait till some of these patches make it into the Release Candidate, I'm rubbish at patching lol.
Re: More Realistic Path Signals...
Probably because it's bloody hard to do.Leanden wrote:So why has noone done it yet ^^
Can't wait till some of these patches make it into the Release Candidate, I'm rubbish at patching lol.
|||| My OTTD/TTDP pics ||||Currently slighty obsessed with getting Platinum Trophies||||Retired moderator||||
Re: More Realistic Path Signals...
The problem here is that TTDPatch as it currently exists, is no longer based solely on the British Experience. Overall, it is quite Eurocentric along with representation from Asia, Australia and North America. The current signaling system is quite sophisticated with a lot of thought going into its interoperability. It would be quite a chore to amend it for what would turn out to be only one reality in a very large picture.Leanden wrote:In the UK, British Railway Signals...
That said, if someone were to draw and code a separate British Signal Set for those absolutely committed to reality in the British experience, I am sure that those players would be very thankful.
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
Re: More Realistic Path Signals...
Perhaps JGR could comment on the possibility of adding speed restrictions via the advanced Signal routing feature?
(You've got to remember that the more features you add the more of a performance hit the game will be/have)
(You've got to remember that the more features you add the more of a performance hit the game will be/have)
Last known as: Weirdy
Re: More Realistic Path Signals...
Ay, obviously this was only the british version, but many Railway signals i've looked up have a similar thing, much more than just stop and go.
(Side note on speed limits, they'd be good to slow trains before a level crossing, reduce crashes.)
(Side note on speed limits, they'd be good to slow trains before a level crossing, reduce crashes.)
Re: More Realistic Path Signals...
You could try enabling the appropriate experimental feature.Leanden wrote:(Side note on speed limits, they'd be good to slow trains before a level crossing, reduce crashes.)
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: More Realistic Path Signals...
Edit your ttdpatch.cfg file.Leanden wrote:How do i go about that?
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
Re: More Realistic Path Signals...
I hath been summoned...SkeedR wrote:Perhaps JGR could comment on the possibility of adding speed restrictions via the advanced Signal routing feature
In one word: no.
In more than one word:
It is unlikely that any mechanism to reduce the maximum line speed on a given track tile will ever be implemented. This is due to various factors. Firstly there is little remaining landscape storage space remaining. Secondly, due to the nature of the train movement code, it would seem to me that it would be necessary for each tile within a reduced speed zone to be marked with the required speed. This results in a UI problem of marking each tile. Marking only a single tile would result in the train accelerating back to normal after passing the tile unless some kind of distance-limited or toggleable state was applied to the vehicle, which opens up a whole new water-heating-device of scaled-marine-wildlife, with loomingly overbearing and evil consequences and side effects to trip up coders and users alike. Furthermore, unless you can find somebody with the necessary inclination and abilities necessary to undertake such an endeavour the odds of any attempt at an implementation occurring are less than satisfying.
If the NMA was implemented, some of these issues would cease to be of concern, however, I am less than absolutely convinced that the implementation of that (rather extensive and internally drastic) system will be complete in the sort of timescales which would be convenient for you. Do not also forget that in TTD train-movement lookahead and braking distance is clamped to half a tile, which kind of makes a mockery of the concept of speed restricted track segments and similar proposals, and from a gameplay POV makes them entirely unnecessary (barring the level-crossing fiasco, which Dale has addressed).
I hope that that has cleared up that uncertainty, bearing in mind that everything above is an unfounded opinion.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: More Realistic Path Signals...
Sorry for butting in where I probably don't know even a tenth of what's needed to know to be able to comment, but my immediate reaction to the 'speed limit' question was this method:
- Create one new property for an engine: DesignedMaxSpeed (maybe this is impossible?)
- Think of the MaxSpeed (or whatever you call it today) as CurrentMaxSpeed
- Loading a GRF, passing a signal "no limit", leaving a depot, ...(and whatever more conditions you can think of where the speed should be reset), sets CurrentMaxSpeed = DesignedMaxSpeed
- Passing a signal "speed limit" sets CurrentMaxSpeed = SignalSpeedLimit
- Placeholder for everything else I have forgotten to think about (or didn't even knew)
Re: More Realistic Path Signals...
Hmm, having the speed restriction reset when passing a non-speed-limited signal is quite a good idea, as it reduces the extent of one of the problems, namely: defining the endpoint of a speed limited area without requiring each tile to be individually set, and trains which inadvertently leave the area without being marked as such, and hence causing issues elsewhere, which can still happen, but is less likely and has less consequences...
For long stretches it would still be necessary to redeclare the limitation on each signal, but that would be easier than on each tile.
From an internal storage POV, signals have almost no landscape storage space left, but it would be theoretically possible to wedge it into the restricted/programmed signal tree structure. That's code's a mess though, and the GUI is also already somewhat festooned with widgets and whatsits...
In light of AndersI's excellent suggestion, I'm going to revise my answer to the following:
Furthermore, unless you can find somebody with the necessary inclination and abilities to undertake such an endeavour the odds of any attempt at an implementation occurring are less than satisfying. <-- This is the big one
...results in a UI problem of marking each tile^Wsignal.
Do not also forget that in TTD train-movement lookahead and braking distance is clamped to half a tile, which kind of makes a mockery of the concept of speed restricted track segments and similar proposals, and from a gameplay functionality POV makes them entirely unnecessary (barring the level-crossing fiasco, which Dale has addressed).
For long stretches it would still be necessary to redeclare the limitation on each signal, but that would be easier than on each tile.
From an internal storage POV, signals have almost no landscape storage space left, but it would be theoretically possible to wedge it into the restricted/programmed signal tree structure. That's code's a mess though, and the GUI is also already somewhat festooned with widgets and whatsits...
In light of AndersI's excellent suggestion, I'm going to revise my answer to the following:
Furthermore, unless you can find somebody with the necessary inclination and abilities to undertake such an endeavour the odds of any attempt at an implementation occurring are less than satisfying. <-- This is the big one
...results in a UI problem of marking each tile^Wsignal.
Do not also forget that in TTD train-movement lookahead and braking distance is clamped to half a tile, which kind of makes a mockery of the concept of speed restricted track segments and similar proposals, and from a gameplay functionality POV makes them entirely unnecessary (barring the level-crossing fiasco, which Dale has addressed).
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Re: More Realistic Path Signals...
JGR wrote:the restricted/programmed signal tree structure. That's code's a mess though, and the GUI is also already somewhat festooned with widgets and whatsits...
![Laughing :lol:](./images/smilies/icon_lol.gif)
![Laughing :lol:](./images/smilies/icon_lol.gif)
A third independent switch in there would not improve either of those issues.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: More Realistic Path Signals...
WOW! A year old topic dig, but I think this speed limit thing might be possible and as it happens there is a current topic over in the OTTD Suggestions forum, to which I have posted my suggestion.
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
Who is online
Users browsing this forum: No registered users and 19 guests