![Shocked :shock:](./images/smilies/icon_eek.gif)
Sorry, JGR.
Leaving original post for context.
Moderator: OpenTTD Developers
I'm fairly sure that there weren't any diagonal level crossings in TTDPatch.
There is an open draft PR for it on mainline, but it needs a lot of work before it'll be ready. https://github.com/OpenTTD/OpenTTD/pull/8556
I commented about this a year ago in the placing houses patch topic.Emperor Jake wrote: ↑29 Mar 2021 13:32 Anyway, while I'm enjoying messing with the new town zone customisation I came to complain about a discrepancy:
...
as you can see, the innermost town zone is called zone 1 by the place buildings menu but zone 4 in the settings menu. I think what the buildings menu uses is far more intuitive, even if it's not how the game numbers them internally.
Which version are you using? There was a fix for braking behaviour when descending slopes in the most recent version (v0.40.5).Snail wrote: ↑02 Apr 2021 17:15 Hey JGR,
I'd like to get a better understanding of the "realistic braking" feature, especially with trains going downhill. One of the things that annoyed me about TTD, was to see long, heavy consists going full speed on steep downhill tracks, which is very unrealistic, especially for freight trains. I was hoping this feature would finally stop that.
I just ran a test, and it sounds like some work has been done on that side, but it still behaves a bit strangely. In the attached screenshots:
ttd braking downhill.png
Sorry for the sprite size. I needed to post 4 screenshots, but the forum only allows for 3 attachments, so I had to cram them in the same file.
So, I bought a railcar with a max speed of 100 km/h on a mountain top, and sent it on a long downhill track. The track has path-based signals, which can be crossed on the opposite side, at a regular distance.
1. Top left: Before approaching the downhill track, the train runs at full speed. So far, so good.
2. Top right: I would expect it to slow down as soon as it approaches the downhill part of the track, or (even better) a while before, but no: it keeps doing downhill at full speed.
3. Bottom left: just before approaching the first signal in the downhill track, the train slows down to a more reasonable speed of 42 km/h. I would have expected this to happen a while before, but anyway...
4. Bottom right: this is what baffles me. Right after passing the signal, the train immediately releases its brakes and goes back to full speed. But the track is still going downhill...! That would be quite a dangerous move in real life. At least, a speed increase should happen gradually.
Is this the normal behavior of the patch? Or am I doing something wrong as I placed the signals?
Connected to this, I'd still like to be able to change a consists' braking distance according to the types of vehicles in it. Perhaps this would require a new vehicle property?
Is brake force modelled?
Brake force is modelled in the realistic acceleration model in trunk, though in almost all cases it's just "big constant".andythenorth wrote: ↑02 Apr 2021 19:46Is brake force modelled?![]()
[Light engines are speed restricted in the UK as they often don't have enough brake force to meet stopping distances]
Thanks for your reminder! I was still using 0.40.4. I just upgraded to 0.40.5, and now the train doesn't slow down at all.
Got it. I wouldn't have minded passenger trains to also slightly reduce speed on long downhill tracks, but that's fair enough.
Yep, that would be cool. What would the required steps to make it happen be?JGR wrote: ↑02 Apr 2021 18:23 The NewGRF spec doesn't include anything to do with braking, so the parameters are derived from the things which are specified: power, air resistance, weight, train length, in as way that is consistent with the current acceleration model (original or realistic acceleration). I'm not averse to adding a way to override this from NewGRF in future though.
If the train had been full when you sent it down, the calculated braking acceleration would probably have gone negative (i.e. increasing speed with time when braking), this gets clamped and triggers the brakes overheated breakdown.Snail wrote: ↑02 Apr 2021 20:41 On the other hand, I build a 180-ton freight train (a diesel engine and 15 empty hopper wagons) and sent it on the same track, i.e. a long downhill route. Now it slows down from its top speed of 50 km/h, to something like 9 km/h ...
Isn't that a bit too sharp of a decrease? I'd expect that train to approach the downhill track to around 20 km/h, or maybe at least 15.
I would need to think of spec extensions and any associated changes to the physics model, implement, test and document them, and then update my NML fork.
There is a setting in advanced settings called Enable improved breakdowns. Turning this off will resolve this.
Code: Select all
Check train entry direction
> If BACK - apply varying penalty to make trains prioritize different platforms depending on their direction, i.e. no awkward crossing over
> ELSE - Check current order and maximum train speed
>> If train doesn't stop at the station AND is faster than specified
- the signal should attempt a long reserve. BOTH conditions must be true.
>> If only one or neither of these conditions apply, nothing should happen
- the train is either stopping (therefore it would pointlessly block the crossovers)
- or isn't fast enough to warrant a preferrential treatment
Users browsing this forum: No registered users and 3 guests