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
vincentkoevoets
Engineer
Engineer
Posts: 17
Joined: 14 Nov 2014 10:49
Location: Assen, Netherlands

Re: JGR's Patch Pack

Post by vincentkoevoets » 12 Dec 2017 10:27

mak wrote:I can confirm that the update works.

Windows 10 (Home) 1709 Fall update.

:) :) :)
I can also confirm it works! I rolled back to 1703 once I discovered the problem with the mouse, and just now I updated again to 1709 and used JGR's new version, and all is well!
Thanks for the quick new build!

Dou
Engineer
Engineer
Posts: 5
Joined: 12 Dec 2017 08:15
Skype: f***
Location: f***
Contact:

Re: JGR's Patch Pack

Post by Dou » 12 Dec 2017 11:34

andythenorth wrote:
Dou wrote:I'm using wine on osx high sierra. after starting it closes without any message.
I build it myself on Sierra, and it worked fine last time I tried. ;)
https://github.com/JGRennison/OpenTTD-patches

Sorry, i have no idea how to build it myself from source. ?( Any tutorials available?

User avatar
andythenorth
Tycoon
Tycoon
Posts: 4863
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: JGR's Patch Pack

Post by andythenorth » 12 Dec 2017 11:38

Dou wrote:Sorry, i have no idea how to build it myself from source. ?( Any tutorials available?
Caveat: it's quite involved and requires using Terminal a lot.

I'm not a programmer though, and I can do it.

https://wiki.openttd.org/Compiling_on_Mac_OS_X

Dou
Engineer
Engineer
Posts: 5
Joined: 12 Dec 2017 08:15
Skype: f***
Location: f***
Contact:

Re: JGR's Patch Pack

Post by Dou » 12 Dec 2017 13:46

ok, i tried it, and got a load of errors. sorry, thats too much for me. maybe i try to setup windows with bootcamp. or any chance to get a compiled osx version?

marioxcc
Engineer
Engineer
Posts: 17
Joined: 25 Nov 2017 22:04

Re: JGR's Patch Pack

Post by marioxcc » 14 Dec 2017 20:02

Dou wrote:ok, i tried it, and got a load of errors. sorry, thats too much for me. maybe i try to setup windows with bootcamp. or any chance to get a compiled osx version?
Use GNU/Linux. It is free as in freedom and most (if not all) distributions are downloadable at no cost and the required programs for compiling are part of the system. I recommend Debian.

p4nzer
Engineer
Engineer
Posts: 25
Joined: 27 Jun 2017 21:43

Re: JGR's Patch Pack

Post by p4nzer » 16 Dec 2017 07:00

Is it possible to make the "ticks per minute" setting stored in save rather than global? Under the current system, if I switch between games with different tickrates the timetables get all messed up.

Eddi
Tycoon
Tycoon
Posts: 7366
Joined: 17 Jan 2007 00:14

Re: JGR's Patch Pack

Post by Eddi » 16 Dec 2017 12:05

ticks per minute should have no influence on how the timetables actually work.

also, this would force all people in a multiplayer game to have the same
You might not exactly be interested in Ferion, but if you are, have fun :)

User avatar
JGR
Tycoon
Tycoon
Posts: 1935
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR » 16 Dec 2017 17:16

JGR wrote:
Xaxa wrote:Yeah sure, I hope you have a way to deactivate newgrfs though for testing because I've scavenged all of the internet for some of the ones I play with (and there's quite a few ones). That's the reason why I initially didn't post the save file. If I can do that somehow to make life easier for you, you can let me know too and I'll get rid of the newgrfs for you.

Just fyi, these are the vehicle groups that have conditional stops /and/ scheduled departures (all belong to company #2: Connexxion):
- RB 1
- RB 2 (this one has quite a few)
- SVz 1
- SVz 2
- SVz 3 (only one each way)
- SVz 4

I got rid of the conditional stops with the other trams as it was bothering me.
I've done some initial testing and the effect where vehicles become unexpectedly late does not require the use of scheduled dispatch, only conditional orders.
It seems that after the conditional order jump the scheduled arrival time at the station which has been jumped to is the same as the scheduled departure time of the station before the jump (i.e. the timetabled travel time for conditional order jumps is 0).
Of course the real travel time is not 0 and so the vehicle becomes behind schedule.
In the case where conditional order jumps are not taken, timetabling seems to work fine.
I will look into a solution/workaround, but this may take some time.
It seems that it's already possible to set the travel time for conditional order jumps.
If you select the conditional order in the timetable window and use the "Change Time" button you can set the timetabled travel time for the conditional order jump itself. If you set the value judiciously you can avoid the issue of vehicles being excessively late after following the jump.
It seems that timetable autofill/automate cannot automatically fill this at the moment, and can assign the wrong travel time to the order after the jump if the jump was taken.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

p4nzer
Engineer
Engineer
Posts: 25
Joined: 27 Jun 2017 21:43

Re: JGR's Patch Pack

Post by p4nzer » 17 Dec 2017 21:41

Eddi wrote:ticks per minute should have no influence on how the timetables actually work.

also, this would force all people in a multiplayer game to have the same
You're right, what it actually affects is the scheduled dispatch feature, which is irritating because if you rely on dispatch scheduling, as I do, it can mess up your entire game.

p4nzer
Engineer
Engineer
Posts: 25
Joined: 27 Jun 2017 21:43

Re: JGR's Patch Pack

Post by p4nzer » 17 Dec 2017 21:55

I'm experiencing a confusing bug with routing restrictions.

Image

As in the image, the signals are set up so that fast trains long reserve through the station, while slow trains behave as normal. However, when trains enter from the path signal at the top right, both fast and stopping trains long reserve. It could be that I did something stupid, but this happens with roughly 1 out of every 5 or so similar signal setups, so I think it's probably a bug.

Image

I've attached the save file.
Attachments
British Rail, Dec 18th, 2034.sav
(164.2 KiB) Downloaded 48 times

Eddi
Tycoon
Tycoon
Posts: 7366
Joined: 17 Jan 2007 00:14

Re: JGR's Patch Pack

Post by Eddi » 18 Dec 2017 00:23

p4nzer wrote:
Eddi wrote:ticks per minute should have no influence on how the timetables actually work.

also, this would force all people in a multiplayer game to have the same
You're right, what it actually affects is the scheduled dispatch feature, which is irritating because if you rely on dispatch scheduling, as I do, it can mess up your entire game.
i don't know what dispatch scheduling is, but if it uses the ticks per minute for something gameplay relevant, it's a desync hazard.
You might not exactly be interested in Ferion, but if you are, have fun :)

ino
Engineer
Engineer
Posts: 101
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino » 18 Dec 2017 00:31

p4nzer wrote:
Eddi wrote:ticks per minute should have no influence on how the timetables actually work.

also, this would force all people in a multiplayer game to have the same
You're right, what it actually affects is the scheduled dispatch feature, which is irritating because if you rely on dispatch scheduling, as I do, it can mess up your entire game.
It doesn't. It just mess up what is displayed, because internally schedule dispatch store everything in Date + Tick. If you match the setting that the original game use (including wall clock offset), it should display everything nicely.

I do find having to adjust the setting irritating for each save game, so usually I adjust day length instead. I don't think it used to matter much until scheduled dispatch, where suddenly precise timetabling is more common.

User avatar
JGR
Tycoon
Tycoon
Posts: 1935
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR » 18 Dec 2017 00:59

ino wrote:It doesn't. It just mess up what is displayed, because internally schedule dispatch store everything in Date + Tick. If you match the setting that the original game use (including wall clock offset), it should display everything nicely.

I do find having to adjust the setting irritating for each save game, so usually I adjust day length instead. I don't think it used to matter much until scheduled dispatch, where suddenly precise timetabling is more common.
A user deliberately setting different ticks per minute values for their different savegames is not a use-case which occurred to me at the time.
I for one just set it once to a reasonable value and then leave it.

In principle this sort of thing could become a company setting, but that does introduce somewhat of a backwards compatibility and user-unexpected behaviour issue.
p4nzer wrote:I'm experiencing a confusing bug with routing restrictions.

...

As in the image, the signals are set up so that fast trains long reserve through the station, while slow trains behave as normal. However, when trains enter from the path signal at the top right, both fast and stopping trains long reserve. It could be that I did something stupid, but this happens with roughly 1 out of every 5 or so similar signal setups, so I think it's probably a bug.

...

I've attached the save file.
This is most likely because you have level crossings on the far side of the station before the signal with the routing restriction attached.
This will probably have caused the pathfinder to switch to next destination look-ahead before the signal is reached, as the destination has already been passed. This updates the current order for the purposes of pathfinding.
In most cases this is useful (for pathfinding) but it can be unintuitive in some cases.
Using a non-lookahead order for PBS action tests might work? I will investigate at some point.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

ino
Engineer
Engineer
Posts: 101
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino » 18 Dec 2017 01:07

JGR wrote:A user deliberately setting different ticks per minute values for their different savegames is not a use-case which occurred to me at the time.
I for one just set it once to a reasonable value and then leave it.

In principle this sort of thing could become a company setting, but that does introduce somewhat of a backwards compatibility and user-unexpected behaviour issue.
When I play a real-world map, I usually set tick per minute to allow me to use real-world timetable. That's the only use case I use. For generated map, I don't really care.

I have also thought of making it company setting, but I also don't think that's worth it. I just put some signs on the map indicating all the value I use for particular save game.

User avatar
Redirect Left
Tycoon
Tycoon
Posts: 6526
Joined: 22 Jan 2005 19:31
Location: Wakefield, West Yorkshire

Re: JGR's Patch Pack

Post by Redirect Left » 21 Dec 2017 00:58

Any chance of increasing the max string size for the signs, and also implement something to turn a new line (usually this is '\n' or similar). I currently end up having to place signs on consecutive blocks when I want to do long messages.
Image
Worst Behaved IRC Member of 2008, 2009 & 2010 - Go Me!

User avatar
Gwyd
Chief Executive
Chief Executive
Posts: 684
Joined: 17 Apr 2017 16:52
Location: Western Ile-de-France Region

Re: JGR's Patch Pack

Post by Gwyd » 22 Dec 2017 07:44

I got a crash in the latest version while taking part in the unholy act of changing NewGRFs. If you want to see it, you can have the crash log later. I didn't make an emergency save.

kucir
Engineer
Engineer
Posts: 4
Joined: 11 Jan 2010 16:20

Re: JGR's Patch Pack

Post by kucir » 22 Dec 2017 22:52

So we are playing newest patchpack and we came into economic troubles after some time. I do not know if it is related to this patch or it is because we exchanged car pack to some polish/hungary trucks and buses. but it is first time I see this behavior of gam and I am affraid to start new game as it can end the same.

I enclosed savegame so if anybody is interested, you can try to drive company back from red numbers.

We started early, building first invented cars and develop transport network around first city. After some years we noticed, that some buses started to be in red numbers. Then we found these are buses dedicated to particular ciites. I came to conclusion, that problematic lines are those, which are on the end of network - delivering people to their final destination. Looks like transport lines are too slow and people arrive to destination after too long time, so they refuse to pay for this kind of transport. I tried to split network to few smaller networks and suddenly, buses made profit again.

my questions:
Was there some economy change? In earlier games on earlier version we never faced this situation.
Is there some setting where I can change transport rates for our game?

I do not want to start game in later years and I also do not enjoy to make transport lines, which are not connected.
Attachments
Krotoszyn Wielki Transport, 30. čer 1948.sav
game save
(192.34 KiB) Downloaded 30 times

User avatar
acs121
Tycoon
Tycoon
Posts: 1900
Joined: 03 Nov 2017 18:57
Location: Courbevoie, near Paris, France

Re: JGR's Patch Pack

Post by acs121 » 22 Dec 2017 23:26

First, this has nothing to do here, but anyway :D

If your buses are in red numbers, it's because of the running costs that are too high compared to the revenue of those buses. You could use the BaseCosts NewGRF to lower the road vehicle running costs.

For the theory saying that your transport lines are too slow, i didn't check the savegame but in 1948 you have very good vehicles and if you use Polroad, the vehicles are quite good too in 1948. Of course, payment is reduced depending on the time it takes to go to the next town. But you should have good payment normally.

To know if your buses could make profit, let a little time go, click on the bus, go on "Details" and see how much passengers there are in the vehicle.

McZapkie
Tycoon
Tycoon
Posts: 1175
Joined: 18 Jan 2014 18:10

Re: JGR's Patch Pack

Post by McZapkie » 23 Dec 2017 09:38

I also noticed negative incomes during cargodist transfers.
And new option "feeder_payment_src_station".
Some explanation how feeders are working now would be welcome...
My experimental openTTD server: 149.156.194.203:3979 non-standard client, now testing: JGRPP http://tiny.pl/ggnch
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, preindustrial houses, wired, ECS industry extension, V4 CEE train set.
Addicted to freeciv longturn.

ino
Engineer
Engineer
Posts: 101
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino » 23 Dec 2017 14:03

Regarding how transfer works (or how it should be if it is not buggy): (Cargodist is just like normal transfer order)

1. Cargo age is counted only while cargo is on train (including while the train is still in the station, but exclude when it was stored in station)
2. When a train transfer/unload at a station, a profit to this station is calculate based on the original distance from the cargo loading station (NOT the origin station).
3.1 With respect to the bank balance, this profit is added to your bank balance when it is accepted by the station (i.e. at the final destination). With respect to vehicle profitability (and also what is shown in the viewport), if it's the final destination, it's the calculated profit minus any existing transfer credit. (Which, as we know, can cause it to be minus and is shown as a red "Cost" instead.).
3.2 If it is just transfer, the calculated profit minus any existing transfer credit, is then multiply by the transfer credit percentage (default 75%). This transfer credit is added to existing transfer credit of the cargo, and is also shown in viewport and use to calculate vehicle profitability. However, this amount does not affect your bank balance at all.

With option "feeder_payment_src_station": During transfer calculation, the distance between source/origin station and current station is used instead of between pickup station and current station. So this should result in less chance of having negative profit in the last leg.


That's how I understand the system anyway, which may not be totally accurate.

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: vrn and 7 guests