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

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

Re: JGR's Patch Pack

Post by JGR »

michael blunck wrote: 21 Apr 2021 15:31 When trying to save an older game (started in trunk 1.8.) in 0.41.0, I'm getting the error message:
Game save failed (undefined string)
This file may be from a different game.
Has anything been changed in this respect since
JGR wrote: Savegames from trunk up to the last savegame version which has been merged should be loadable in this patchpack.
?

regards
Michael
If you can send a savegame which shows the problem I'll take a look at it. I'm not aware of any such issues at the moment.
McZapkie wrote: 21 Apr 2021 16:17 Not sure how deceleration in advanced braking model works, but maybe it would be interesting to take tractive effort of all vehicles into account?
So newgrf maker can easily simulate all these brake-less wagons just by putting TE 0 (usually it is default 0.3 and not used).
There are still some changes that I have in mind to how braking forces are calculated.
Once all that is done I'll see about adding NewGRF engine properties to override the default values.
Ex TTDPatch Coder
Patch Pack, Github
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: JGR's Patch Pack

Post by Wahazar »

JGR wrote: 21 Apr 2021 20:37
...Once all that is done I'll see about adding NewGRF engine properties to override the default values.
[/quote]
But there is no need to overriding all default TE values, IMO. All modern locomotives and wagons are now equipped with
centralized pneumatic brakes and this default 0.3 value is exactly steel wheel friction coefficient.
But.
If someone want to make newgrf which depict lack of brakes in vintage carriages, he should be able to do it just by nullify TE.
But it is newgrf maker decision, while braking patch should just take all these tractive_effort_coefficient into consideration.
So if there is long train where only locomotive is equipped with brakes, deceleration should be much worse (or in case of slope, even no deceleration, as it is now in case of slippery acceleration).
It is an elegant way to introduce very substantial (now) caboose, or mixing wagons with and without handbrake (more or less expensive).
mrjack2
Engineer
Engineer
Posts: 74
Joined: 21 Jan 2016 23:04

Re: JGR's Patch Pack

Post by mrjack2 »

Hi JGR, could my town growth issues here be something to do with JGRPP, or otherwise something fixable?

viewtopic.php?f=31&t=88779
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: JGR's Patch Pack

Post by Hafting »

Roll-through train depots have a small problem: Every time a train is about to roll into one, I get a "lost train" notification. The train get through to the station - no problem with routing. But I get spammed with these messages. I can only guess the pathfinder consider the train "lost" because it doesn't always consider the new roll-through option?

I have two depots back to back, in front of a station. And another double depot next to this, for higher throughput. The trains have no depot order, only an order to get to the station on the other side. This so it may use either the left or the right double-depot, depending on availability. I use realistic braking, if that makes a difference.

An idea for further enhancement: Merge adjacent depots into a single larger depot. One may then give a train a depot order, and it will use whatever entrance it finds unobstructed. Just like stations with multiple platforms.
User avatar
Snail
Tycoon
Tycoon
Posts: 1283
Joined: 28 Apr 2003 18:52
Contact:

Re: JGR's Patch Pack

Post by Snail »

McZapkie wrote: 21 Apr 2021 21:44
JGR wrote: 21 Apr 2021 20:37 ...Once all that is done I'll see about adding NewGRF engine properties to override the default values.
But there is no need to overriding all default TE values, IMO. All modern locomotives and wagons are now equipped with
centralized pneumatic brakes and this default 0.3 value is exactly steel wheel friction coefficient.
But.
If someone want to make newgrf which depict lack of brakes in vintage carriages, he should be able to do it just by nullify TE.
But it is newgrf maker decision, while braking patch should just take all these tractive_effort_coefficient into consideration.
So if there is long train where only locomotive is equipped with brakes, deceleration should be much worse (or in case of slope, even no deceleration, as it is now in case of slippery acceleration).
It is an elegant way to introduce very substantial (now) caboose, or mixing wagons with and without handbrake (more or less expensive).
This is exactly my case. I think it would be useful to have a discussion about how to handle such a feature.

I'm not sure if the braking patch should tie braking force to tractive effort. Tractive effort represents the "strength" and the "potential" of an engine as a whole, to pull a consist; braking force has more to do with the weight applied to those axles that are equipped with brakes. The two quantities are definitely related, but not always the same.

More than that, I was looking forward to a new "property" of vehicles that would allow a newGRF author to lengthen or shorten a consist's standard distance to stop. Right now, any consist in my set requires a minimum amount of wagons with brakes, otherwise it won't be allowed to leave a depot. With the property I mentioned, a consist with very few braking wagons would still be allowed to leave its depot, but would require a longer distance to stop.
A train with few braking wagons would also require to considerably slow down before approaching any downhill track, and keep a very low speed as it descends those tracks.
The French Narrow Gauge Train Set is now released! Get it here
gebik
Traffic Manager
Traffic Manager
Posts: 174
Joined: 07 Sep 2020 15:12
Location: Usually near some interesting rail systems. :P

Re: JGR's Patch Pack

Post by gebik »

Hi JGR,
I got something on my mind some time ago and I think, it would be possible: Change the number of required cargoes in company table (I hope this is correct translate) from 8 to number of cargoes possible to transport in game. This would increase difficulty to have this section completed for 100 %, if there is some industry set with more than default cargoes, for example FIRS, XIS, etc. However it would keep compatibility with default industries and with some hypothetical PAX-only industry set or other sets based on default industry chains. I find absolutely nonsense to need to transport 8 cargoes, if there are 64 of them in that game.
Maybe this could be connected also to some adjustment of other company success factors there. We all know, that this is really old thing, so it might need some work elsewhere.
I am writing this here and not to OTTD suggestions, since here is more probable, that something will be done with it. :) Plus, it can be later suggested to be pushed upstream, if not buggy.

Thanks, MLG
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.
Argus
Tycoon
Tycoon
Posts: 1204
Joined: 16 Oct 2018 08:31
Location: Heart of the Highlands. Not Scottish. Czech.

Re: JGR's Patch Pack

Post by Argus »

Bad colors in reports
Attachments
McIntosh & Co., 9. úno 1751.png
(1.43 MiB) Not downloaded yet
User avatar
JGR
Tycoon
Tycoon
Posts: 2559
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

McZapkie wrote: 21 Apr 2021 21:44
JGR wrote: 21 Apr 2021 20:37
...Once all that is done I'll see about adding NewGRF engine properties to override the default values.
But there is no need to overriding all default TE values, IMO. All modern locomotives and wagons are now equipped with
centralized pneumatic brakes and this default 0.3 value is exactly steel wheel friction coefficient.
But.
If someone want to make newgrf which depict lack of brakes in vintage carriages, he should be able to do it just by nullify TE.
But it is newgrf maker decision, while braking patch should just take all these tractive_effort_coefficient into consideration.
So if there is long train where only locomotive is equipped with brakes, deceleration should be much worse (or in case of slope, even no deceleration, as it is now in case of slippery acceleration).
It is an elegant way to introduce very substantial (now) caboose, or mixing wagons with and without handbrake (more or less expensive).
I did a bit of looking into this and the default is not actually 0.3.
0.3 is what all the default rail vehicles are set to, and is the default for road vehicles.
The NewGRF documentation is incorrect. For new rail vehicles the default is 0.

Most of the NewGRF wagons that I've tested so far leave wagon TE at 0. I did find one that set it to a value near the default.
Also, because the TE value for 0 power vehicles is not used, there is no guarantee that existing NewGRFs don't unintentionally set it to silly values because it doesn't matter.
Snail wrote: 23 Apr 2021 16:41
McZapkie wrote: 21 Apr 2021 21:44
JGR wrote: 21 Apr 2021 20:37 ...Once all that is done I'll see about adding NewGRF engine properties to override the default values.
But there is no need to overriding all default TE values, IMO. All modern locomotives and wagons are now equipped with
centralized pneumatic brakes and this default 0.3 value is exactly steel wheel friction coefficient.
But.
If someone want to make newgrf which depict lack of brakes in vintage carriages, he should be able to do it just by nullify TE.
But it is newgrf maker decision, while braking patch should just take all these tractive_effort_coefficient into consideration.
So if there is long train where only locomotive is equipped with brakes, deceleration should be much worse (or in case of slope, even no deceleration, as it is now in case of slippery acceleration).
It is an elegant way to introduce very substantial (now) caboose, or mixing wagons with and without handbrake (more or less expensive).
This is exactly my case. I think it would be useful to have a discussion about how to handle such a feature.

I'm not sure if the braking patch should tie braking force to tractive effort. Tractive effort represents the "strength" and the "potential" of an engine as a whole, to pull a consist; braking force has more to do with the weight applied to those axles that are equipped with brakes. The two quantities are definitely related, but not always the same.

More than that, I was looking forward to a new "property" of vehicles that would allow a newGRF author to lengthen or shorten a consist's standard distance to stop. Right now, any consist in my set requires a minimum amount of wagons with brakes, otherwise it won't be allowed to leave a depot. With the property I mentioned, a consist with very few braking wagons would still be allowed to leave its depot, but would require a longer distance to stop.
A train with few braking wagons would also require to considerably slow down before approaching any downhill track, and keep a very low speed as it descends those tracks.
I still do intend to add such properties, but I don't want to do that until various issues in the physics and default values have been addressed.
Various changes need to be made to both the braking model and the corresponding driving model.
MLG wrote: 23 Apr 2021 18:06 Hi JGR,
I got something on my mind some time ago and I think, it would be possible: Change the number of required cargoes in company table (I hope this is correct translate) from 8 to number of cargoes possible to transport in game. This would increase difficulty to have this section completed for 100 %, if there is some industry set with more than default cargoes, for example FIRS, XIS, etc. However it would keep compatibility with default industries and with some hypothetical PAX-only industry set or other sets based on default industry chains. I find absolutely nonsense to need to transport 8 cargoes, if there are 64 of them in that game.
Maybe this could be connected also to some adjustment of other company success factors there. We all know, that this is really old thing, so it might need some work elsewhere.
I am writing this here and not to OTTD suggestions, since here is more probable, that something will be done with it. :) Plus, it can be later suggested to be pushed upstream, if not buggy.

Thanks, MLG
The default scoring system makes no sense at all and is mainly preserved for backwards compatibility. I don't think that it will see any changes here or upstream.
There are various goal and scoring scripts which do a better job here.
Argus wrote: 23 Apr 2021 19:06 Bad colors in reports
I will look into this, thanks for the report.
mrjack2 wrote: 22 Apr 2021 01:55 Hi JGR, could my town growth issues here be something to do with JGRPP, or otherwise something fixable?

viewtopic.php?f=31&t=88779
I'll take a look at this in a bit.
Edit: The script is broken, please see the other thread.
Hafting wrote: 23 Apr 2021 15:36 Roll-through train depots have a small problem: Every time a train is about to roll into one, I get a "lost train" notification. The train get through to the station - no problem with routing. But I get spammed with these messages. I can only guess the pathfinder consider the train "lost" because it doesn't always consider the new roll-through option?

I have two depots back to back, in front of a station. And another double depot next to this, for higher throughput. The trains have no depot order, only an order to get to the station on the other side. This so it may use either the left or the right double-depot, depending on availability. I use realistic braking, if that makes a difference.

An idea for further enhancement: Merge adjacent depots into a single larger depot. One may then give a train a depot order, and it will use whatever entrance it finds unobstructed. Just like stations with multiple platforms.
In general, it's best to always have at least one service at depot order in the order list for trains, road vehicles and ships.
At the moment the pathfinder does not look through drive-through depots for so that trains don't use them as a shortcut (and for implementation simplicity).
There is an upstream PR for combined depots here: https://github.com/OpenTTD/OpenTTD/pull/8480
Ex TTDPatch Coder
Patch Pack, Github
User avatar
JGR
Tycoon
Tycoon
Posts: 2559
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Argus wrote: 23 Apr 2021 19:06 Bad colors in reports
I'd suggest disabling the "Hardware acceleration" checkbox in the Game Options window.
Ex TTDPatch Coder
Patch Pack, Github
Argus
Tycoon
Tycoon
Posts: 1204
Joined: 16 Oct 2018 08:31
Location: Heart of the Highlands. Not Scottish. Czech.

Re: JGR's Patch Pack

Post by Argus »

Thanks, problem solved :)
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: JGR's Patch Pack

Post by Wahazar »

Snail wrote: 23 Apr 2021 16:41 I'm not sure if the braking patch should tie braking force to tractive effort. Tractive effort represents the "strength" and the "potential" of an engine as a whole, to pull a consist; braking force has more to do with the weight applied to those axles that are equipped with brakes. The two quantities are definitely related, but not always the same.
...
Tractive effort doesn't represent some magic strength, it is just effective static friction coefficient, which give a force
depending on axle weight.
For train with single loco, accelerating force Fa = min(TE*Mloco*g, P/V), decelrating force Fd = TE*Mloco*g+sum(TE*Mcar*g).
Usually same calculations can be used for starting force or brake force, maybe except of with some edge cases such as locomotive equipped with auxiliary wheels with brake but not powered.
While tractive_effort_coefficient is used to calculate maximal static friction force, which is used both for accelerating and decelerating, the only difference is that only powered vehicles are used for calculating acceleration (it is already implemented), while all vehicles for deceleration (thus there is need to exclude some brakeless vans by putting TE 0).

EDIT: I checked newgrf sources as JGR suggested and indeed, many authors put TE 0 for wagons. It spoils all above idea :(
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
User avatar
Snail
Tycoon
Tycoon
Posts: 1283
Joined: 28 Apr 2003 18:52
Contact:

Re: JGR's Patch Pack

Post by Snail »

McZapkie wrote: 24 Apr 2021 12:00
Snail wrote: 23 Apr 2021 16:41 I'm not sure if the braking patch should tie braking force to tractive effort. Tractive effort represents the "strength" and the "potential" of an engine as a whole, to pull a consist; braking force has more to do with the weight applied to those axles that are equipped with brakes. The two quantities are definitely related, but not always the same.
...
Tractive effort doesn't represent some magic strength, it is just effective static friction coefficient, which give a force
depending on axle weight.
Well, quite obviously it's not a random number. For my steamers, I compute it using a formula, which takes into account boiler pressure, cylinder size and number, expansion type (compound or simple expansion), diameter of driving wheels, and adhesive weight.
More specifically, the friction coefficient depending on the axle weight you described, is the maximum theoretical tractive effort a locomotive can reach, given its weight and the laws of physics.
However, if the engine of the locomotive isn't "strong" enough, that value can't be reached, so the final tractive effort will be lower than braking force. In case of a steamer, this might happen because of low boiler pressure, small cylinders, huge driving wheels, Italian style compounding (i.e. one high pressure cylinder on the right, one low pressure on the left)...

This is why I say that braking force and tractive effort are sometimes disconnected concepts. In addition, as you mentioned, there are many cases when the braking axles don't coincide with the driving axles, not to mention some steamers can effectively brake using the engine in reverse (contre-vapeur in French) while others can't.

As a result, it easily gets quite complicated.

-- EDIT --
Thinking again about this made me realize we might want to add a new property for vehicles, such as "braking force" (or "braking effort"), which would be equal to TE by default if not otherwise specified. But then again, this wouldn't be backward-compatible, if most existing sets have a TE of 0 for all wagons...
The French Narrow Gauge Train Set is now released! Get it here
michael blunck
Tycoon
Tycoon
Posts: 5948
Joined: 27 Apr 2005 07:09
Contact:

Re: JGR's Patch Pack

Post by michael blunck »

many authors put TE 0 for wagons
most existing sets have a TE of 0 for all wagons...
Well, this behaviour developed from a time when we only had original vehicle IDs available for our own vehicles.

Although original vehicles hadn't a property for tractive effort ... just to be safe.

regards
Michael
Image
User avatar
Andrew350
Chairman
Chairman
Posts: 768
Joined: 19 Dec 2011 07:54
Location: Washington State, USA
Contact:

Re: JGR's Patch Pack

Post by Andrew350 »

Hi JGR

Very minor issue I encountered with the NewGRF debug window. It seems that if the first permanent register which gets initialized starts on a new line (i.e. 4, 8, 12, etc.), it is always reported as being value 0, even if not. For example, in this screenshot register 8 actually has a value of 1:

Murphy & Co., 2077-03-11.png
Murphy & Co., 2077-03-11.png (3.05 KiB) Viewed 1888 times
This doesn't seem to occur if one of the other registers are initialized first. Not a big deal, it just lead me to a brief moment of confusion why the storage was initialized but still seemingly showed the wrong value :)
User avatar
JGR
Tycoon
Tycoon
Posts: 2559
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Andrew350 wrote: 25 Apr 2021 07:28 Hi JGR

Very minor issue I encountered with the NewGRF debug window. It seems that if the first permanent register which gets initialized starts on a new line (i.e. 4, 8, 12, etc.), it is always reported as being value 0, even if not. For example, in this screenshot register 8 actually has a value of 1:

Murphy & Co., 2077-03-11.png
This doesn't seem to occur if one of the other registers are initialized first. Not a big deal, it just lead me to a brief moment of confusion why the storage was initialized but still seemingly showed the wrong value :)
Thanks, this should be fixed now.
McZapkie wrote: 24 Apr 2021 12:00
Snail wrote: 23 Apr 2021 16:41 I'm not sure if the braking patch should tie braking force to tractive effort. Tractive effort represents the "strength" and the "potential" of an engine as a whole, to pull a consist; braking force has more to do with the weight applied to those axles that are equipped with brakes. The two quantities are definitely related, but not always the same.
...
Tractive effort doesn't represent some magic strength, it is just effective static friction coefficient, which give a force
depending on axle weight.
For train with single loco, accelerating force Fa = min(TE*Mloco*g, P/V), decelrating force Fd = TE*Mloco*g+sum(TE*Mcar*g).
Usually same calculations can be used for starting force or brake force, maybe except of with some edge cases such as locomotive equipped with auxiliary wheels with brake but not powered.
While tractive_effort_coefficient is used to calculate maximal static friction force, which is used both for accelerating and decelerating, the only difference is that only powered vehicles are used for calculating acceleration (it is already implemented), while all vehicles for deceleration (thus there is need to exclude some brakeless vans by putting TE 0).

EDIT: I checked newgrf sources as JGR suggested and indeed, many authors put TE 0 for wagons. It spoils all above idea :(
At the moment braking force is also variable with current speed, though this only really matters on slopes with the current driving model.

I'm not really keen for braking force to simply be M * TE * g, because what that actually means is that M doesn't matter at all, because it's immediately cancelled out when calculating the acceleration.
Using the tractive TE as the braking TE is not really workable as discussed above, so it would have to be a new property with a reasonable default value. This would effectively mean that all trains have pretty much identical braking curves by default, which is not really what I'm looking to achieve.
Using M * TE * g implies unbounded braking power dissipation. If it is made bounded in some way you get some more interesting dynamics. The downside is that acceleration varies over the braking distance which makes the braking distance/speed projections less straightforward. The current approach to this is to calculate a braking force which can be achieved over the entire speed range (which some special casing of what speed range means for slope descents), but this is overly punitive for faster/heavier vehicles and so needs to be replaced anyway.
Ex TTDPatch Coder
Patch Pack, Github
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: JGR's Patch Pack

Post by Wahazar »

JGR wrote: 25 Apr 2021 14:25 ...
I'm not really keen for braking force to simply be M * TE * g, because what that actually means is that M doesn't matter at all, because it's immediately cancelled out when calculating the acceleration.
Well, theoretically indeed, braking deceleration (at level track) doesn't depend on mass (if all wheels are equipped with brakes).
a = F/M, where F = -M*TE*g -M*g*sin(slope), for slope=0 you get a = TE*g
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Hafting
Engineer
Engineer
Posts: 106
Joined: 13 Feb 2014 11:22

Re: JGR's Patch Pack

Post by Hafting »

JGR wrote: 23 Apr 2021 19:54 [
Hafting wrote: 23 Apr 2021 15:36 Roll-through train depots have a small problem: Every time a train is about to roll into one, I get a "lost train" notification. The train get through to the station - no problem with routing. But I get spammed with these messages. I can only guess the pathfinder consider the train "lost" because it doesn't always consider the new roll-through option?

I have two depots back to back, in front of a station. And another double depot next to this, for higher throughput. The trains have no depot order, only an order to get to the station on the other side. This so it may use either the left or the right double-depot, depending on availability. I use realistic braking, if that makes a difference.

An idea for further enhancement: Merge adjacent depots into a single larger depot. One may then give a train a depot order, and it will use whatever entrance it finds unobstructed. Just like stations with multiple platforms.
In general, it's best to always have at least one service at depot order in the order list for trains, road vehicles and ships.
Unfortunately, trains sometimes need to not have a depot order: The amount of cargo moved, may need a higher frequency of trains than a single depot can handle. (FIRS, when you boost an already good mine with engineering supplies.) A depot order will have all trains queue up for that depot, limiting freight capacity to how many trains a single depot can handle.

One alternative then, is to have two depots, placed so the train must go through one or the other in order to reach the next station. No depot order, but the train will be serviced on every roundtrip. (There being no direct route to that station, so the train goes through the first uncongested depot and gets serviced) If the roundtrip is very long, have several such double depots spread out to prevent trains from seeking out a random depot for emergency service.

A much more cumbersome alternative is to have two sets of trains (A and B), which are serviced in different depots, using depot orders As you get more and more goods, you have to be careful to buy more trains in pairs - this is the cumbersome part. If trains from set A and B don't alternate perfectly along the line, then depot queues and delays still happens. No such problems with double depots and no depot order.

At the moment the pathfinder does not look through drive-through depots for so that trains don't use them as a shortcut (and for implementation simplicity).
Simplicity, I understand. You surely have more pressing issues than my wishes.

But the pathfinder would not use the double depot as a shortcut unnecessarily. It already avoids unnecessary trips through single depots, preferring direct railway. Surely, the pathfinder knows the depot represent a delay. The only case I see trains going unnecessarily through depots, is when the direct route is blocked by other trains. That is acceptable and wanted behavior.

Getting the "lost train" message for every train, means drive-through depots aren't useful unless there is a depot order. With a depot order, no erroneous lost train message.

The drive-through depot theoretically allows more throughput than the ordinary depot - as incoming trains don't need to wait for leaving trains. They only need to wait for the previous incoming train, which goes at a "depot speed" slower than "normal speed". For that reason, having two sets of drive-through depots may still be necessary for high throughput.

In practice, a single drive-through depot does not work well, at least not with realistic braking: One train rolls into the depot. As soon as it is in, the next train reserves a way into the depot and start rolling. This is as it should be - but unfortunately, the first train is prevented from transferring to the 'leaving depot' when the second train has reserved a way into the 'entering depot'. The result is that all trains on this congested line gather in 'entering depot'. Eventually, no train is trying to get in. Only then are trains transferred to the 'leaving depot' and is able to go to the next station.

This problem does not happen when I have two sets of drive-through depots. A train will roll into the left drive-through. Before all of it is inside, the next train arrives at the split, and finds an unobstructed way into the right drive-through. When the first train is fully inside the left drive-through, the second train is still blocking the split, so the third train cannot immediately reserve a path into the left drive-through. So train1 gets the time it needs to transfer to the 'leaving depot'. This works very well, except for the continuous messages about 'lost trains'.
There is an upstream PR for combined depots here: https://github.com/OpenTTD/OpenTTD/pull/8480
Interesting, and good to know.
User avatar
JGR
Tycoon
Tycoon
Posts: 2559
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Hafting wrote: 25 Apr 2021 15:34 Getting the "lost train" message for every train, means drive-through depots aren't useful unless there is a depot order. With a depot order, no erroneous lost train message.
Could you post the savegame for this? It'd be helpful to take a look at the setup and do some testing on.
Hafting wrote: 25 Apr 2021 15:34 The drive-through depot theoretically allows more throughput than the ordinary depot - as incoming trains don't need to wait for leaving trains. They only need to wait for the previous incoming train, which goes at a "depot speed" slower than "normal speed". For that reason, having two sets of drive-through depots may still be necessary for high throughput.

In practice, a single drive-through depot does not work well, at least not with realistic braking: One train rolls into the depot. As soon as it is in, the next train reserves a way into the depot and start rolling. This is as it should be - but unfortunately, the first train is prevented from transferring to the 'leaving depot' when the second train has reserved a way into the 'entering depot'. The result is that all trains on this congested line gather in 'entering depot'. Eventually, no train is trying to get in. Only then are trains transferred to the 'leaving depot' and is able to go to the next station.
This should be fixable.
In the long run, depots should have a finite capacity and/or have better coordination between the two ends, but for now removing the restriction on moving between the two ends when the current side is reserved/blocked seems reasonable.
Hafting wrote: 25 Apr 2021 15:34 Unfortunately, trains sometimes need to not have a depot order: The amount of cargo moved, may need a higher frequency of trains than a single depot can handle. (FIRS, when you boost an already good mine with engineering supplies.) A depot order will have all trains queue up for that depot, limiting freight capacity to how many trains a single depot can handle.

One alternative then, is to have two depots, placed so the train must go through one or the other in order to reach the next station. No depot order, but the train will be serviced on every roundtrip. (There being no direct route to that station, so the train goes through the first uncongested depot and gets serviced) If the roundtrip is very long, have several such double depots spread out to prevent trains from seeking out a random depot for emergency service.

A much more cumbersome alternative is to have two sets of trains (A and B), which are serviced in different depots, using depot orders As you get more and more goods, you have to be careful to buy more trains in pairs - this is the cumbersome part. If trains from set A and B don't alternate perfectly along the line, then depot queues and delays still happens. No such problems with double depots and no depot order.
You could also try a service at nearest depot order, with a suitable waypoint in advance of the depots this should work.
Ex TTDPatch Coder
Patch Pack, Github
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: JGR's Patch Pack

Post by Wahazar »

Is there any reason why inflation modifiers are in cheat menu, instead of settings?
It is nice feature to balance economy of any scenario.
User avatar
JGR
Tycoon
Tycoon
Posts: 2559
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

McZapkie wrote: 25 Apr 2021 17:51 Is there any reason why inflation modifiers are in cheat menu, instead of settings?
It is nice feature to balance economy of any scenario.
It's not a setting in the usual sense as the inflation values change as the game progresses according to the actual inflation settings.
Ex TTDPatch Coder
Patch Pack, Github
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 17 guests