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.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.
JGR's Patch Pack
Moderator: OpenTTD Developers
-
- Engineer
- Posts: 7
- Joined: 30 Jun 2019 01:45
Re: JGR's Patch Pack
Re: JGR's Patch Pack
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
Patch Pack, Github
Re: JGR's Patch Pack
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.JGR wrote: ↑01 Jul 2019 22:04It 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.
-
- Engineer
- Posts: 7
- Joined: 30 Jun 2019 01:45
Re: JGR's Patch Pack
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.
Re: JGR's Patch Pack
Thanks for reporting this and going through the trouble to document the problem.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
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
Patch Pack, Github
-
- Engineer
- Posts: 7
- Joined: 30 Jun 2019 01:45
Re: JGR's Patch Pack
Thank you for the fix!JGR wrote: ↑03 Jul 2019 01:40Thanks for reporting this and going through the trouble to document the problem.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
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.
Re: JGR's Patch Pack
So im trying to compile the patch to Ubuntu Xenial and i got this error while i was trying to configure
Edit: Followed https://wiki.openttd.org/Compiling_on_( ... D#Manually
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
Re: JGR's Patch Pack
This suggests that libsdl is not installed, try running: `sudo apt build-dep openttd` or `sudo apt install libsdl1.2-dev`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
Edit: Followed https://wiki.openttd.org/Compiling_on_( ... D#ManuallyCode: 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
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
Signal routing quirk
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: -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:
I reproduced it in the plain 0.31.2 version: -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:
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Re: Signal routing quirk
It all depends on the properties of the world.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
-
- Engineer
- Posts: 6
- Joined: 10 Jul 2019 09:40
- Location: Wildesford, on some TTO map
Re: JGR's Patch Pack
I can confirm this on Debian, but with libsdl1.2-dev and libsdl2-dev definitely installed. Reinstalling them didn't help either.JGR wrote: ↑07 Jul 2019 23:56This suggests that libsdl is not installed, try running: `sudo apt build-dep openttd` or `sudo apt install libsdl1.2-dev`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
Edit: Followed https://wiki.openttd.org/Compiling_on_( ... D#ManuallyCode: 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
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.
Re: JGR's Patch Pack
What is the output of: `pkg-config sdl --modversion`?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.
Would you be able to post the relevant bit of config.log?
What bug are you referring to? If it is one that is unfixed could you give some more details.
I'll take a look into this, a savegame would be useful if that's all right.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.
Thanks.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
-
- Engineer
- Posts: 6
- Joined: 10 Jul 2019 09:40
- Location: Wildesford, on some TTO map
Re: JGR's Patch Pack
JGR wrote: ↑10 Jul 2019 11:26What is the output of: `pkg-config sdl --modversion`?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.
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
The one with the disappearing bridges. It's fixed.
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 wrote: ↑10 Jul 2019 11:26I'll take a look into this, a savegame would be useful if that's all right.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.
Re: Signal routing quirk
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.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.
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
Patch Pack, Github
Re: JGR's Patch Pack
This should be fixed now, so don't worry too much about the savegame.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.
Ex TTDPatch Coder
Patch Pack, Github
Patch Pack, Github
-
- Chief Executive
- Posts: 675
- Joined: 03 Apr 2016 20:19
Re: JGR's Patch Pack
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.
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.
Re: JGR's Patch Pack
I do have other (higher priority) things to do as well you know.SimYouLater wrote: ↑11 Jul 2019 23:05Not trying to rush you, but it takes longer than 2 months to add in NRT?
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
Patch Pack, Github
-
- Chief Executive
- Posts: 675
- Joined: 03 Apr 2016 20:19
Re: JGR's Patch Pack
I understand. Like I said, not trying to rush you. Sorry about that.
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.
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.
Re: Signal routing quirk
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.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.
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.
Tinkering in the code in between writing mostly naughty stuff.
See http://scifurz.wordpress.com/
See http://scifurz.wordpress.com/
Who is online
Users browsing this forum: No registered users and 47 guests