Realistic Deceleration

[crakinshot]

As the name implies; trains can't stop instantly. This essentially means that train deceleration is determined by a calculation rather than "just for show". The idea is simply this: if you have a train running at 140mph and it "sees" a red signal 2-3 tiles ahead, then it simply won't be able to stop in time and will SPAD (Signal Passed At Danger). Basically it means it could run into what ever is ahead...

On its own, this wouldn't be a particularity useful patch... every train would pass red signals and crash. So the way to incorporate this, as I see it, is for multi-aspect signalling. i.e., a signal imposes a speed limit on the train to signify that the block ahead could have a red signal. From this restricted speed, the train can slow down and stop at the red signal.

That's essentially it... would definitely make the game a little more interesting as you'd have to make sure the spacing between signals was enough so trains had enough time to stop from full speed.

Anyhow, something I'll have a crack at... even if I'm the only one that likes it. Can see some major problems unless you use Long Reserve PBS along with it.

[CommanderZ]

As the name implies; trains can't stop instantly. This essentially means that train deceleration is determined by a calculation rather than "just for show". The idea is simply this: if you have a train running at 140mph and it "sees" a red signal 2-3 tiles ahead, then it simply won't be able to stop in time and will SPAD (Signal Passed At Danger). Basically it means it could run into what ever is ahead...

On its own, this wouldn't be a particularity useful patch... every train would pass red signals and crash. So the way to incorporate this, as I see it, is for multi-aspect signalling. i.e., a signal imposes a speed limit on the train to signify that the block ahead could have a red signal. From this restricted speed, the train can slow down and stop at the red signal.

That's essentially it... would definitely make the game a little more interesting as you'd have to make sure the spacing between signals was enough so trains had enough time to stop from full speed.

Anyhow, something I'll have a crack at... even if I'm the only one that likes it. XD

It would require extensive balancing (and the whole thing would have to be optional - just see the people bitching about planes crashing from time to time), but I believe it would be fun!

[crakinshot]

Well that's the reason for advanced options; use it if you want it.

[jaricanese7]

That would be awesome. As far at signals are concerned, the NYC subway works with the speed signal system. Red means full stop, orange means theres a red ahead so slow down, and green of course means all systems go.

[crakinshot]

Well I realised you'd HAVE to use longer track reservation... I can't see another way of doing it without it being a dirty hack and prone to bugs. So, will have to wait until LR PBS is finalised, I think. In hindsight I should have put this thread in suggestions area.

I'm playing with the idea of centralised track control though. i.e., signal boxes. So rather than trains trying to find a path they are given one by a signal box. But now that its centralised you have a bit more information, such as all the trains entering or leaving blocks. Trains 'on their way' to the signal boxes' control area. You also have a centralised definition of the 'blocks', signal interlocks and block speed limits. All of which can be made up automatically, but easily edited. Its a shift really, rather than try to make signals 'programmable' you force them to only present data to the trains and then have a single entity try to control the traffic, rather than trains choosing for themselves. It would need a lot of changes, but maybe not forcing exclusivity. i.e., the old system could still be used just not within the signal boxes' area. I dunno, its very much an idea.

Essentially, realistic deceleration is a simple thing to do; I've already managed to have trains slow down less suddenly, but they of course run red signals. But, to actually make the whole rail-system work, it needs a whole lot more, which is dependent on other people's work.

[jub]

Nice idea. What I would like to see done with deceleration is something simplier. The train would check in the safe distance before the signal and set it to green if possible. Otherwise it would start to slower down and check again maybe each two squares if the route is free. My main concern are sudden stops, they do not look nice.

[crakinshot]

hmm, should be easy to do that one. When a train reserves a segment is also checks the next in the path, if that path is free then the train runs at full, otherwise it begins to slow down as if to stop. You'd still have the sudden stops though if, when the train arrives at the signal, the situation has changed and the path is no longer free. At least it would generally avoid sudden stopping.

[dihedral]

that sounds very cpu heavy!

[crakinshot]

Maybe... For the last idea though not really. My understanding is yapf already looks ahead 10000 tiles anyway and caches its 'ideal' path. Trains try to follow that path until something changes.

[XeryusTC]

Maybe you should go with the Locomotion method and reserve the amount of tiles that are needed for stopping ahead of the train the same way that happens in a PBS block (which happens for the entire path though) and have trains stop if they can't reserve ahead in their current breaking space. That way you shouldn't have the problem of sudden stops.

[jaricanese7]

Well I realised you'd HAVE to use longer track reservation... I can't see another way of doing it without it being a dirty hack and prone to bugs. So, will have to wait until LR PBS is finalised, I think. In hindsight I should have put this thread in suggestions area.

I'm playing with the idea of centralised track control though. i.e., signal boxes. So rather than trains trying to find a path they are given one by a signal box. But now that its centralised you have a bit more information, such as all the trains entering or leaving blocks. Trains 'on their way' to the signal boxes' control area. You also have a centralised definition of the 'blocks', signal interlocks and block speed limits. All of which can be made up automatically, but easily edited. Its a shift really, rather than try to make signals 'programmable' you force them to only present data to the trains and then have a single entity try to control the traffic, rather than trains choosing for themselves. It would need a lot of changes, but maybe not forcing exclusivity. i.e., the old system could still be used just not within the signal boxes' area. I dunno, its very much an idea.

Essentially, realistic deceleration is a simple thing to do; I've already managed to have trains slow down less suddenly, but they of course run red signals. But, to actually make the whole rail-system work, it needs a whole lot more, which is dependent on other people's work.

Yes once again this would be similar to have many of the railroad/subway systems operate today. Trains them-self don't choose a path because in reality they have no clue what is ahead of them which is where the train traffic controllers come in.

[jub]

Maybe you should go with the Locomotion method and reserve the amount of tiles that are needed for stopping ahead of the train the same way that happens in a PBS block (which happens for the entire path though) and have trains stop if they can't reserve ahead in their current breaking space. That way you shouldn't have the problem of sudden stops.

That is what I had in mind. If I need 8 squares to stop and there is a signal on 8th square, then the train should either set the signal to green (and keep it green until it passes it) or start to break.

[2007Alain2007]

I think we need more signals befor we can do that

[crakinshot]

(forgive me I'm back from a night of many shots of vodka)

See, what I'm aiming toward is one single unified signal... a MAS (Multi-aspect signal). This signal essentially is a "does all" signal, that includes the ability to have 4 (or more) levels of warning (speed limits). these signals generally allow extended reservations to be performed. If you want a home signal "i.e., a signal that does not allow extended reservations" then you would use SignalEx to specify that the signal does not allow extended reservations. This would allow you to have trains slow down before this signal, and once approaching reserve only one single segment ahead.

I really don't like (with passion) the different signal types and 'logos'. What I want is for one single signal... easy to use, and no BS in setting it up. Then if I want to specify extra information I would click on a signal, extend it and utilise an extension (i.e., no long reserve, restrictions, programmable, direct train cargo along this path, etc... ). Of course with MAS signals it would be based on a longer reservation method. So if you can only reserve 1 segment ahead, you have to travel at 40mph, if you can reserve 2 segments ahead you travel at 80mph... etc... thats the task I see myself performing in the long run here. The other side is shunting, although that is a far harder nut to crack as it needs an extension on the path finders I think.

[Kogut]

Great idea!
versions without changes in patchfinder
a- Train stops BEFORE read light (for example: 20 tiles before) (what with PBS?)
b- Train stops AFTER read light (and destroy everything for next 20 tiles)


now:
-----------------------------O/------------------
----------------------------O/


tracks for version b:
-O---------------------------/------------------
-O--------------------------/
[
O signal
- and / tracks
]
Another thing - train should also stop before end of tracks

Another idea - speed limits signs, broken down instead of crashed after low speed crashes (less than 20 km/h)

[jaricanese7]

Yes I like that low speed crash idea. Makes a lot of sense.