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: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Valdez wrote: 04 Apr 2021 11:34 I've encountered this several times already in the past years, but only got to documenting it now..

Image

Something's wrong with some programmed signals, like the one in the example above. Ideally, they should function like this:

Code: Select all

Check train entry direction
	> If BACK - apply varying penalty to make trains prioritize different platforms depending on their direction, i.e. no awkward crossing over
	> ELSE - Check current order and maximum train speed
		>> If train doesn't stop at the station AND is faster than specified
			 - the signal should attempt a long reserve. BOTH conditions must be true.
		>> If only one or neither of these conditions apply, nothing should happen
			 - the train is either stopping (therefore it would pointlessly block the crossovers)
			 - or isn't fast enough to warrant a preferrential treatment
Here is one train that stops at Okayama, yet the signal shows green/clear. I've had this signal program fail in similar way in other places and work okay elsewhere (via program copying and just swapping the stations, so no chance of having different structure).

While there's a possibility it's a PEBKAC issue, I consider that fairly improbable - had that been the case, none of the signals with this programming would work properly.

What could be the problem? Something broken in the If.. Else If.. structure, or sometimes the game just doesn't evaluate current order condition properly?
The train's "current order" is advanced as the pathfinder moves past the target.
In this case, once the pathfinder/reservation has gone past the platform, the "current order" becomes the next item in the order list, and the "last visited station" becomes Okayama.
This is the same as in vanilla and is so that PBS works reasonably when you have a junction or similar on the far side of the target station or waypoint.
The signal is green because a long reservation is being made, because "current order is not Okayama" is true. A long reserve reservation would not normally occur because the train is stopping at the station. Turning on "show path reservations" should show this. Using "last visited station" instead ought to resolve this.
Valdez wrote: 04 Apr 2021 11:34 Also a possible feature suggestion - could a "release any/all slots" option be added to both signals and vehicle orders? Having to pick the exact slot can be a bit troublesome sometimes..
This would seem to me to be a bit too much of a potential footgun. Each slot is intended to be orthogonal to all other slots (except where the player has specifically programmed otherwise).
Having a slot be released because the train happened to go past the release point for a completely different slot would create issues which would be quite difficult to track down in a large network.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
nirasa
Engineer
Engineer
Posts: 83
Joined: 03 Sep 2015 07:11
Location: Czech republic

Re: JGR's Patch Pack

Post by nirasa »

OTTD JGR 0.40.5.
Linux XUbuntu 18.04
The trains are all the same and have the same load. I need to divide them into lines 1,2,3,1,2,3 etc. I can't set the programmable signal to work well. Am I making a mistake somewhere?
Thank you for any help
Attachments
jgr-program_signal.png
(255.55 KiB) Not downloaded yet
jgr-program_signal.sav
(23.82 KiB) Downloaded 70 times
My YouTube channel: https://www.youtube.com/c/nirasa/videos Czech language. :D
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

nirasa wrote: 04 Apr 2021 14:46 OTTD JGR 0.40.5.
Linux XUbuntu 18.04
The trains are all the same and have the same load. I need to divide them into lines 1,2,3,1,2,3 etc. I can't set the programmable signal to work well. Am I making a mistake somewhere?
Thank you for any help
You'd probably be better off using counters. See: https://github.com/JGRennison/OpenTTD-p ... g#counters

I don't see how the setup you're using at the moment would work for more than two choices.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
nirasa
Engineer
Engineer
Posts: 83
Joined: 03 Sep 2015 07:11
Location: Czech republic

Re: JGR's Patch Pack

Post by nirasa »

JGR wrote: 04 Apr 2021 15:47
nirasa wrote: 04 Apr 2021 14:46 OTTD JGR 0.40.5.
Linux XUbuntu 18.04
The trains are all the same and have the same load. I need to divide them into lines 1,2,3,1,2,3 etc. I can't set the programmable signal to work well. Am I making a mistake somewhere?
Thank you for any help
You'd probably be better off using counters. See: https://github.com/JGRennison/OpenTTD-p ... g#counters

I don't see how the setup you're using at the moment would work for more than two choices.
Ok, thank you :)
My YouTube channel: https://www.youtube.com/c/nirasa/videos Czech language. :D
Michpi
Engineer
Engineer
Posts: 62
Joined: 03 Feb 2021 18:51

Re: JGR's Patch Pack

Post by Michpi »

Fix flickering of polyrail measurement tooltip.
Now measurement tooltip "freezes" on window after using polyrail, if polyrail button is still pressed.

Could you please add some filters?
Cargo filter in Replace vehicles window.
Type filter in creating new vehicle template window.
As in the picture below
1.jpg
1.jpg (182.75 KiB) Viewed 1110 times
User avatar
CombatGold1
Tycoon
Tycoon
Posts: 4621
Joined: 29 May 2002 15:27
Location: Cardiff, South Wales
Contact:

Re: JGR's Patch Pack

Post by CombatGold1 »

I may have missed it in the thread if already asked, but is it possible to use this really splendid patch pack in the Steam release?

Now that I've started using OpenTTD in Steam I've realised how many features from JGRPP I miss! What an outstanding set of features this really is.

(Hard to search for the question with "steam" bringing up so many answers about steam trains.) :P
Thanks,
Adam Reece.
User avatar
kamnet
Moderator
Moderator
Posts: 8548
Joined: 28 Sep 2009 17:15
Location: Eastern KY
Contact:

Re: JGR's Patch Pack

Post by kamnet »

You can add your current install of JGRPP to Steam, but you won't get any of the benefits such as automatic updates.
User avatar
nirasa
Engineer
Engineer
Posts: 83
Joined: 03 Sep 2015 07:11
Location: Czech republic

Re: JGR's Patch Pack

Post by nirasa »

JGR wrote: 04 Apr 2021 15:47
nirasa wrote: 04 Apr 2021 14:46 OTTD JGR 0.40.5.
Linux XUbuntu 18.04
The trains are all the same and have the same load. I need to divide them into lines 1,2,3,1,2,3 etc. I can't set the programmable signal to work well. Am I making a mistake somewhere?
Thank you for any help
You'd probably be better off using counters. See: https://github.com/JGRennison/OpenTTD-p ... g#counters

I don't see how the setup you're using at the moment would work for more than two choices.
Thanks to JGR for the link to the counter. I am sorry. I can't understand how to set the routefinding restriction and programmable pre-signal for three tracks. I want the trains to change regularly. I have the files and image above in my post.
Can anyone tell me how to set the signals? Thank you very much.
My YouTube channel: https://www.youtube.com/c/nirasa/videos Czech language. :D
ZaphodB
Engineer
Engineer
Posts: 6
Joined: 17 Apr 2020 12:03

Re: JGR's Patch Pack

Post by ZaphodB »

nirasa wrote: 06 Apr 2021 05:44
JGR wrote: 04 Apr 2021 15:47
nirasa wrote: 04 Apr 2021 14:46 OTTD JGR 0.40.5.
Linux XUbuntu 18.04
The trains are all the same and have the same load. I need to divide them into lines 1,2,3,1,2,3 etc. I can't set the programmable signal to work well. Am I making a mistake somewhere?
Thank you for any help
You'd probably be better off using counters. See: https://github.com/JGRennison/OpenTTD-p ... g#counters

I don't see how the setup you're using at the moment would work for more than two choices.
Thanks to JGR for the link to the counter. I am sorry. I can't understand how to set the routefinding restriction and programmable pre-signal for three tracks. I want the trains to change regularly. I have the files and image above in my post.
Can anyone tell me how to set the signals? Thank you very much.
Here's one way of doing it (not claiming this is the best way necessarily). It uses a counter called "Splitter" which is incremented every time a train passes the entry signal and then resets to zero once it gets above two, using a programme on the entry signal. There is then a 'backwards-facing' path signal on each piece of track after the junction. The first one of these has a programme to 'deny' access to a train if the counter has the value 0. The second one denies if the value is 1, and so on. This has the effect of each train choosing the next path along compared to the previous train. And so on...

If you didn't want the restriction to be as strict, you could use the "penalty" function instead of "deny", for example if you had breakdowns on.
Attachments
Fort Martwood Transport, 2200-02-22.sav
(23.72 KiB) Downloaded 70 times
User avatar
CombatGold1
Tycoon
Tycoon
Posts: 4621
Joined: 29 May 2002 15:27
Location: Cardiff, South Wales
Contact:

Re: JGR's Patch Pack

Post by CombatGold1 »

kamnet wrote: 05 Apr 2021 23:22 You can add your current install of JGRPP to Steam, but you won't get any of the benefits such as automatic updates.
I thought as much, though knowing Steam it'll overwrite changes made at any point. :)
Thanks,
Adam Reece.
User avatar
nirasa
Engineer
Engineer
Posts: 83
Joined: 03 Sep 2015 07:11
Location: Czech republic

Re: JGR's Patch Pack

Post by nirasa »

ZaphodB wrote: 06 Apr 2021 09:42
nirasa wrote: 06 Apr 2021 05:44
JGR wrote: 04 Apr 2021 15:47
You'd probably be better off using counters. See: https://github.com/JGRennison/OpenTTD-p ... g#counters

I don't see how the setup you're using at the moment would work for more than two choices.
Thanks to JGR for the link to the counter. I am sorry. I can't understand how to set the routefinding restriction and programmable pre-signal for three tracks. I want the trains to change regularly. I have the files and image above in my post.
Can anyone tell me how to set the signals? Thank you very much.
Here's one way of doing it (not claiming this is the best way necessarily). It uses a counter called "Splitter" which is incremented every time a train passes the entry signal and then resets to zero once it gets above two, using a programme on the entry signal. There is then a 'backwards-facing' path signal on each piece of track after the junction. The first one of these has a programme to 'deny' access to a train if the counter has the value 0. The second one denies if the value is 1, and so on. This has the effect of each train choosing the next path along compared to the previous train. And so on...

If you didn't want the restriction to be as strict, you could use the "penalty" function instead of "deny", for example if you had breakdowns on.
Great! Thank you very much for a very illustrative and instructive example and explanation. It works! :D
My YouTube channel: https://www.youtube.com/c/nirasa/videos Czech language. :D
Eddi
Tycoon
Tycoon
Posts: 8257
Joined: 17 Jan 2007 00:14

Re: JGR's Patch Pack

Post by Eddi »

CombatGold1 wrote: 06 Apr 2021 10:32
kamnet wrote: 05 Apr 2021 23:22 You can add your current install of JGRPP to Steam, but you won't get any of the benefits such as automatic updates.
I thought as much, though knowing Steam it'll overwrite changes made at any point. :)
there's a difference between "adding a non-steam game to steam" and "overwriting the current steam installation's game files"
ZaphodB
Engineer
Engineer
Posts: 6
Joined: 17 Apr 2020 12:03

Re: JGR's Patch Pack

Post by ZaphodB »

JGR wrote: 27 Mar 2021 23:36
ZaphodB wrote: 15 Mar 2021 09:26 Hi there,

Is it possible to have a conditional order jump based on a train's timetable delay? I love using this patch pack to create realistic passenger networks with timetables and connecting services. The ability to have trains turn back short of their destination when delayed would be a great addition and mirrors the real practice of many operators.

Thank you for the patch pack and apologies if this suggestion has been made before.
This is implemented now, it'll be in the next release.
Thank you very much indeed for implementing this!

Also, the realistic braking feature is brilliant! I never imagined that OpenTTD would be come quite this close to a realistic model of signals and route setting. Even down to the intricacies of having a signal sighting distance. Absolutely fantastic, thanks again!
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: JGR's Patch Pack

Post by Wahazar »

When we have this deceleration patch implemented, maybe it is good idea to introduce third, yellow aspect for the signals?
For example distant signal green/yellow, which always allow to pass but works like 2w path signal with reserve trough programmed - it is trying to reserve path to the next signal in advance and display yellow aspect if failed.
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
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Aegir wrote: 30 Mar 2021 03:53 I wrote that patch so allow me to chime in; tbh I think it's the house placing patch that's got it wrong to be honest, probably because they've looked at the newgrf spec for house availability and accidentally read it backwards. How it then ended up being 1-5 instead of 0 > 4 or 4 > 0 though is anyones guess.

https://newgrf-specs.tt-wiki.net/wiki/V ... e_.2842.29

Zone 4 is the central zone and zone 0 is the outer most. This is consistent with the newgrf spec for writing newgrf houses, consistent with the raw variable names inside OpenTTD source code, and also consistent with the grf debug view for newhouses. I see no benefit whatsoever in changing the patch to contradict the newgrf spec or the game source code. That's a bad outcome for developers, a bad outcome for newgrf authors as well. I'll have a chat to JGR and see if changing the house picker UI is a better way to go.

As a side note; my favorite settings for that patch are 255/4/3/2/1 :D .
The town zones are consistently 4 - 0. The corresponding house zone bits are labelled HZ_ZON5 to HZ_ZON1, which is a little unfortunate, though they are in the same order.

In normal real-life town zoning, you'd start with zone 1 in the centre and increment going outwards. I had assumed that that was the way it was done internally as well until I noticed otherwise when merging the town zones PR.
As both the house picker UI and the additional settings are mainly useful to developers or advanced users who already know about the spec, I think it makes more sense to change the house picker UI in this instance.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
nirasa
Engineer
Engineer
Posts: 83
Joined: 03 Sep 2015 07:11
Location: Czech republic

Re: JGR's Patch Pack

Post by nirasa »

nirasa wrote: 06 Apr 2021 10:37
ZaphodB wrote: 06 Apr 2021 09:42
nirasa wrote: 06 Apr 2021 05:44

Thanks to JGR for the link to the counter. I am sorry. I can't understand how to set the routefinding restriction and programmable pre-signal for three tracks. I want the trains to change regularly. I have the files and image above in my post.
Can anyone tell me how to set the signals? Thank you very much.
Here's one way of doing it (not claiming this is the best way necessarily). It uses a counter called "Splitter" which is incremented every time a train passes the entry signal and then resets to zero once it gets above two, using a programme on the entry signal. There is then a 'backwards-facing' path signal on each piece of track after the junction. The first one of these has a programme to 'deny' access to a train if the counter has the value 0. The second one denies if the value is 1, and so on. This has the effect of each train choosing the next path along compared to the previous train. And so on...

If you didn't want the restriction to be as strict, you could use the "penalty" function instead of "deny", for example if you had breakdowns on.
Great! Thank you very much for a very illustrative and instructive example and explanation. It works! :D
EN: There is another possibility. Train counters and their regular distribution between lines.
CZ: Existuje ještě další možnost. Počitadla vlaků a jejich pravidelné rozdělení mezi tratě.
splitter-programmable-signal-en-maly.png
(1.31 MiB) Not downloaded yet
My YouTube channel: https://www.youtube.com/c/nirasa/videos Czech language. :D
User avatar
Tintinfan
Engineer
Engineer
Posts: 105
Joined: 29 Sep 2010 11:36

Re: JGR's Patch Pack

Post by Tintinfan »

Hello,

If a game starts with day length factor 80 and this is changed to say 70 in-game...all the trains built after this change to the game that use scheduled dispatch are broken (they are running a ridiculous number ahead of schedule) until you click "reset last dispatched" and then "reset late counter". Afterwards the train and scheduled dispatch work just fine after a day length factor change. I threw together a default game with a train built after changing daylength that has this insane delay, which can be fixed by doing the above steps.
dispatchbroken_80to70.sav
(33.53 KiB) Downloaded 64 times
Regards,

Tinny/Tintinfan. :)
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Tintinfan wrote: 17 Apr 2021 13:27 Hello,

If a game starts with day length factor 80 and this is changed to say 70 in-game...all the trains built after this change to the game that use scheduled dispatch are broken (they are running a ridiculous number ahead of schedule) until you click "reset last dispatched" and then "reset late counter". Afterwards the train and scheduled dispatch work just fine after a day length factor change. I threw together a default game with a train built after changing daylength that has this insane delay, which can be fixed by doing the above steps.

dispatchbroken_80to70.sav
Thanks for letting me know about this.
I was able to reproduce this without changing the day length in game. It appears to be an issue of signed integer overflow when the product of date and daylength is sufficiently high.
This will be fixed in the next release.
McZapkie wrote: 08 Apr 2021 12:01 When we have this deceleration patch implemented, maybe it is good idea to introduce third, yellow aspect for the signals?
For example distant signal green/yellow, which always allow to pass but works like 2w path signal with reserve trough programmed - it is trying to reserve path to the next signal in advance and display yellow aspect if failed.
I have thought about doing something like this, but it is not straightforward to implement and there are quite a few corner cases to handle.
Providing additional signal types with different default behaviour creates some issues in terms of the map array, the UI and upstream future compatibility. I can also imagine that there would be many different opinions on what any extra types should be (e.g. repeater as you've suggested, banner, shunt, weird semaphores, etc), and also on things what aspects to display and so on.
Such a thing would also be largely incompatible with existing GRF-provided signals.
Ex TTDPatch Coder
Patch Pack, Github
User avatar
Snail
Tycoon
Tycoon
Posts: 1283
Joined: 28 Apr 2003 18:52
Contact:

Re: JGR's Patch Pack

Post by Snail »

Hey JGR,

I just tried to compile your latest version (0.41.0) on my system, which is OS X 10.12 . I could compile versions up to 0.40.5 with no problems, thanks to your previous fix.

Now, at around 60%, I come across the following error:

Code: Select all

[ 63%] Building CXX object CMakeFiles/openttd.dir/src/network/network_udp.cpp.o
/roba/OpenTTD-patches-jgrpp-0.41.0/src/network/network_udp.cpp:733:18: error: expected ';' after
      expression
        std::scoped_lock lock(_udp_client.mutex, _udp_server.mutex, _udp_master.mutex);
                        ^
                        ;
/roba/OpenTTD-patches-jgrpp-0.41.0/src/network/network_udp.cpp:733:7: error: no member named
      'scoped_lock' in namespace 'std'; did you mean 'adopt_lock'?
        std::scoped_lock lock(_udp_client.mutex, _udp_server.mutex, _udp_master.mutex);
        ~~~~~^~~~~~~~~~~
             adopt_lock
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__mutex_base:79:25: note: 
      'adopt_lock' declared here
constexpr adopt_lock_t  adopt_lock  = adopt_lock_t();
                        ^
/roba/OpenTTD-patches-jgrpp-0.41.0/src/network/network_udp.cpp:733:2: warning: expression result
      unused [-Wunused-value]
        std::scoped_lock lock(_udp_client.mutex, _udp_server.mutex, _udp_master.mutex);
        ^~~~~~~~~~~~~~~~
1 warning and 2 errors generated.
make[2]: *** [CMakeFiles/openttd.dir/src/network/network_udp.cpp.o] Error 1
make[1]: *** [CMakeFiles/openttd.dir/all] Error 2
make: *** [all] Error 2
Your Mac OS bin works fine with my system, so my question is more of a curiosity. Would this be an easy error to fix? If so, it'd be great if it could get fixed, since I would still welcome the opportunity of compiling your patchpack myself.

Thanks in advance!
The French Narrow Gauge Train Set is now released! Get it here
Wahazar
Tycoon
Tycoon
Posts: 1451
Joined: 18 Jan 2014 18:10

Re: JGR's Patch Pack

Post by Wahazar »

JGR wrote: 18 Apr 2021 10:17 ...
Providing additional signal types with different default behaviour creates some issues in terms of the map array, the UI and upstream future compatibility. I can also imagine that there would be many different opinions on what any extra types should be (e.g. repeater as you've suggested, banner, shunt, weird semaphores, etc), and also on things what aspects to display and so on.
Such a thing would also be largely incompatible with existing GRF-provided signals.
Well, there are already additional programmable semaphores and works fine.
However they still provide 0/1 state, maybe additional state is a problem here?

So what about following simplification: signal which behave identical as currently existing path signal with reserve trough added,
but with graphics appearance of warning signal/repeater (whatsoever it is called)?
I mean, such signal would still work as all others signals do (just 0/1 state), just have different graphics to let user to easily distinguish from regular signals.
It would be also very convenient to have such ready-to-use signal with intrinsic reserve-trough.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 10 guests