[Patch][WIP] YAAM - Yet Another Acceleration Model
Moderator: OpenTTD Developers
Re: [WIP] YAAM - Yet Another Acceleration Model
Few things, starting with a crash report:
Game crashed as I over built a station tile with a different style platform. Station was attached to an airport. Not sure if that is helpful.
Other things I have noticed:
The YAAM accelleration model is very slow, even with modern, powerful trains. This is probably intended, for realism or otherwise, but it poses some scale problems on smaller maps (512 and below). If playing an original, 256^2 sized map, with a normal town and industry density, distances between junctions or stations are small enough that trains will spend a large amount of their time accelerating or decelerating. I understand this is part of the challenge, but it becomes extreme to the point of un-fun on compact maps. Not sure if a setting to change acceleration strength would help or not.
Compounding the above; when industries or towns are closer together, branches off the mainline become closer together. Due to OpenTTD's scale, we can't really space junctions several miles apart. With a long reservation ahead, more and more of the track near a junction becomes 'interlocked', with distant trains able to reserve a path that blocks traffic in both ways on the mainline, and delays cascading to affect other junctions. As trains take longer to re-accelerate from a red or yellow, busy trunk lines trend towards speeds stuck between 40-70 km/h. This can be partially relieved by making all junctions grade separated, but the point where this becomes necessary arrives much sooner than normal. Furthermore, it seems sort of contrary to the spirit of careful, realistic track design intended by this patch. It also means that mixed traffic or branching service is discouraged, whereas one of the dreams of having yellow signals in game is smoother integration of slow and fast trains.
It is still very difficult to run single track sections of any kind. A completely isolated single line with a single train will run at 15 km/h the entire time. It is not the end of the world to fill such a line with signals, but it does feel odd. Simple branches off the mainline are awkward both for trains entering or leaving, as the train will slow to yellow speed before it leaves the mainline and proceed along the entire branch as if about to stop. Even when the branch is small compared to the distance traveled on mainline, it can have a huge impact on journey time (see attached image) Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
Lastly, at stations; trains try to reserve a long path ahead if able, even when stopping at a station. At certain types of terminus, or where two tracks merge just past the station, this means a train can block a significant distance ahead for a long time while it loads. This can lead to a stopped local train blocking an express passing through, or a loading train blocking the station entrance at end of line. In the attached image, the northern DMU has reserved track out onto the station throat, and will prevent the other DMU and scrap metal train from leaving, as well as a hypothetical train from entering. Additionally it is possible that one of these trains arriving from the north could trap a train in the depot. I'd suggest enforcing that reservations end at visited stations, and further reservations are not requested until the train departs.
An observation: diesels produce a ton of smoke while braking - hopefully they are not trying to use thrust reversers!
I still don't know how to treat block signals... unlimited speed at your own risk? two-aspect red/yellow only?
I hope this is helpful input, please don't take it as a complaint! Let me know if you want me to draw more signal types!
Game crashed as I over built a station tile with a different style platform. Station was attached to an airport. Not sure if that is helpful.
Other things I have noticed:
The YAAM accelleration model is very slow, even with modern, powerful trains. This is probably intended, for realism or otherwise, but it poses some scale problems on smaller maps (512 and below). If playing an original, 256^2 sized map, with a normal town and industry density, distances between junctions or stations are small enough that trains will spend a large amount of their time accelerating or decelerating. I understand this is part of the challenge, but it becomes extreme to the point of un-fun on compact maps. Not sure if a setting to change acceleration strength would help or not.
Compounding the above; when industries or towns are closer together, branches off the mainline become closer together. Due to OpenTTD's scale, we can't really space junctions several miles apart. With a long reservation ahead, more and more of the track near a junction becomes 'interlocked', with distant trains able to reserve a path that blocks traffic in both ways on the mainline, and delays cascading to affect other junctions. As trains take longer to re-accelerate from a red or yellow, busy trunk lines trend towards speeds stuck between 40-70 km/h. This can be partially relieved by making all junctions grade separated, but the point where this becomes necessary arrives much sooner than normal. Furthermore, it seems sort of contrary to the spirit of careful, realistic track design intended by this patch. It also means that mixed traffic or branching service is discouraged, whereas one of the dreams of having yellow signals in game is smoother integration of slow and fast trains.
It is still very difficult to run single track sections of any kind. A completely isolated single line with a single train will run at 15 km/h the entire time. It is not the end of the world to fill such a line with signals, but it does feel odd. Simple branches off the mainline are awkward both for trains entering or leaving, as the train will slow to yellow speed before it leaves the mainline and proceed along the entire branch as if about to stop. Even when the branch is small compared to the distance traveled on mainline, it can have a huge impact on journey time (see attached image) Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
Lastly, at stations; trains try to reserve a long path ahead if able, even when stopping at a station. At certain types of terminus, or where two tracks merge just past the station, this means a train can block a significant distance ahead for a long time while it loads. This can lead to a stopped local train blocking an express passing through, or a loading train blocking the station entrance at end of line. In the attached image, the northern DMU has reserved track out onto the station throat, and will prevent the other DMU and scrap metal train from leaving, as well as a hypothetical train from entering. Additionally it is possible that one of these trains arriving from the north could trap a train in the depot. I'd suggest enforcing that reservations end at visited stations, and further reservations are not requested until the train departs.
An observation: diesels produce a ton of smoke while braking - hopefully they are not trying to use thrust reversers!
I still don't know how to treat block signals... unlimited speed at your own risk? two-aspect red/yellow only?
I hope this is helpful input, please don't take it as a complaint! Let me know if you want me to draw more signal types!
Re: [WIP] YAAM - Yet Another Acceleration Model
The way how I implemented this. There is nothing like simple logic. PBS and track reserving in trunk is one huge spaghetti code. YAAM and yellow PBS are built on pillars of this mess.xZise wrote:Is that a basic part of OpenTTD or what makes this hard?Karn wrote:[…]Key here is, the green/doubleyellow/yellow extending isn't universal, it would be actually too hard if you wanted one more block or color.[…]
If you change something without thinking about every possibility, you will break something else. And here are too many things to break. Or that's just programming.
If you know something about programming, check the source code and try to think how to implement ETCS2. First step is preventing stackoverflow in that crazy recursion. Then if you want more colors, you need to solve how to put more than 4 colors into 2 bits (you can't). Etc. etc.
I don't wanna spend hundreds/thousands hours on implementing ETCS2, I have other things to do.
And there goes algorithmic complexity. If you compute something many times, it can have performance impact.xZise wrote:Okay I was assuming there is a way to change the reservation. If you could reserve more track later (aka block by block) you could increase the reserved paths until there is no free path left (or you reached another stopping point like a station) or you don't need any more track because the train can accelerate anyway. It does not require you to temporarily reserve track.Karn wrote:[…]Also braking distance isn't predictable before reserving track with simple math (think about hills).
Can't reproduce this, I'd need more details.supermop wrote:Game crashed as I over built a station tile with a different style platform. Station was attached to an airport. Not sure if that is helpful.
Hmm what should happen if I place more distant signals in a row?supermop wrote:Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
OH **** , I swear I fixed this before posting v3, seems like there is more to fix.supermop wrote: Lastly, at stations; trains try to reserve a long path ahead if able, even when stopping at a station. At certain types of terminus, or where two tracks merge just past the station, this means a train can block a significant distance ahead for a long time while it loads. This can lead to a stopped local train blocking an express passing through, or a loading train blocking the station entrance at end of line.
So do electric trains, I hoped nobody will notice Ik why, changing that is just TMWFTLB.supermop wrote:An observation: diesels produce a ton of smoke while braking - hopefully they are not trying to use thrust reversers!
Nah you seem to be nice Well, I don't need it yet, for testing purpose are reused PBS sprites enough. I don't have done anything yet and I don't know when it will be done. Your work has value only if there will be working code. I think it's good idea to wait if I can make new meaningful signal type. Then there will be place for drawing. Thanks anyway.supermop wrote:I hope this is helpful input, please don't take it as a complaint! Let me know if you want me to draw more signal types!
Re: [WIP] YAAM - Yet Another Acceleration Model
In case the crash report wasn't sufficient, I am attaching the other crash files here: As far as I can tell, it may have been caused by overbuilding a station tile that had a path reserved through it.Karn wrote:supermop wrote:Game crashed as I over built a station tile with a different style platform. Station was attached to an airport. Not sure if that is helpful.Can't reproduce this, I'd need more details.
It seems to me that there are two basic functions to signals, in game and also in life: 1) don't let trains crash into one another, and, more importantly in most games; 2) by careful configuration to prevent a train obstructing another in it's movement. All of the consideration that goes into placing pre-signals and path signals in game is in pursuit of minimizing trains getting blocked, or worse, stuck. This patch adds another function, also found in the real world, to give trains information about when to reduce speed.Karn wrote:Hmm what should happen if I place more distant signals in a row?
ON the single track branch problem, we want out train to be aware of the end of the line and be able to brake appropriately. We also do not want our train to slow to a low speed while still on the mainline when it has plenty of distance left to travel. Leaving the branch un-signaled will cause the train to brake prematurely,y proceeding slowly down the line and possibly slowing other trains on the mainline. Signaling the branch, however, could permit a second train down the line that ends up trapping the first train. What we need is a way to provide the information to brake without providing the 'safe waiting point' function of a PBS. I envision that such signals would essentially be yellow or green only: regardless of how many are placed, the 'starter signal' will only admit a train to the branch if it can reserve all the way to a safe waiting point, the yellow/green only signals simply tell when the train starts to brake. Otherwise I guess the look-ahead function would need to be changed to behave differently on long single tracks somehow? Or some type of path based pre-signal that will only go to clear or caution if there is a string of green or yellows all the way to the next safe stopping point?
No problems - that's the reason I am testing weird station configurations, to find bugs.Karn wrote:OH **** , I swear I fixed this before posting v3, seems like there is more to fix.
Question: will the yellow signals still work on realistic acceleration instead of YAAM? In case someone wants the functionality but their play-style is more fun with stronger brake performance?
Thanks!
Re: [WIP] YAAM - Yet Another Acceleration Model
Station overbuilding is fine, it just re-reserve tracks. Block signal in wrong direction after station is the real reason. (see image) I'll try to fix this soon with other things (I hope this week). Thanks for report.supermop wrote:As far as I can tell, it may have been caused by overbuilding a station tile that had a path reserved through it.
And do you want signal type for this one side track situation? Or do you want something more general? For this situation would be enough if previous PBS would be always green. No reservation extending after distant signal, one signal color (red is not necessary in my opinion). I think it's easy to do it, but I'm not sure if this implementation uses whole potential of "not safe waiting position".supermop wrote:It seems to me that there are two basic functions to signals, in game and also in life: 1) don't let trains crash into one another, and, more importantly in most games; 2) by careful configuration to prevent a train obstructing another in it's movement. All of the consideration that goes into placing pre-signals and path signals in game is in pursuit of minimizing trains getting blocked, or worse, stuck. This patch adds another function, also found in the real world, to give trains information about when to reduce speed.
ON the single track branch problem, we want out train to be aware of the end of the line and be able to brake appropriately. We also do not want our train to slow to a low speed while still on the mainline when it has plenty of distance left to travel. Leaving the branch un-signaled will cause the train to brake prematurely,y proceeding slowly down the line and possibly slowing other trains on the mainline. Signaling the branch, however, could permit a second train down the line that ends up trapping the first train. What we need is a way to provide the information to brake without providing the 'safe waiting point' function of a PBS. I envision that such signals would essentially be yellow or green only: regardless of how many are placed, the 'starter signal' will only admit a train to the branch if it can reserve all the way to a safe waiting point, the yellow/green only signals simply tell when the train starts to brake. Otherwise I guess the look-ahead function would need to be changed to behave differently on long single tracks somehow? Or some type of path based pre-signal that will only go to clear or caution if there is a string of green or yellows all the way to the next safe stopping point?
Atm nope, I kept realistic acceleration intact. Maybe there is inconsistent behaviour somewhere, because I forgot to separate something but generally it works exactly like in YPS patch (no braking).supermop wrote:Question: will the yellow signals still work on realistic acceleration instead of YAAM? In case someone wants the functionality but their play-style is more fun with stronger brake performance?
In the future will be more reasonable to make parameter for accelerating speed in the yaam. Or I don't know. I wanted to avoid changing old trunk behaviour. When someone likes instant stopping with realistic AM, why to take it away from him.
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
Version 4 in first post.
I decided to separate 1 block reservation and 3 block reservation path signals. Hopefuly this can help in certain configurations. Also added parameter for acceleration speed. It brings question if it shouldn't be in Yellow Path Signals patch too.
I decided to separate 1 block reservation and 3 block reservation path signals. Hopefuly this can help in certain configurations. Also added parameter for acceleration speed. It brings question if it shouldn't be in Yellow Path Signals patch too.
If you are still interested, would be cool to have different graphics for 3 block reservations signals. (I can't use basic path signals graphics, i still need yellow there for consistency(not just visual))supermop wrote:Let me know if you want me to draw more signal types!
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
I'd be up for drawing some more - can you tell me a bit more about what you are thinking, and how the 1-block differs from vanilla PBS?Karn wrote: If you are still interested, would be cool to have different graphics for 3 block reservations signals. (I can't use basic path signals graphics, i still need yellow there for consistency(not just visual))
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
Here is explanation picture and ofc you can try in gamesupermop wrote:I'd be up for drawing some more - can you tell me a bit more about what you are thinking, and how the 1-block differs from vanilla PBS?Karn wrote: If you are still interested, would be cool to have different graphics for 3 block reservations signals. (I can't use basic path signals graphics, i still need yellow there for consistency(not just visual))
- Attachments
-
- vis.png (22.6 KiB) Viewed 8759 times
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
Ok - can the 1-block yellow signal ever show a green aspect? Or does it it only show yellow and red (I can't test at the moment).
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
Technically it can show green. If you turn off the patch, it should show green. And there is that optimalization with block signals/stations which use every color (I can change that though).
In normal cases it should be just yellow/red.
In normal cases it should be just yellow/red.
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
Would you prefer a 2-lens look for just yellow and red (we have a few like this on the NYC subway on speed restricted areas and in the midpoints of stations), and then the 'yellow' is 'green' when YAAM is turned off?
Or a 3-lens version with the green lens always dark?
Or a 3-lens version with the green lens always dark?
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
I was thinking more about this. And i realised that with 2 more signals we cant turn off yellow color. Probably it will be only yellow/red.
2-lens NYC sounds cool.
2-lens NYC sounds cool.
-
- Engineer
- Posts: 3
- Joined: 25 May 2017 18:42
Re: [WIP] YAAM - Yet Another Acceleration Model
If this is a problem then they would need to require a stop signal as well to function (like pre-signals; https://en.wikipedia.org/wiki/Railway_s ... nt_signals). Also, the semaphore path signal appears to have the distant/stop signals the wrong way round (https://en.wikipedia.org/wiki/Railway_s ... nt_signals), and the rest of the UK (EDIT: 'Drive on Left Side' Option) semaphores are also lower quadrant as opposed to this mod's upper quadrant (despite the fact that the latter replaced them in the '20s [https://en.wikipedia.org/wiki/Railway_s ... r_quadrant] - three decades before TTD's starting date and 10 years before TT's starting date). Then again, I'm probably in the wrong place to talk about consistency with real life (even though I'm pretty sure I am).Karn wrote:Hmm what should happen if I place more distant signals in a row?supermop wrote:Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
- MinchinWeb
- Traffic Manager
- Posts: 225
- Joined: 01 Feb 2011 12:41
- Contact:
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
It's an interesting problem so I'm glad you're thinking about it.
As I think about this in regards to my own gameplay, I think it could be useful to solve two particular issues I run into:
As I think about this in regards to my own gameplay, I think it could be useful to solve two particular issues I run into:
- on merges, to give priority to the train currently running at speed, and
- on congested mainlines, to allow trains to flow at reduced speed rather than fits of starts and stops.
Alberta Town Names - 1500+ real names from 'Acme' to 'Zama City'
MinchinWeb's Random Town Name Generator - providing 2 million plus names...
WmDOT v13 - An AI that doubles as your highway department
MinchinWeb's Random Town Name Generator - providing 2 million plus names...
WmDOT v13 - An AI that doubles as your highway department
Re: [WIP] YAAM - Yet Another Acceleration Model
So I almost implemented distant signal (1 block PBS), except it has red aspect and reserve path one tile later. I see flaw in current implementation too, because it still reserve too far and too soon. I'll try to change it to distant signal, which can be more useful.marinesciencedude wrote:If this is a problem then they would need to require a stop signal as well to function (like pre-signals; https://en.wikipedia.org/wiki/Railway_s ... nt_signals). Also, the semaphore path signal appears to have the distant/stop signals the wrong way round (https://en.wikipedia.org/wiki/Railway_s ... nt_signals), and the rest of the UK (EDIT: 'Drive on Left Side' Option) semaphores are also lower quadrant as opposed to this mod's upper quadrant (despite the fact that the latter replaced them in the '20s [https://en.wikipedia.org/wiki/Railway_s ... r_quadrant] - three decades before TTD's starting date and 10 years before TT's starting date). Then again, I'm probably in the wrong place to talk about consistency with real life (even though I'm pretty sure I am).Karn wrote:Hmm what should happen if I place more distant signals in a row?supermop wrote:Adding signals for the train entering the branch has the danger of letting a following train down and trapping the first on the branch line. Single track also has the issue that it is normally not signaled except for passing loops, so reservations can extend and block track much farther and earlier than desired, or end up with a train travelling a huge distance at reduced speed. It might be helpful to add a 'distant' signal, without a red aspect, that does not serve as a possible stopping point for trains, but does warn them of need to reduce speed ahead. This would let trains do their deceleration off the mainline, near the actual end of line, without trapping other trains.
This patch has goal of making TTD more consistent with real life, place is right But I'm not the person who can answer this.
Those 2 problems are actually even worse. Yellow can bring solution to this, but every magic comes with a price. The price can be track performance. Basic concept I haven't realise before is, that yellow increase distance between trains. Although trains will move more fluent, their frequency is reduced. Lower throughput appears to be cost of braking and realism. But I didn't test this much, I can be wrong.MinchinWeb wrote:It's an interesting problem so I'm glad you're thinking about it.
As I think about this in regards to my own gameplay, I think it could be useful to solve two particular issues I run into:
- on merges, to give priority to the train currently running at speed, and
- on congested mainlines, to allow trains to flow at reduced speed rather than fits of starts and stops.
Re: [WIP] YAAM - Yet Another Acceleration Model
I think it depends on the train. The faster trains accelerate, the better the current model.Karn wrote:Those 2 problems are actually even worse. Yellow can bring solution to this, but every magic comes with a price. The price can be track performance. Basic concept I haven't realise before is, that yellow increase distance between trains. Although trains will move more fluent, their frequency is reduced. Lower throughput appears to be cost of braking and realism. But I didn't test this much, I can be wrong.
But for more realistic, slowly accelerating trains, not coming to a complete stop as often should increase throughput.
Of course, a system with one signal per piece of track will work optimally for both cases with the current braking system, but it's pretty ridiculous.
-
- Engineer
- Posts: 3
- Joined: 25 May 2017 18:42
Re: [WIP] YAAM - Yet Another Acceleration Model
Good to hear it, let's move on!Karn wrote: So I almost implemented distant signal (1 block PBS), except it has red aspect and reserve path one tile later. I see flaw in current implementation too, because it still reserve too far and too soon. I'll try to change it to distant signal, which can be more useful.
This patch has goal of making TTD more consistent with real life, place is right But I'm not the person who can answer this.
The problem with the distant signal having a red aspect (stop) is that it would be more like the combined signals, but you haven't mentioned the green aspect (clear) yet. I'll have to deal with this compromise until consistency with real life is eventually achieved or when I can help with the patch (which I'm not sure will happen any time soon).
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
Progress is slow, fixed few bugs, I'll make version 5 when there will be more content.
I also decided to put it on github https://github.com/Palo123/openttd_yaam
Video showing what's about unsafe version (it's just demo-hack, doesn't work in other cases yet)
I also decided to put it on github https://github.com/Palo123/openttd_yaam
Video showing what's about unsafe version (it's just demo-hack, doesn't work in other cases yet)
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
I really like the concept of this acceleration model, because I think that it would increase player focus towards choosing vehicles that are well-suited for their actual operations and ensuring that the infrastructure supports the speeds they aim for. With the excessive acceleration across the board in the current "Realistic" model (augmented by the fact that the launch tractive effort is maintained as continuous tractive effort), passenger trains are mainly purchased based on their top speed properties, because they almost universally offer strong acceleration and spend most of their time cruising at top speed. This leads to services with very frequent stops being operated with vehicles capable of high top speeds, even if they would rarely be achieved on such a service realistically, rendering other vehicle types that are technically better-suited in real life obsolete due to this distorted focus.
Seeing that you're also active with Realistic Train Shunting, Karn, I'd like to ask you: has any more work on this acceleration model happened since the last update?
Seeing that you're also active with Realistic Train Shunting, Karn, I'd like to ask you: has any more work on this acceleration model happened since the last update?
Re: [Patch][WIP] YAAM - Yet Another Acceleration Model
Currently I'm too busy with personal life. Both yaam and rts are on hold until I find free time for it.Valle wrote: Seeing that you're also active with Realistic Train Shunting, Karn, I'd like to ask you: has any more work on this acceleration model happened since the last update?
When it comes to priorities, I would like to finish shunting patch first and after it's done, then work on yaam again. Shunting patch is more rewarding to develop.
Who is online
Users browsing this forum: No registered users and 20 guests