JGR's Patch Pack

[Auge]

Hello and a happy new year,

with the latest versions of JGRPP I am experiencing a change in behaviour of the send-to-depot button (at least) in the rail vehicle window. When clicking the button, the vehicle jumps to the next order instead of going to a depot. Sending the train to a depot is only achievable with a double click. IMHO this is a clear misbehaviour of the UI and (at least for me) very annoying.

Is this a JGRPP "feature" or one of the vanilla game? I searched the changelogs of OpenTTD (13.x) and of JGRPP (0.48.x upwards) but found no matching entry (possibly I've missed something). Is there a reason to change the behaviour and a setting to restore the before default behaviour?

Tschö, Auge

[JGR]

Hello and a happy new year,

with the latest versions of JGRPP I am experiencing a change in behaviour of the send-to-depot button (at least) in the rail vehicle window. When clicking the button, the vehicle jumps to the next order instead of going to a depot. Sending the train to a depot is only achievable with a double click. IMHO this is a clear misbehaviour of the UI and (at least for me) very annoying.

Is this a JGRPP "feature" or one of the vanilla game? I searched the changelogs of OpenTTD (13.x) and of JGRPP (0.48.x upwards) but found no matching entry (possibly I've missed something). Is there a reason to change the behaviour and a setting to restore the before default behaviour?

Tschö, Auge

I'm not able to reproduce any behaviour like this.
Skipping to the next order is only performed when the current order is already a depot order.

If you have a save or configuration where the behaviour is incorrect, if you can upload it I'll take a look.

[Auge]

Hello

with the latest versions of JGRPP I am experiencing a change in behaviour of the send-to-depot button ...

Skipping to the next order is only performed when the current order is already a depot order.

And here we are. I every when and then send trains to stop in the depot when their current order already is their explicit maintenance order. I do this i.e. to add additional or newer, faster, greater carriages to a train. Is there a setting to disable the skipping-the-depot-order behaviour? I want to disable it, because IMHO it is a UI fail. When I click the send-to-depot button I expect the vehicle to be sent to a depot and nothing else.

Two last questions. Is this a JGRPP-feature and if so, in which version it was introduced?

Thank you in advance and tschö, Auge

[JGR]

Hello

with the latest versions of JGRPP I am experiencing a change in behaviour of the send-to-depot button ...

Skipping to the next order is only performed when the current order is already a depot order.

And here we are. I every when and then send trains to stop in the depot when their current order already is their explicit maintenance order. I do this i.e. to add additional or newer, faster, greater carriages to a train. Is there a setting to disable the skipping-the-depot-order behaviour? I want to disable it, because IMHO it is a UI fail. When I click the send-to-depot button I expect the vehicle to be sent to a depot and nothing else.

Two last questions. Is this a JGRPP-feature and if so, in which version it was introduced?

Thank you in advance and tschö, Auge

This behaviour has been present in OpenTTD since SVN r1, which was slightly more than 18 years ago.
I haven't bothered to check the original TTD, I leave that up to you if you are interested.

[Auge]

Hello

Two last questions. Is this a JGRPP-feature and if so, in which version it was introduced?

This behaviour has been present in OpenTTD since SVN r1, which was slightly more than 18 years ago.

This surprises me. I am sure to have never seen this behaviour before the latest one or two months.

Tschö, Auge

[Redirect Left]

I haven't bothered to check the original TTD, I leave that up to you if you are interested.

For the lols I found my original disc copy, it isn't present in the original TTD for Windows 95/98.

[LaChupacabra]

Skipping to the next order is only performed when the current order is already a depot order.

This behaviour has been present in OpenTTD since SVN r1, which was slightly more than 18 years ago.

This is not a behavior present in the regular version and never, as far as I know this game since 1.4.0, hasn't been. In your version, it's not something that has always been there either. It certainly wasn't in 0.32.4. In the later ones, probably also, but I can't say when it changed. It's very possible that adding some setting caused this change, because it seems to me that in versions 0.40.5 and 0.43.1 it wasn't there either (I'm not downloading every updates). I have the oldest one on a different computer and maybe that's why the behavior is different.

I find this unintuitive and bad behavior. If I want the vehicle to go to the depot, that means I want it to go to the depot, not bypass it. This button always works like this, just not when the vehicle is heading for service. Note that if someone is also using the regular version of the game, it will not be convenient to constantly change behavior. Moreover, canceling the order with the designated depot may cause the train to get lost.

A specific example
Train #56 has a designated depot. This structure is designed to evenly distribute supplies (there is always a train in each direction). If I manually send a train to another depot on the way back, the order will be canceled and the train will enter the platform where it not should. This will cause him to take a completely different route and get lost. In the regular version of the game, this problem doesn't occur.

JGR - depot issue.png (419.21 KiB) Viewed 3500 times

[Heresy]

Seems to be related to the functionality change of the depot order button when enabling the "Show go to depot/hangar and sell feature" in settings.

If I have the setting disabled and click the depot button on a current depot order, the vehicle heads to the depot and stops there.
If I have the setting enabled and click the depot button on a current depot order, the vehicle skips the current depot order and heads to the next destination.

[Auge]

Hello

It certainly wasn't in 0.32.4. In the later ones, probably also, but I can't say when it changed. It's very possible that adding some setting caused this change, because it seems to me that in versions 0.40.5 and 0.43.1 it wasn't there either (I'm not downloading every updates).

Also JGRPP 0.50.0 doesn't show this misbehaviour (in the configuration as it exists on the exact computer where JGRPP 0.50.0 runs). If I'm not misinterpreting the Github issue #470 and the posting of Heresy it seems to be related to a new feature in combination with a change in a setting default.

Tschö, Auge

[Heresy]

Hello

It certainly wasn't in 0.32.4. In the later ones, probably also, but I can't say when it changed. It's very possible that adding some setting caused this change, because it seems to me that in versions 0.40.5 and 0.43.1 it wasn't there either (I'm not downloading every updates).

Also JGRPP 0.50.0 doesn't show this misbehaviour (in the configuration as it exists on the exact computer where JGRPP 0.50.0 runs). If I'm not misinterpreting the Github issue #470 and the posting of Heresy it seems to be related to a new feature in combination with a change in a setting default.

Tschö, Auge

The settings for your 0.50.0 and 0.50.1 installation are the same?

I have not done any testing to see if there are any other game settings that might affect the behaviour, but as mentioned, with the "Show go to depot/hangar and sell feature" enabled in Settings (Expert setting, under Interface), the vehicle does skip the current depot order.
And if I disable that setting, the vehicle stops skipping the order and changes it from a service at depot order, to a heading to depot order and stops there.

That behaviour was identical in my tests on 0.26.0, 0.48.0, 0.48.1, 0.50.0 and 0.50.1, so it has (likely, did not test every release) been like that since the setting was introduced.

If you have the setting enabled, can you try disabling it in your game settings, and see if the vehicles then perform as you expect?

[Auge]

Hello

Also JGRPP 0.50.0 doesn't show this misbehaviour (in the configuration as it exists on the exact computer where JGRPP 0.50.0 runs).

The settings for your 0.50.0 and 0.50.1 installation are the same?

I have to correct me. On both machines runs JGRPP 0.50.0 and in one installation the button does work as I would it expect, in the other it doesn't. So it is a question of different settings. I'll change it, where necessary, and will be done.

Tschö, Auge

[Heresy]

Hello

Also JGRPP 0.50.0 doesn't show this misbehaviour (in the configuration as it exists on the exact computer where JGRPP 0.50.0 runs).

The settings for your 0.50.0 and 0.50.1 installation are the same?

I have to correct me. On both machines runs JGRPP 0.50.0 and in one installation the button does work as I would it expect, in the other it doesn't. So it is a question of different settings. I'll change it, where necessary, and will be done.

Tschö, Auge

As an update, in the next release, the behaviour when doing a normal click on the depot button will be the same independent of enabled or disabled status of the go to depot and sell feature, as it was changed in a recent commit to be consistent.

So once the new release becomes available, the vanilla behaviour (where it changes from "service at depot" to "head to depot" and stop), is what happens when you click the button with either setting state.

[Walter Novotny]

Is it possible to implement a patch that allows:
1. generation of rivers where they are supposed to be,
2. importing landmarks (cities, objects, signs, industries etc) from external txt file?

viewtopic.php?t=70846

[desiroboy]

I was wondering if perhaps the following functionality could be added to the Departure Boards feature.

The ability to filter the departure boards based on vehicle groups.

For example in my current save I am building the UK railway system. At London Euston a large terminus served by numerous London underground metro lines the departure boards are FULL of London Underground departures as they are every 2/3 minutes and therefore there isn't much visibility of the less frequent mainline services on the boards.

Would such a feature be easy to implement ?

[OzTrans]

Why does it take up to 4 game days for a road depot built on snowy ground to show up as snowy variant ? [JGR-PP 49.2]

Sample here took 3 days ... for variable 0x40 to change from 0x00 to 0x04 ...

Jusr built ...

Road Depot Construction A.png (11.17 KiB) Viewed 2653 times

Turned snowy ...

Road Depot Construction B.png (11.56 KiB) Viewed 2653 times

[ino]

Because it takes a while for snow to fall and build-up on the depot?

(Sorry couldn't help)

[Argus]

In addition, for example, steam locomotives drove into the depot, steam is hot, isn't it.

[Auge]

Hello

Why does it take up to 4 game days for a road depot built on snowy ground to show up as snowy variant ? [JGR-PP 49.2]

Sample here took 3 days ... for variable 0x40 to change from 0x00 to 0x04 ...

A question is, how it is handled in the vanilla game. If there's no difference, we can (more or less) assume that it worked that way since the beginning. Even on new built streets or rail tracks it takes a bit before the the tiles get snowy.

Tschö, Auge

[BeSt-Com]

Hello

Why does it take up to 4 game days for a road depot built on snowy ground to show up as snowy variant ? [JGR-PP 49.2]

Sample here took 3 days ... for variable 0x40 to change from 0x00 to 0x04 ...

A question is, how it is handled in the vanilla game. If there's no difference, we can (more or less) assume that it worked that way since the beginning. Even on new built streets or rail tracks it takes a bit before the the tiles get snowy.

Tschö, Auge

2-3 days, just tested

[Eddi]

snow falls during the "tile loop". just clear a large area with the bull dozer and observe the pattern.