JGR's Patch Pack

[Towa Shina]

Now moving on to the matter, I'm having trouble using the "Template Replacement" Feature. Let me explain this.

When I don't have any train and then buy 2 trains, they should be train #1 and #2. And then I sold #1 and buy 2 trains, I'll get #1 and #3, because #1 doesn't exist and #2 is already existing. This is normal, but the following is the problem. When I have train #1 and #2, then replace train #1 with the template replacement, I'll get #1(replaced) and #2. But however, when I go buy a train after that, I'll get #4. Even if I sell all trains and buy 4 trains, I'll get #1, #2, #4, and #5. Missing number 3 won't be able to use afterwards. In summary, each time when you replace a train with a template, the youngest train number will be occupied and won't be able to be used again. So if you replace #1 twice when you have #1 and #2, then #3 and #4 will be missing. This behavior occurs on 0.31.2 win64. I don't know whether this affects other features like maximum train limits or not, but it would be nice if this behavior and existing savefile is fixed.

I'm sorry but I can't reproduce the behaviour anymore after updating my newgrfs. I still have corrupted save datas, but even if I tried the same thing on that save data, everything went just fine. I think it was because of some newgrfs I installed rather than this patch pack. I apologize that I got you into a trouble.

[JGR]

I sent it by dm

It looks to me like the message is emitted correctly.
Trains 123, 144, 277, 507, 539, 658, etc. all struggle to ascend slopes as the freight weight multiplier is 5x, the slope steepness setting is 5%, and the locomotives provide insufficient power and/or tractive effort.
Train 507 is particularly problematic as one locomotive is electric but it has to run uphill on a non-electrified section.
Train 658 has to ascend two levels at once from a standing start.

For a 5% slope, plausible minimum values for the max T.E / weight and power / weight ratios would probably be around around 0.15 kN / t and 2 kW / t (use the show train weight ratios in details setting), for trains to be able to successfully ascend a single height level from a standing start. I'd suggest running some experiments to what values you can get away with.
For ascending multiple height levels at once that you could multiply that accordingly.

[Lw25]

I sent it by dm

It looks to me like the message is emitted correctly.
Trains 123, 144, 277, 507, 539, 658, etc. all struggle to ascend slopes as the freight weight multiplier is 5x, the slope steepness setting is 5%, and the locomotives provide insufficient power and/or tractive effort.
Train 507 is particularly problematic as one locomotive is electric but it has to run uphill on a non-electrified section.
Train 658 has to ascend two levels at once from a standing start.

For a 5% slope, plausible minimum values for the max T.E / weight and power / weight ratios would probably be around around 0.15 kN / t and 2 kW / t (use the show train weight ratios in details setting), for trains to be able to successfully ascend a single height level from a standing start. I'd suggest running some experiments to what values you can get away with.
For ascending multiple height levels at once that you could multiply that accordingly.

Thank you very much. Now at least I know it is my client problem. To be honest, I was mostly looking at powerfull electric locos as a possible error, Czech locs and SM42 were problematic for me since I played on 1.9.1 or even 1.8.0 but I did not manage to switch them all to something more powerful yet.

[Towa Shina]

I'm sorry that I'm still messing around here but I had to come back because the glitch I was talking about happened again. I'm now able to reploduce it and recorded it on a video. Could you please look into this? Thank you.

glitch.mp4

(7.98 MiB) Downloaded 169 times

[JGR]

I'm sorry that I'm still messing around here but I had to come back because the glitch I was talking about happened again. I'm now able to reploduce it and recorded it on a video. Could you please look into this? Thank you.
glitch.mp4

Thanks for reporting this and going through the trouble to document the problem.

It seems to me like there are two problems:
1. virtual vehicles used in the template editing window have (and therefore are reserving) unit numbers, which they shouldn't
2. removing the head virtual vehicle in the template editing window seems to result in a virtual vehicle (which has a unit number) being leaked

I will look into fixing these shortly.
Edit: Should be fixed now.

[Towa Shina]

I'm sorry that I'm still messing around here but I had to come back because the glitch I was talking about happened again. I'm now able to reploduce it and recorded it on a video. Could you please look into this? Thank you.
glitch.mp4

Thanks for reporting this and going through the trouble to document the problem.

It seems to me like there are two problems:
1. virtual vehicles used in the template editing window have (and therefore are reserving) unit numbers, which they shouldn't
2. removing the head virtual vehicle in the template editing window seems to result in a virtual vehicle (which has a unit number) being leaked

I will look into fixing these shortly.
Edit: Should be fixed now.

Thank you for the fix!

[ForoxYT]

So im trying to compile the patch to Ubuntu Xenial and i got this error while i was trying to configure

Code: Select all

checking awk... awk
detecting OS... UNIX
checking build system type... x86_64-linux-gnu
checking host system type... x86_64-linux-gnu
checking universal build... no
checking build cc... gcc
checking host cc... gcc
checking build c++... g++
checking host c++... g++
checking strip... disabled
checking builtin depend... yes
checking makedepend... disabled
detecting cpu-type... 64 bits
detecting SSE... found
checking static... no
checking unicode... no
using debug level... no
using desync debug level... no
using link time optimization... no
checking OSX sysroot... not OSX, skipping
checking allegro... not found
checking sdl... not found
checking COCOA... not OSX, skipping
checking GDI video driver... not Windows, skipping
configure: error: no video driver development files found
 If you want a dedicated server use --enable-dedicated as parameter

Edit: Followed https://wiki.openttd.org/Compiling_on_( ... D#Manually

[JGR]

So im trying to compile the patch to Ubuntu Xenial and i got this error while i was trying to configure

Code: Select all

checking awk... awk
detecting OS... UNIX
checking build system type... x86_64-linux-gnu
checking host system type... x86_64-linux-gnu
checking universal build... no
checking build cc... gcc
checking host cc... gcc
checking build c++... g++
checking host c++... g++
checking strip... disabled
checking builtin depend... yes
checking makedepend... disabled
detecting cpu-type... 64 bits
detecting SSE... found
checking static... no
checking unicode... no
using debug level... no
using desync debug level... no
using link time optimization... no
checking OSX sysroot... not OSX, skipping
checking allegro... not found
checking sdl... not found
checking COCOA... not OSX, skipping
checking GDI video driver... not Windows, skipping
configure: error: no video driver development files found
 If you want a dedicated server use --enable-dedicated as parameter

Edit: Followed https://wiki.openttd.org/Compiling_on_( ... D#Manually

This suggests that libsdl is not installed, try running: `sudo apt build-dep openttd` or `sudo apt install libsdl1.2-dev`

[SciFurz]

While building my new test track I discovered a weird quirk when I tried to deny the train towards a current order and force it to take an alternative route.

I reproduced it in the plain 0.31.2 version:

Refrence, 1980-12-23.png

(414.07 KiB) Not downloaded yet

-Deny does not work with entry direction from the front
-Except it did while testing with a split path signal in front of it
-Deny doesn't work at all when the signal faces another one directly in front of it (face to face)
-Also, when there's one tile between the signal and the corner/junction the train comes from

The setup as in the screenshot worked as intended, the train goes from Depot to station B and back via the shunt track at the left, instead of taking the corner in the middle which the train expected to be passable.
It looks to me YAPF does whatever it feels like since it ignored one signal when the direct path was interrupted by a deleted piece of track.

On another note, trucks bunch up at multiple stations the least amount of time when they're forced to enter clockwise. My guess is when a truck takes a left corner the tile on the left gets triggered later than one the right and the truck directly behind it sees it as a free one. The only times I've seen a second truck following directly behind the previous one while taking a right corner into the station was when either the first or the second truck attemtped to take over on the straight road before and failed or succeeded at the last moment. The distance between the two trucks is probably zero at the moment of cornering and again the path is seen as free.

The one-way station that displayed best behavior:

Beta-99, 2066-03-14-truck_station.png

(214.49 KiB) Not downloaded yet

[Eddi]

My guess is when a truck takes a left corner the tile on the left gets triggered later than one the right

Breaking News: Scientists discover that the inner curve is shorter than the outer curve!

[SciFurz]

My guess is when a truck takes a left corner the tile on the left gets triggered later than one the right

Breaking News: Scientists discover that the inner curve is shorter than the outer curve!

It all depends on the properties of the world.

[Guy from Wildesford]

So im trying to compile the patch to Ubuntu Xenial and i got this error while i was trying to configure

Code: Select all

checking awk... awk
detecting OS... UNIX
checking build system type... x86_64-linux-gnu
checking host system type... x86_64-linux-gnu
checking universal build... no
checking build cc... gcc
checking host cc... gcc
checking build c++... g++
checking host c++... g++
checking strip... disabled
checking builtin depend... yes
checking makedepend... disabled
detecting cpu-type... 64 bits
detecting SSE... found
checking static... no
checking unicode... no
using debug level... no
using desync debug level... no
using link time optimization... no
checking OSX sysroot... not OSX, skipping
checking allegro... not found
checking sdl... not found
checking COCOA... not OSX, skipping
checking GDI video driver... not Windows, skipping
configure: error: no video driver development files found
 If you want a dedicated server use --enable-dedicated as parameter

Edit: Followed https://wiki.openttd.org/Compiling_on_( ... D#Manually

This suggests that libsdl is not installed, try running: `sudo apt build-dep openttd` or `sudo apt install libsdl1.2-dev`

I can confirm this on Debian, but with libsdl1.2-dev and libsdl2-dev definitely installed. Reinstalling them didn't help either.

Also, there's one more problem with importing Spring 2013 savegames (after the bridge bug has been fixed): If a train has a longer schedule with jumps to orders from 17 to 32, the jump target numbers are reduced by 16. So a jump order to 17 becomes a jump order to 1, a jump order to 18 becomes a jump order to 2 and so forth, and a jump order to 32 becomes a jump order to 16. Jump targets from 33 upward are okay again, as are 16 and below.

[JGR]

I can confirm this on Debian, but with libsdl1.2-dev and libsdl2-dev definitely installed. Reinstalling them didn't help either.

What is the output of: `pkg-config sdl --modversion`?
Would you be able to post the relevant bit of config.log?

(after the bridge bug has been fixed)

What bug are you referring to? If it is one that is unfixed could you give some more details.

Also, there's one more problem with importing Spring 2013 savegames (after the bridge bug has been fixed): If a train has a longer schedule with jumps to orders from 17 to 32, the jump target numbers are reduced by 16. So a jump order to 17 becomes a jump order to 1, a jump order to 18 becomes a jump order to 2 and so forth, and a jump order to 32 becomes a jump order to 16. Jump targets from 33 upward are okay again, as are 16 and below.

I'll take a look into this, a savegame would be useful if that's all right.

Thanks.

[Guy from Wildesford]

I can confirm this on Debian, but with libsdl1.2-dev and libsdl2-dev definitely installed. Reinstalling them didn't help either.

What is the output of: `pkg-config sdl --modversion`?

Code: Select all

Package sdl was not found in the pkg-config search path.
Perhaps you should add the directory containing `sdl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'sdl', required by 'virtual:world', not found

Strange thing is that I've been able to build OpenTTD before until recently (at least JGR 0.31.0).

(after the bridge bug has been fixed)

What bug are you referring to? If it is one that is unfixed could you give some more details.

The one with the disappearing bridges. It's fixed.

Also, there's one more problem with importing Spring 2013 savegames (after the bridge bug has been fixed): If a train has a longer schedule with jumps to orders from 17 to 32, the jump target numbers are reduced by 16. So a jump order to 17 becomes a jump order to 1, a jump order to 18 becomes a jump order to 2 and so forth, and a jump order to 32 becomes a jump order to 16. Jump targets from 33 upward are okay again, as are 16 and below.

I'll take a look into this, a savegame would be useful if that's all right.

I'll see if I've got something that isn't too huge and doesn't use any exotic GRFs installed past the fruit shop.

[JGR]

While building my new test track I discovered a weird quirk when I tried to deny the train towards a current order and force it to take an alternative route.

I reproduced it in the plain 0.31.2 version:
Refrence, 1980-12-23.png

-Deny does not work with entry direction from the front
-Except it did while testing with a split path signal in front of it
-Deny doesn't work at all when the signal faces another one directly in front of it (face to face)
-Also, when there's one tile between the signal and the corner/junction the train comes from

The setup as in the screenshot worked as intended, the train goes from Depot to station B and back via the shunt track at the left, instead of taking the corner in the middle which the train expected to be passable.
It looks to me YAPF does whatever it feels like since it ignored one signal when the direct path was interrupted by a deleted piece of track.

A savegame would make it easier to verify what you're trying to achieve, however from your description I don't see that there is really a problem here.

The deny restriction prevents pathfinding beyond the signal in question (it is effectively equivalent to a dead end).
If all other paths are also dead ends then the pathfinder has no better option than to choose one of the dead ends anyway, which may well be a deny restricted signal. Which dead end may or may not get chosen is fairly arbitrary and you should not design your network around that.
If you want to force a train to reverse in a siding without using a waypoint, either use the "reverse behind signal" restriction, or use a depot, as the pathfinder can follow the reversal to the target.

[JGR]

I'll see if I've got something that isn't too huge and doesn't use any exotic GRFs installed past the fruit shop.

This should be fixed now, so don't worry too much about the savegame.

[SimYouLater]

...

Not trying to rush you, but it takes longer than 2 months to add in NRT?

[JGR]

...

Not trying to rush you, but it takes longer than 2 months to add in NRT?

I do have other (higher priority) things to do as well you know.
That said, the merge is on github already in a separate branch if you want to try it out pre-release/pre-testing.

[SimYouLater]

...

Not trying to rush you, but it takes longer than 2 months to add in NRT?

I do have other (higher priority) things to do as well you know.

I understand. Like I said, not trying to rush you. Sorry about that.

That said, the merge is on github already in a separate branch if you want to try it out pre-release/pre-testing.

I'll give it a try. Thanks.

[SciFurz]

A savegame would make it easier to verify what you're trying to achieve, however from your description I don't see that there is really a problem here.

The deny restriction prevents pathfinding beyond the signal in question (it is effectively equivalent to a dead end).
If all other paths are also dead ends then the pathfinder has no better option than to choose one of the dead ends anyway, which may well be a deny restricted signal. Which dead end may or may not get chosen is fairly arbitrary and you should not design your network around that.
If you want to force a train to reverse in a siding without using a waypoint, either use the "reverse behind signal" restriction, or use a depot, as the pathfinder can follow the reversal to the target.

The original is my test trck for the realtime patch, so not very useful without compiling the realtime OpenTTD first (which is why I tested it quickly in the unmodified version as well). The track is circular and the normal behavior for trains sent to the depot is to go off to a terminated station farther away and return to the junction where they can enter the depot track from the opposite side, so if that counts as a dead end then it would explain it, although it's not obvious behavior if one doesn't know the pathfinder's behavior itself.
Even so, it doesn't explain why it works when I set entry to back of signal and not front of signal.
It's already clear the pathfinder can't think in terms of reversing at junctions or waypoints on its own, otherwise a train could already stop after one and take the other direction because it's a shorter path to the destination and I wouldn't need to arbitrarily stop a train through a specifiied order.

The reason for this setup is so I don't have to insert orders and designate waypoints when I occasionally send a train to the nearest depot for modification, or in other uses, redirect trains to a yard when the station is completely occupied (sreenshot 2) or get them to use a side track and reverse into the station next to the depot after creation (screenshot 3) instead of them going around in circles.
Yes, the usual way is to place depots perpendicular to the track, and no, I don't like the way it looks when trains enter or exit. :-p.

Beta-99, 2066_03_21-19_07.png

(572.72 KiB) Not downloaded yet

Beta-99, 2066_03_21-19_18.png

(671.51 KiB) Not downloaded yet

Beta-99, 2066_03_21-19_34.png

(780.82 KiB) Not downloaded yet