[Patch][WIP] YAAM - Yet Another Acceleration Model

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

[Patch][WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 08 Feb 2016 22:26

Here's serious first post.

This patch tries to solve 2 issues that bothers me.
First - decelerating. Everybody can notice, trains in trunk/stable openttd accelerate gradually, but brakes instantly. This doesn't look nice and behaves weird compared to reality.
Second - too easy track designing and signal designing. You can literally put signal on every tile, do basic station scheme and you are making billions.

How to solve this?
1) Obviously some programming - making trains to compute braking distance, making them brake at right moment. Also useful thing here is my yellow path signal patch. With more signal colors make braking more sense.
2) If we say, the physics is important here. When trains have ability to brake, there is place for not braking on time. Tl dr; there will be unsafe switch button in setting for allowing trains to pass red light on signal. This can happen if signals are too dense, because green signals have unlimited speed limit.
There are other options to include in hardcore mode - Train can derail on too sharp curve (for example train going 200km/h on 90°turn should derail instead of instant braking). Also going too fast on brigdes is option for this. If we think about this, then we need something effective for certain speed limits. In my opion this patch http://www.tt-forums.net/viewtopic.php?f=33&t=73745 is best for speed limits in such situations.

Status of implementation
1) Functionality almost done. Code need some refectoring, settings need refactoring, but things kind of work.
2) Nothing done yet, I need more free time.

Known bugs
Advanced settings are mess. To have things work as designed, you need allowed yellow signals, YAAM acceleration model for trains, turned on looking at next signal and turned on allow slowing down in stations. It might work with other settings, but it's developed for these. (please don't report weird behaviour in different settings).
Block signals are useless with yaam, don't use them.
Braking distances are not always perfect.

v4 changes:

-added new signal type for 3 reservations
-station braking should now work
-added setting for adjust train acceleration(deceleration)
-changed speed limits for yellow colors a little
-fixed crashing bug
-fixed reservation when train stops in station
Attachments
openttd-yaam-r27505_v4.zip
patch + windows binaries
(7.06 MiB) Downloaded 84 times
Last edited by Karn on 13 Mar 2017 20:34, edited 3 times in total.

Zealotus
Engineer
Engineer
Posts: 3
Joined: 06 Jan 2010 05:18

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Zealotus » 16 Feb 2016 20:07

I must say I really like this idea!

I'm already playing the game with heavily decreased acceleration (it has always bothered me that a freight train of 16-20(+) loaded wagons accelerates to top speed in just a few squares).
But, sadly, they still go from 120 to 0 within a single square... which, if anything, bothers me even more!

But I must ask if this is taking the train characteristics into consideration?
Almost all DMUs and EMUs have close to instant brake response since their brakes are controlled electronically (and most even have magnet brakes for use in emergencies).
But then we have the traditional locomotive(s) and wagons trains that use air preassure to controll their brakes. Longer train = longer brake response.
And, of course, the train's total weight has a very high impact on its stop distance.

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 22 Feb 2016 17:39

I read articles about train deceleration. Generally irl, there is deceleration limit around 1ms^2. Some freight trains have it lower (0,6ms^2), some EMU's higher (1,3ms^2). This is because some surface steel coefficient blah blah and other complicated reasons.
As everybody knows, train acceleration in ttd isn't real on any meaningful scale. Deceleration is just a bad joke. So I picked one scale, which is time in seconds. I will ignore ttd days since now (they can be changed via daylenght patch anyway).
Reason why the acceleration is wrong - it counts ticks as seconds. So we have quite good model, but it's scaled "wrong" for gameplay purposes. Here is my first attempt to do something about it.

- computed acceleration in YAAM is in real seconds, instead of seconds substituted by game ticks.
- trains see 3 tiles ahead (when it's enabled in Yellow PBS settings, this has side effect, that it enables sooner acceleration too, I will separate this later) - they can attempt to brake sooner on yellow/double yellow signals.
- there is assumption, that every engine and wagon has brakes with force 1kN per 1ton of weight, which results in 1ms^2 deceleration.
- engines have additional dynamic brake, this is basically old method of braking scaled to seconds.

Some of my observations:
To test this, I built something similar to Circular particle accelerator :mrgreen:
Trains with less wagons have shorter braking distance - dynamic brake reason.
AsiaStar without wagons going 265km/h (max speed) needs 35 tiles to stop.
Maglev Lev4 of lenght 8 (2x loco and 14 empty wagons) needs, ~60 tiles to stop.
According to seconds point of view, tile has ~18 meters.

Things I think about adding in next version:
Make that unsafe version with trains passing red lights.
Introduce emergency braking on red signals - by breaking down the train. This will be nice, because emergency brake needs some time to be released. On safe version, train will break down. On unsafe train will break down and pass the red signal.
Gradually braking in front of red signal, something like - planned speed 1 tile before red signal will be 20km/h, 2 tiles 30km/h etc.
I might be wrong, but tunnels and brigdes most likely don't understand my 3 tiles ahead thing. <- fixing this, making 3 tiles configurable and try to make repeating signal
Zealotus wrote:But I must ask if this is taking the train characteristics into consideration?
Almost all DMUs and EMUs have close to instant brake response since their brakes are controlled electronically (and most even have magnet brakes for use in emergencies).
But then we have the traditional locomotive(s) and wagons trains that use air preassure to controll their brakes. Longer train = longer brake response.
And, of course, the train's total weight has a very high impact on its stop distance.
I'm not sure, if brake delay isn't more annoying than wanted feature. It complicates whole idea, and simulating pipe pressure is little overkill for me, when you can't control trains. I'm little lost at weight. Do exist brakes depending on train load? I mean when wagon is fully loaded, then it would unlock more braking power, because there is more adhesion..? (even if doesn't this patch acts like it does :D )

here is patch including yellow pbs and yaam.

Edit attached NewGRF with signal sprites.
Attachments
trunk-r27505-yellow_pbs_8_1-yaam.diff
(61.51 KiB) Downloaded 84 times
PBS_4_Aspects.grf
(27.56 KiB) Downloaded 97 times
Last edited by Karn on 28 Feb 2016 10:41, edited 1 time in total.

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9278
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by planetmaker » 22 Feb 2016 18:10

Are you aware that you can set in plain OpenTTD without any patches or modifications the desired travel speed for a train between two of its ordered stations / waypoints?

As such, I'm not sure what problem you really try to solve.

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 22 Feb 2016 18:27

Ofc I am :) This question is one of reasons, why I need the waypoint patch. You have to ask, if I'm aware of very hidden feature which is opposite of user friendly, when you have 300 trains going regularly over specific tiles and suddenly want speed limit there.

User avatar
JGR
Tycoon
Tycoon
Posts: 1951
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by JGR » 22 Feb 2016 19:29

planetmaker wrote:Are you aware that you can set in plain OpenTTD without any patches or modifications the desired travel speed for a train between two of its ordered stations / waypoints?

As such, I'm not sure what problem you really try to solve.
Setting a maximum speed for a particular order is not the same thing as having non-zero braking distances.
To me at least it comes across as a difficulty/realism feature rather than a way of running individual trains at a lower speed.


I would suggest staying away from complicated physics modelling like brake pipe delays and so on. The physics in the rest of the game is not nearly as thorough as that.
Using a straightforward braking curve allows the braking distance and max speed to brake in time for a given red signal/speed restriction to be calculated easily.
Given that, what I would instead suggest considering is using the braking distance calculated above to determine the minimum required reservation length and the maximum speed as the reservation is followed, instead of hard-coding speeds for particular signal aspects.
Longer signal spacing doesn't then result in excessively long reservations or low speeds (e.g. the single track with loops problem on the other thread), and short signal spacing doesn't then result in trains having insufficient reservation for the speed that they're travelling at.
This also means that you don't need to hard-code a separate braking curve for approaching a red signal as your reservation (at the point you passed the previous signal) would already extend up to that point (but it may be worth doing something slightly different when stopping at a platform at a point other than at the end of the reservation).
(If you wanted to be really fancy you could do braking and/or constrain your reservation length for curves by following the reservation as well, but that might be a bit much to start with).

Bridges/tunnels do pose some challenges but I don't think they should be problematic in this case (unless you try to integrate this with the signals on bridges/tunnels patch, in which case you will have a significant issue).
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 22 Feb 2016 20:57

JGR wrote:Given that, what I would instead suggest considering is using the braking distance calculated above to determine the minimum required reservation length and the maximum speed as the reservation is followed, instead of hard-coding speeds for particular signal aspects.
Longer signal spacing doesn't then result in excessively long reservations or low speeds (e.g. the single track with loops problem on the other thread), and short signal spacing doesn't then result in trains having insufficient reservation for the speed that they're travelling at.
This also means that you don't need to hard-code a separate braking curve for approaching a red signal as your reservation (at the point you passed the previous signal) would already extend up to that point (but it may be worth doing something slightly different when stopping at a platform at a point other than at the end of the reservation).
(If you wanted to be really fancy you could do braking and/or constrain your reservation length for curves by following the reservation as well, but that might be a bit much to start with).

Bridges/tunnels do pose some challenges but I don't think they should be problematic in this case (unless you try to integrate this with the signals on bridges/tunnels patch, in which case you will have a significant issue).
I have 2 questions about this ETCS level 2 behaviour
How to calculate braking distance including slopes? (I don't like physics, so I'm not gonna be the guy, who will create formula for this)
Excluding realism, what's the gameplay benefit of ETCS level 2?

User avatar
JGR
Tycoon
Tycoon
Posts: 1951
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by JGR » 22 Feb 2016 22:45

Karn wrote:I have 2 questions about this ETCS level 2 behaviour
How to calculate braking distance including slopes? (I don't like physics, so I'm not gonna be the guy, who will create formula for this)
You could do something very fancy for calculating an exact distance, but most likely a simple calculation with an error margin tacked on would be fine.
To a first degree of approximation with a (point mass) train with a fixed braking force such that braking on the flat has a constant acceleration, taking v = end speed, u = start speed, a = acceleration due to braking, s = distance, h = height increase, with h << s, you could use v^2 = u^2 + 2as - 2gh, and solve depending on which end of the reservation you want to calculate from.
I'm not suggesting going as far as ETCS level 2 in terms of having movement authority independent of track-side signals, I'm more thinking in terms of having a better "driver" and "signaller" within the same 4-aspect signalling system.
Karn wrote:Excluding realism, what's the gameplay benefit of ETCS level 2?
If you want to "Make that unsafe version with trains passing red lights." or "emergency braking on red signals" at the same time as having a constant/upper limit of braking deceleration you'll probably want to have implement something along these lines, as otherwise you'll have issues trying to build a layout that can cope with fast trains short of adding lots of manual speed limits, especially if you're talking 35 tile braking distances.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 23 Feb 2016 00:04

Okay, now I get why I need braking distance for better driver. To get rid off 3 tiles ahead watching.
Thx for formula, I will look at this rocket science tomorrow :D
Good, this actually sounds like worth implementing.
For example if we have signal, 1 tile, signal, 6 tiles, signal, 3 tiles, signal, 2 tiles and train going left S-S------S---S--<TWWWW--
There will be red signal, yellow signal with speed limit 20km/h, double yellow 80km/h, green signal and train going for example with its maximum speed 200km/h? 20km/h and 80km/h are based on future braking distance formula.
If there aren't more free tracks, this would lead to emergency braking. I hope I understand what you tried to say.

pi1985
Engineer
Engineer
Posts: 107
Joined: 16 May 2013 08:22
Location: Ukraine

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by pi1985 » 28 Feb 2016 06:34

Your patch tries to load PBS_4_Aspects.grf. Where can I get it?
Image
Image
Image.

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 28 Feb 2016 10:52

It's part of Yellow Path Signals patch. I guess it's good idea to have copy here for archive reasons. It's now attached in this thread too.

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 29 Feb 2016 20:13

I made progress on this.
My friend, who knows something about physics helped me to improve JGR's formula on slopes. It calculates average slope steepness and affect deceleration in formula, it's good enough for every standard case.
I realised, that trains calculate speed 2 times per tick, so my formula isn't correct either, acceleration/deceleration is still 2x faster/slower than in-game units. Although, correct formula makes trains too slow.. I will stick with v1 formula for now.

changes in v2:
- trains are smarter - they calculate braking distance and in most cases slow down soon enough in front of red PBS.
- signals are smarter - with respect to max (double) yellow settings, the speed on yellow and double yellow aspects varies. Bigger distance between signals means bigger speed limit on signals.
- when train is going faster than 25km/h on red signal, it will break down.
- looking at next signal color setting serves again its purpose.
- braking force is 1KN per 1 ton + Max tractive effort. (AsiaStar without wagons can stop on 17 tiles, AsiaStar length 5 - with 8 empty wagons can stop on 26 tiles)

Updated TODO list:
- unsafe collision version
- better behaviour with dynamic speed limits, when train max speed is lower than yellow and double yellow settings.
- better separation of this feature in code when using i.e. original acceleration model.
- smooth braking in stations & depots.
Attachments
trunk-r27505-yellow_pbs_8_1-yaam_2.diff
(69.81 KiB) Downloaded 99 times

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 07 Nov 2016 10:54

I'm still alive and sometimes working on this. Version 3 released (in the first post). Change from previous version: Trains now brake in stations.

User avatar
supermop
Tycoon
Tycoon
Posts: 1042
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by supermop » 07 Nov 2016 15:40

Karn wrote:I'm still alive and sometimes working on this. Version 3 released (in the first post). Change from previous version: Trains now brake in stations.
Cool! Curious to try it if anyone has a binary! Glad to hear you are still working on this!

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 08 Nov 2016 10:10

Binary posted, I hope you use windows :D

User avatar
supermop
Tycoon
Tycoon
Posts: 1042
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by supermop » 08 Nov 2016 20:59

Karn wrote:Binary posted, I hope you use windows :D
I do! Thanks!

User avatar
supermop
Tycoon
Tycoon
Posts: 1042
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by supermop » 10 Nov 2016 03:53

Not sure if intentional or not - I personally almost never use block signals anymore, but while playing around with breaking distances (in 1910 my trains are too slow to pass a red at danger...) I noticed something.

If the look-ahead reservation from a path signal ends at a green block signal, the PBS will show green aspect, but as soon as the train passes the green block signal, it will brake down to 15kmh. The train will continue to run at 15kmh, through any further green block signals, until it reaches a path signal, at which time it will accelerate to the speed permitted by aspect as normal.
PBS to Block.PNG
PBS to Block.PNG (149.97 KiB) Viewed 3996 times
If the Block signal is red, the path signal will still show a green aspect before it, and the train will proceed right up to the red block signal at full speed, passing it at danger (in the shown case that means emergency brake breakdown).
Path to Block SPAD.PNG
Path to Block SPAD.PNG (119.6 KiB) Viewed 3996 times
I don't really have a strong opinion for or against this behavior, I can see justifications on both sides. Of course, the distant aspects of signals in this patch are based on the path reservation, which ends at a block signal, so there is no easy way to determine the appropriate state of the line ahead.

Thinking of ways to use this behavior, with small modifications, one could envision some case where one does want to signal a line, but for visual stopping distance speeds. In this case, it would be fine for bock signals to give such a limited speed, but the path signal should reflect that the reservation does not extend, and show a yellow aspect instead. This would let trains have a better chance of stopping at a red block signal if needed.

In arguing for a more substantial change, some players seem to use long stretches of block signals in places (although that precludes the advantages of yellow signals..) If they were to load an old game in this patch, they might be faced with hours of signal converting (maybe that is the point, to deprecate block signals in a fail-safe way?). Maybe those players would prefer all block signals give the unlimited or yellow speed instead of shunting speed, and let what accidents come what may. I can't really think of a good 'third way' around this at this time.

Best,

xZise
Engineer
Engineer
Posts: 57
Joined: 19 Mar 2009 16:52
Location: Bad Schwartau

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by xZise » 11 Nov 2016 13:47

I think it is possible to avoid requiring hard speed limits by reserving a path past than the next signal(s).

The basic idea is that the train is so fast that the breaking distance is as long as the length of the reserved path. This can be done by reserving past at least one signal (kind of like two blocks) before it is too close to the next signal. Originally it would only switch to green when the train is at the signal, but then the breaking distance is short and forcing the train to be slow enough to stop at the signal. Now your yellow path signal patch allows to reserve past the next signal and this increases the available breaking distance and drive faster.

So if the signals shows green, it actually reserves past three signals (the green, double yellow and yellow ones) and it uses the distance to the next red signal as the breaking distance. So if the train can come to a stop before that red signal (breaking distance < reserved path) it can accelerate and otherwise it needs to decelerate. Now you include yellow path signals in this patch, but in theory any number of signal aspects would work, even using the stock signals. The signal just needs to switch to green before the train actually starts to slow down.

Additionally there could be another system like ETCS level 2, where it knows how far the actual red signal is away. Without it a green signal means that there is a red signal after 4 signals (using yellow path signals and including the green one). If that distance is to short for the maximum speed, the train will never reach the speed. So with a system “like” ETCS level 2, it would know that after the green signal, there is another green signal (and so forth) and it could have longer breaking distances. This would require to reserve even more track, although that would be required anyway if the breaking distance is so long then.

I only say “like” ETCS level 2, because you don't actually have to implement anything complicated. You “just” need to reserve a longer path than without it. There shouldn't be any additional logic required. In theory you can just reserve as much signals as possible (and necessary?) and just use green for every signal except the last two (excluding the red signal). You could add another track type which “adds” this support or you add a feature to trains to show whether they support this system.

EDIT: I have now looked at the patch and updated the post accordingly.

Karn
Engineer
Engineer
Posts: 127
Joined: 02 Oct 2011 18:56

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by Karn » 11 Nov 2016 19:57

supermop wrote:If the look-ahead reservation from a path signal ends at a green block signal, the PBS will show green aspect, but as soon as the train passes the green block signal, it will brake down to 15kmh. The train will continue to run at 15kmh, through any further green block signals, until it reaches a path signal, at which time it will accelerate to the speed permitted by aspect as normal.
15kmph on block signals is not intentional. As I remember, it's there for dealing with stopped trains in some cases. I'll try to fix it better way, it's side effect.
supermop wrote:I don't really have a strong opinion for or against this behavior, I can see justifications on both sides. Of course, the distant aspects of signals in this patch are based on the path reservation, which ends at a block signal, so there is no easy way to determine the appropriate state of the line ahead.

Thinking of ways to use this behavior, with small modifications, one could envision some case where one does want to signal a line, but for visual stopping distance speeds. In this case, it would be fine for bock signals to give such a limited speed, but the path signal should reflect that the reservation does not extend, and show a yellow aspect instead. This would let trains have a better chance of stopping at a red block signal if needed.

In arguing for a more substantial change, some players seem to use long stretches of block signals in places (although that precludes the advantages of yellow signals..) If they were to load an old game in this patch, they might be faced with hours of signal converting (maybe that is the point, to deprecate block signals in a fail-safe way?). Maybe those players would prefer all block signals give the unlimited or yellow speed instead of shunting speed, and let what accidents come what may. I can't really think of a good 'third way' around this at this time.
I don't know any good answer for block signals either. They shouldn't ignore whole YAAM, it would be inconsistent. But train knows nothing about his future inside block of block signals. Technically, if block signals were only on straight tracks without intersections - no spliting nor merging - they can deal with yellow. But including possibility of intersections ruins everything. So yea, for now I can think of only 2 options <insert speed limit here> or "just act like there is no YAAM".
xZise wrote:I think it is possible to avoid requiring hard speed limits by reserving a path past than the next signal(s).

The basic idea is that the train is so fast that the breaking distance is as long as the length of the reserved path. This can be done by reserving past at least one signal (kind of like two blocks) before it is too close to the next signal. Originally it would only switch to green when the train is at the signal, but then the breaking distance is short and forcing the train to be slow enough to stop at the signal. Now your yellow path signal patch allows to reserve past the next signal and this increases the available breaking distance and drive faster.

So if the signals shows green, it actually reserves past three signals (the green, double yellow and yellow ones) and it uses the distance to the next red signal as the breaking distance. So if the train can come to a stop before that red signal (breaking distance < reserved path) it can accelerate and otherwise it needs to decelerate. Now you include yellow path signals in this patch, but in theory any number of signal aspects would work, even using the stock signals. The signal just needs to switch to green before the train actually starts to slow down.
It's not how things exactly work. Speed limits for yellow signals are actually based on braking distance too. Train compute its speed for yellow signal and double yellow signal. It knows speed on red, yellow and doubleyellow. Red is always 0, yellow is computed as minimum from yellow setting and distance to red. Double yellow is computed as minimum from double yellow setting and distance and speed on yellow.

Forced speed limits settings are in bug list. Their forced nature is yellow path signals feature, here it's bug though. But even now you can set it to "unlimited" (if all your important trains have max speed 200, you can set it both to 190 (or 195 and 190, I have bad memory) and it will act like unlimited).
xZise wrote:Additionally there could be another system like ETCS level 2, where it knows how far the actual red signal is away. Without it a green signal means that there is a red signal after 4 signals (using yellow path signals and including the green one). If that distance is to short for the maximum speed, the train will never reach the speed. So with a system “like” ETCS level 2, it would know that after the green signal, there is another green signal (and so forth) and it could have longer breaking distances. This would require to reserve even more track, although that would be required anyway if the breaking distance is so long then.

I only say “like” ETCS level 2, because you don't actually have to implement anything complicated. You “just” need to reserve a longer path than without it. There shouldn't be any additional logic required. In theory you can just reserve as much signals as possible (and necessary?) and just use green for every signal except the last two (excluding the red signal). You could add another track type which “adds” this support or you add a feature to trains to show whether they support this system.
Too hard to implement. 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. Also braking distance isn't predictable before reserving track with simple math (think about hills).

xZise
Engineer
Engineer
Posts: 57
Joined: 19 Mar 2009 16:52
Location: Bad Schwartau

Re: [WIP] YAAM - Yet Another Acceleration Model

Post by xZise » 11 Nov 2016 22:46

Karn wrote:[…]But even now you can set it to "unlimited" (if all your important trains have max speed 200, you can set it both to 190 (or 195 and 190, I have bad memory) and it will act like unlimited).[…]
Okay should've looked closer, because in that case it looks nice. And being able to determine an upper limit is fine I guess, as anyone could deactivate it anyway.
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.[…]
Is that a basic part of OpenTTD or what makes this hard?
Karn wrote:[…]Also braking distance isn't predictable before reserving track with simple math (think about hills).
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.

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: Google [Bot] and 2 guests