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

Towa Shina
Engineer
Engineer
Posts: 7
Joined: 30 Jun 2019 01:45

Re: JGR's Patch Pack

Post by Towa Shina »

Towa Shina wrote: 30 Jun 2019 02:28 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. :bow:
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Lw25 wrote: 30 Jun 2019 16:29 I sent it by dm :wink:
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.
Ex TTDPatch Coder
Patch Pack, Github
Lw25
Engineer
Engineer
Posts: 19
Joined: 09 Jun 2019 13:41

Re: JGR's Patch Pack

Post by Lw25 »

JGR wrote: 01 Jul 2019 22:04
Lw25 wrote: 30 Jun 2019 16:29 I sent it by dm :wink:
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
Engineer
Engineer
Posts: 7
Joined: 30 Jun 2019 01:45

Re: JGR's Patch Pack

Post by 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 108 times
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Towa Shina wrote: 02 Jul 2019 23:17 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.
Ex TTDPatch Coder
Patch Pack, Github
Towa Shina
Engineer
Engineer
Posts: 7
Joined: 30 Jun 2019 01:45

Re: JGR's Patch Pack

Post by Towa Shina »

JGR wrote: 03 Jul 2019 01:40
Towa Shina wrote: 02 Jul 2019 23:17 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
Engineer
Engineer
Posts: 1
Joined: 07 Jul 2019 22:52

Re: JGR's Patch Pack

Post by 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
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

ForoxYT wrote: 07 Jul 2019 22:59 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`
Ex TTDPatch Coder
Patch Pack, Github
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Signal routing quirk

Post by 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
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
Eddi
Tycoon
Tycoon
Posts: 8258
Joined: 17 Jan 2007 00:14

Re: Signal routing quirk

Post by Eddi »

SciFurz wrote: 09 Jul 2019 23:41My 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!
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Re: Signal routing quirk

Post by SciFurz »

Eddi wrote: 10 Jul 2019 02:10
SciFurz wrote: 09 Jul 2019 23:41My 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.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
Guy from Wildesford
Engineer
Engineer
Posts: 6
Joined: 10 Jul 2019 09:40
Location: Wildesford, on some TTO map

Re: JGR's Patch Pack

Post by Guy from Wildesford »

JGR wrote: 07 Jul 2019 23:56
ForoxYT wrote: 07 Jul 2019 22:59 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.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Guy from Wildesford wrote: 10 Jul 2019 10:02 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?
Guy from Wildesford wrote: 10 Jul 2019 10:02(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.
Guy from Wildesford wrote: 10 Jul 2019 10:02Also, 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.
Ex TTDPatch Coder
Patch Pack, Github
Guy from Wildesford
Engineer
Engineer
Posts: 6
Joined: 10 Jul 2019 09:40
Location: Wildesford, on some TTO map

Re: JGR's Patch Pack

Post by Guy from Wildesford »

JGR wrote: 10 Jul 2019 11:26
Guy from Wildesford wrote: 10 Jul 2019 10:02 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).
JGR wrote: 10 Jul 2019 11:26
Guy from Wildesford wrote: 10 Jul 2019 10:02(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.
JGR wrote: 10 Jul 2019 11:26
Guy from Wildesford wrote: 10 Jul 2019 10:02Also, 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.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: Signal routing quirk

Post by JGR »

SciFurz wrote: 09 Jul 2019 23:41 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.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Guy from Wildesford wrote: 10 Jul 2019 13:42I'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.
Ex TTDPatch Coder
Patch Pack, Github
SimYouLater
Chief Executive
Chief Executive
Posts: 675
Joined: 03 Apr 2016 20:19

Re: JGR's Patch Pack

Post by SimYouLater »

JGR wrote: 11 Jul 2019 21:38...
Not trying to rush you, but it takes longer than 2 months to add in NRT?
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

SimYouLater wrote: 11 Jul 2019 23:05
JGR wrote: 11 Jul 2019 21:38...
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.
Ex TTDPatch Coder
Patch Pack, Github
SimYouLater
Chief Executive
Chief Executive
Posts: 675
Joined: 03 Apr 2016 20:19

Re: JGR's Patch Pack

Post by SimYouLater »

JGR wrote: 11 Jul 2019 23:30
SimYouLater wrote: 11 Jul 2019 23:05
JGR wrote: 11 Jul 2019 21:38...
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.
JGR wrote: 11 Jul 2019 23:30That 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.
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.
User avatar
SciFurz
Traffic Manager
Traffic Manager
Posts: 154
Joined: 13 Oct 2018 16:33
Contact:

Re: Signal routing quirk

Post by SciFurz »

JGR wrote: 11 Jul 2019 02:59
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
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 13 guests