JGR's Patch Pack
Moderator: OpenTTD Developers
-
- Traffic Manager
- Posts: 174
- Joined: 07 Sep 2020 15:12
- Location: Usually near some interesting rail systems. :P
Re: JGR's Patch Pack
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.
Sorry, JGR.
Leaving original post for context.
Are you an eye candy player? Check out Invisible engine set! viewtopic.php?f=67&t=88934
You can write to me in English, or Czech. Můžete mi psát česky nebo anglicky.
Formerly known as MLG.
You can write to me in English, or Czech. Můžete mi psát česky nebo anglicky.
Formerly known as MLG.
Re: JGR's Patch Pack
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.
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.
Re: JGR's Patch Pack
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
Patch Pack, Github
Re: JGR's Patch Pack
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
Re: JGR's Patch Pack
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
- Tycoon
- Posts: 3427
- Joined: 24 Apr 2007 09:37
- Skype: Discord: Emperor Jake #4106
- Location: Not Actually Japan
- Contact:
Re: JGR's Patch Pack
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: 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.
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.
Re: JGR's Patch Pack
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.
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 64 times
wallyweb on tt-forums: Screenshots - Wallyweb World - Projects & Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018 - December 2018 - May 2019
Re: JGR's Patch Pack
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 .
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 .
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
Re: JGR's Patch Pack
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:
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?
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:
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
Re: JGR's Patch Pack
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?
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
Patch Pack, Github
- andythenorth
- Tycoon
- Posts: 5658
- Joined: 31 Mar 2007 14:23
- Location: Lost in Music
Re: JGR's Patch Pack
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]
FIRS Industry Replacement Set (released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (finished)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Re: JGR's Patch Pack
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]
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
Patch Pack, Github
Re: JGR's Patch Pack
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!
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.
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.
The French Narrow Gauge Train Set is now released! Get it here
Re: JGR's Patch Pack
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.
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.
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
Patch Pack, Github
Re: JGR's Patch Pack
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
Re: JGR's Patch Pack
There is a setting in advanced settings called Enable improved breakdowns. Turning this off will resolve this.
Take a look at: http://www.tt-forums.net/viewtopic.php?f=47&t=74993
Why do it tomorrow when you can do it today
Why do it tomorrow when you can do it today
Re: JGR's Patch Pack
I was wrong. Two vehicles after this was ok, but problem continues ... What's wrong here?
Re: JGR's Patch Pack
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.
Take a look at: http://www.tt-forums.net/viewtopic.php?f=47&t=74993
Why do it tomorrow when you can do it today
Why do it tomorrow when you can do it today
Re: JGR's Patch Pack
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:
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.
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
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) Viewed 1156 times
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
Who is online
Users browsing this forum: No registered users and 47 guests