JGR's Patch Pack

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

MLG
Engineer
Engineer
Posts: 50
Joined: 07 Sep 2020 15:12

Re: JGR's Patch Pack

Post by MLG »

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... :shock:

Sorry, JGR.
Leaving original post for context.
You can write to me in English, or Czech.
Můžete mi psát česky, nebo anglicky.
User avatar
Gadg8eer
Traffic Manager
Traffic Manager
Posts: 190
Joined: 14 Dec 2019 14:22

Re: JGR's Patch Pack

Post by 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.
I have Asperger's, please be easy on me about stuff. My apologies if I've been a problem for you in the past.
User avatar
JGR
Tycoon
Tycoon
Posts: 2261
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Gadg8eer wrote: 28 Mar 2021 21:33 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.
Ex TTDPatch Coder
Patch Pack, Github
Dad-Coder since April 2018

Avatar by MoonsongWolf
User avatar
jfs
Tycoon
Tycoon
Posts: 1316
Joined: 08 Jan 2003 23:09
Location: Denmark

Re: JGR's Patch Pack

Post by jfs »

Gadg8eer wrote: 28 Mar 2021 21:33 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
Tycoon
Tycoon
Posts: 7629
Joined: 17 Jan 2007 00:14

Re: JGR's Patch Pack

Post by 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.
You might not exactly be interested in Ferion, but if you are, have fun :)
User avatar
Emperor Jake
Tycoon
Tycoon
Posts: 3224
Joined: 24 Apr 2007 09:37
Location: NSW Australia

Re: JGR's Patch Pack

Post by 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 :P

Anyway, while I'm enjoying messing with the new town zone customisation I came to complain about a discrepancy:
discrepancy.PNG
discrepancy.PNG (37.82 KiB) Viewed 901 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.
User avatar
wallyweb
Tycoon
Tycoon
Posts: 5855
Joined: 27 Nov 2004 15:05
Location: Canada

Re: JGR's Patch Pack

Post by wallyweb »

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.
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.
Attachments
TownZoneTool.grf
(2.76 KiB) Downloaded 15 times
User avatar
Aegir
Tycoon
Tycoon
Posts: 2799
Joined: 09 Feb 2004 10:02
Contact:

Re: JGR's Patch Pack

Post by 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 :D .
Former NewGRF Coder and Sprite Artist.

Currently working under the name 'reldred' on Github, IRC and Discord.

14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
User avatar
Snail
Tycoon
Tycoon
Posts: 1272
Joined: 28 Apr 2003 18:52
Contact:

Re: JGR's Patch Pack

Post by 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?
The French Narrow Gauge Train Set is now released! Get it here
User avatar
JGR
Tycoon
Tycoon
Posts: 2261
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

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?
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.
Ex TTDPatch Coder
Patch Pack, Github
Dad-Coder since April 2018

Avatar by MoonsongWolf
User avatar
andythenorth
Tycoon
Tycoon
Posts: 5390
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: JGR's Patch Pack

Post by andythenorth »

JGR wrote: 02 Apr 2021 18:23 A single light engine on its own like this will probably not need to reduce speed at all when descending.
Is brake force modelled? :twisted:

[Light engines are speed restricted in the UK as they often don't have enough brake force to meet stopping distances]
User avatar
JGR
Tycoon
Tycoon
Posts: 2261
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

andythenorth wrote: 02 Apr 2021 19:46
JGR wrote: 02 Apr 2021 18:23 A single light engine on its own like this will probably not need to reduce speed at all when descending.
Is brake force modelled? :twisted:

[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.
Ex TTDPatch Coder
Patch Pack, Github
Dad-Coder since April 2018

Avatar by MoonsongWolf
User avatar
Snail
Tycoon
Tycoon
Posts: 1272
Joined: 28 Apr 2003 18:52
Contact:

Re: JGR's Patch Pack

Post by Snail »

JGR wrote: 02 Apr 2021 18:23 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! :)
JGR wrote: 02 Apr 2021 18:23 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.
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.
Yep, that would be cool. What would the required steps to make it happen be?
The French Narrow Gauge Train Set is now released! Get it here
User avatar
JGR
Tycoon
Tycoon
Posts: 2261
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

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.
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.
Snail wrote: 02 Apr 2021 20:41 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.
Ex TTDPatch Coder
Patch Pack, Github
Dad-Coder since April 2018

Avatar by MoonsongWolf
User avatar
fridaemon
Transport Coordinator
Transport Coordinator
Posts: 286
Joined: 27 Oct 2019 21:06
Contact:

Re: JGR's Patch Pack

Post by 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 ... :lol: Thanks ;)

Image
------------------------------------------------------------------------
Image
Fridaemon's Objects: VERSION 1.2.1 OUT NOW
AN UPDATE COMES SOON!
Beach Objects * Shopping Centres * Skyscrapers * Garage Entrances
Modular Warehouses * Trucks 'n' Buses Parking Lots

Winner of the Screenshot of September 2020,
November 2020 and February 2021 :twisted:
dol422
Traffic Manager
Traffic Manager
Posts: 161
Joined: 29 Dec 2015 20:06

Re: JGR's Patch Pack

Post by dol422 »

fridaemon wrote: 03 Apr 2021 13:19 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 ... :lol: Thanks ;)

Image
There is a setting in advanced settings called Enable improved breakdowns. Turning this off will resolve this.
User avatar
fridaemon
Transport Coordinator
Transport Coordinator
Posts: 286
Joined: 27 Oct 2019 21:06
Contact:

Re: JGR's Patch Pack

Post by fridaemon »

dol422 wrote: 03 Apr 2021 13:42
it works, thank you so much :bow:
------------------------------------------------------------------------
Image
Fridaemon's Objects: VERSION 1.2.1 OUT NOW
AN UPDATE COMES SOON!
Beach Objects * Shopping Centres * Skyscrapers * Garage Entrances
Modular Warehouses * Trucks 'n' Buses Parking Lots

Winner of the Screenshot of September 2020,
November 2020 and February 2021 :twisted:
User avatar
fridaemon
Transport Coordinator
Transport Coordinator
Posts: 286
Joined: 27 Oct 2019 21:06
Contact:

Re: JGR's Patch Pack

Post by fridaemon »

I was wrong. Two vehicles after this was ok, but problem continues ... What's wrong here?
Image
------------------------------------------------------------------------
Image
Fridaemon's Objects: VERSION 1.2.1 OUT NOW
AN UPDATE COMES SOON!
Beach Objects * Shopping Centres * Skyscrapers * Garage Entrances
Modular Warehouses * Trucks 'n' Buses Parking Lots

Winner of the Screenshot of September 2020,
November 2020 and February 2021 :twisted:
dol422
Traffic Manager
Traffic Manager
Posts: 161
Joined: 29 Dec 2015 20:06

Re: JGR's Patch Pack

Post by 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.
User avatar
Valdez
Traffic Manager
Traffic Manager
Posts: 193
Joined: 23 Mar 2011 21:33
Location: Czech Republic

Re: JGR's Patch Pack

Post by Valdez »

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

Image

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.
Attachments
JR, 1949-05-22#1.png
(207.29 KiB) Not downloaded yet
My visits on the forums are sporadic only, so PMs may go unanswered for a long time. If you wish to report a bug etc., the best option is via DM or ping on r/Openttd Discord
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 8 guests