JGR's Patch Pack

[gebik]

Okay, okay, just noticed, it was all behaving correctly. Just changed it back to sorting by numbers, and even do not know, when I switched it to sorting in alphabetical order...

Sorry, JGR.
Leaving original post for context.

[Gadg8eer]

Is there any chance of adding diagonal rail crossings? They were in TTDPatch but disappeared when the patch did. No one seems to have done any work on making them available in OpenTTD.

Sorry if this has been asked before.

[JGR]

Is there any chance of adding diagonal rail crossings? They were in TTDPatch but disappeared when the patch did. No one seems to have done any work on making them available in OpenTTD.

Sorry if this has been asked before.

I'm fairly sure that there weren't any diagonal level crossings in TTDPatch.
I was one of the TTDPatch developers and I think that I would remember if that was added.
Searching the codebase doesn't turn up anything either.

It's not something that I'm planning on looking into, and none of the attempts that I've seen so far appear to be much good.
There are also no sprites for it.

[jfs]

Is there any chance of adding diagonal rail crossings? They were in TTDPatch but disappeared when the patch did. No one seems to have done any work on making them available in OpenTTD.

Sorry if this has been asked before.

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

[Eddi]

as far as i remember, the only thing that ever had diagonal crossings in was the MiniIN some 15-ish years ago. the aforementioned PR is based on that old patch, but a lot has changed since then, particularly about NewGRFs (railtypes, roadtypes, etc.) that is not (yet) supported, and the code quality hasn't aged well either.

[Emperor Jake]

Ah, the Mini IN. My very first patchpack. As I recall it aslo had a setting to disable engine (not wagon) speed limits which was interesting

Anyway, while I'm enjoying messing with the new town zone customisation I came to complain about a discrepancy:

discrepancy.PNG (37.82 KiB) Viewed 2420 times

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.

[wallyweb]

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.

I commented about this a year ago in the placing houses patch topic.
As you can see this is a NewGRF specification and a couple of varAction 2s are also involved.
It might be easier to fix the patch than to change the specs.
By the way, here is a helpful related little newobject tool that I use.

[Aegir]

I wrote that patch so allow me to chime in; tbh I think it's the house placing patch that's got it wrong to be honest, probably because they've looked at the newgrf spec for house availability and accidentally read it backwards. How it then ended up being 1-5 instead of 0 > 4 or 4 > 0 though is anyones guess.

https://newgrf-specs.tt-wiki.net/wiki/V ... e_.2842.29

Zone 4 is the central zone and zone 0 is the outer most. This is consistent with the newgrf spec for writing newgrf houses, consistent with the raw variable names inside OpenTTD source code, and also consistent with the grf debug view for newhouses. I see no benefit whatsoever in changing the patch to contradict the newgrf spec or the game source code. That's a bad outcome for developers, a bad outcome for newgrf authors as well. I'll have a chat to JGR and see if changing the house picker UI is a better way to go.

As a side note; my favorite settings for that patch are 255/4/3/2/1 .

[Snail]

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

(372.38 KiB) Not downloaded yet

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?

[JGR]

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?

Which version are you using? There was a fix for braking behaviour when descending slopes in the most recent version (v0.40.5).

A single light engine on its own like this will probably not need to reduce speed at all when descending.
Descending slopes at a reduced speed is only really an issue for freight.

The model that I'm using is by necessity simplified and dispenses with several aspects of real life physics.
As a result of that and to make the game internally consistent braking performance is probably better than it would be in real life. Trains braking slower than they accelerate breaks the illusion a bit, and train acceleration is also probably overpowered compared to real life. The strange time/length scaling in OpenTTD sort of requires this. (Things like weather and leaves also do not exist in OpenTTD).
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.

[andythenorth]

A single light engine on its own like this will probably not need to reduce speed at all when descending.

Is brake force modelled?

[Light engines are speed restricted in the UK as they often don't have enough brake force to meet stopping distances]

[JGR]

A single light engine on its own like this will probably not need to reduce speed at all when descending.

Is brake force modelled?

[Light engines are speed restricted in the UK as they often don't have enough brake force to meet stopping distances]

Brake force is modelled in the realistic acceleration model in trunk, though in almost all cases it's just "big constant".

In real life the axles at the front of the train can have less braking effect than the axles further back in the train because of the drying effect of the wheels themselves.
Then you have things like brake fade, rheostatic braking, wheel slip, etc.
I don't want to model any of this sort of stuff, I think it'd be a bit too overkill.

[Snail]

Which version are you using? There was a fix for braking behaviour when descending slopes in the most recent version (v0.40.5).

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.
By the way, each of your new versions compiles nice and easily on my OS 10.12. I greatly appreciate that!

A single light engine on its own like this will probably not need to reduce speed at all when descending.
Descending slopes at a reduced speed is only really an issue for freight.

Got it. I wouldn't have minded passenger trains to also slightly reduce speed on long downhill tracks, but that's fair enough.

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.

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.

Yep, that would be cool. What would the required steps to make it happen be?

[JGR]

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.

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.
In my own networks, I never have multiple sloped track tiles in a row, and try to avoid a train being on more than one sloped tile at once.
A more reasonable slope would give a higher descent speed. In general sending trains up or down excessive slopes isn't something that I want to encourage.
Also this is affected by what value you've set the slope steepness to.

For non-maglev vehicles, the overall assumption is that power is the limiting factor (this is in line with the existing realistic acceleration model).
Under normal (i.e. flat) conditions, the driving model uses a constant deceleration, so you get simple quadratic behaviour.
This deceleration is calculated as one can be achieved over the train's entire speed range given the traction and drag forces which are approximately inverse and quadratic with speed respectively, this is then limited to the vehicle class maximum value (this is the what the table on the wiki shows).

For descents, this doesn't work for heavy vehicles and/or severe descents.
To calculate the driving speed at a given distance from a fixed target speed with a given elevation change you end with:
* Distance (fixed)
* Start KE (goes as v^2)
* End KE (fixed)
* Potential energy change (fixed) (this is just an approximation which doesn't handle non-uniform train density/variable slope, the physics model does handle this)
* Braking force (goes as fixed + v^-1) (the v and v^2 bits can be neglected here)
You can then solve for v. This is then reduced a bit to account for the elevation approximations, and clamped to a minimum of 5km/h.

Yep, that would be cool. What would the required steps to make it happen be?

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.
It is not a quick process.
At the moment there are still bugs to deal with, and then a number of things to merge/resolve with upstream, which need to be addressed first, but I would like to look into this in due course.

[fridaemon]

In settings I changed something and many of my vehicles need reduced speed and need to be repaired. Where can I turn it off? Can't find it ... Thanks

[dol422]

In settings I changed something and many of my vehicles need reduced speed and need to be repaired. Where can I turn it off? Can't find it ... Thanks

There is a setting in advanced settings called Enable improved breakdowns. Turning this off will resolve this.

[fridaemon]

it works, thank you so much

[fridaemon]

I was wrong. Two vehicles after this was ok, but problem continues ... What's wrong here?

[dol422]

If servicing was still required when the setting was disabled then the vehicles will stay that way forever until it goes to the depot. This happened to me anyway.

[Valdez]

I've encountered this several times already in the past years, but only got to documenting it now..



Something's wrong with some programmed signals, like the one in the example above. Ideally, they should function like 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

Here is one train that stops at Okayama, yet the signal shows green/clear. I've had this signal program fail in similar way in other places and work okay elsewhere (via program copying and just swapping the stations, so no chance of having different structure).

While there's a possibility it's a PEBKAC issue, I consider that fairly improbable - had that been the case, none of the signals with this programming would work properly.

What could be the problem? Something broken in the If.. Else If.. structure, or sometimes the game just doesn't evaluate current order condition properly?


Also a possible feature suggestion - could a "release any/all slots" option be added to both signals and vehicle orders? Having to pick the exact slot can be a bit troublesome sometimes..

EDIT: Just a clarification: I'm using current patchpack (0.40.5), with original braking behavior, but the issues existed even in older versions, before realistic braking was a thing.

EDIT 2: It's probably "current order" evaluation. Even with explicit "If front.. If back.." or reshuffling of the nested conditions the same behavior persists.