Moderator: TTDPatch Moderators
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??
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.
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.
(You've got to remember that the more features you add the more of a performance hit the game will be/have)
(Side note on speed limits, they'd be good to slow trains before a level crossing, reduce crashes.)
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.)
Edit your ttdpatch.cfg file.Leanden wrote:How do i go about that?
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.
- 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)
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).
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...
A third independent switch in there would not improve either of those issues.
Users browsing this forum: No registered users and 1 guest