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
kamnet
Moderator
Moderator
Posts: 7017
Joined: 28 Sep 2009 17:15
Location: Eastern KY
Contact:

Re: JGR's Patch Pack

Post by kamnet »

graphicnano wrote:
10 Feb 2020 10:41
Could you please give me a version of openttd for mac already patched with this patch? :P i really am too noob to understand how to write and code :\
It's not particularly difficult. It's mostly learning how to follow directions. And, once you learn, you're no longer noob ;)

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

Re: JGR's Patch Pack

Post by JGR »

Auge wrote:
10 Feb 2020 10:08
Hello
JGR wrote:
09 Feb 2020 21:58
Diesel Power wrote:
09 Feb 2020 14:17
What's wrong with this picture?
I'm using 33.0.0
Could you elaborate as to what specifically you are drawing attention to?
The only thing I found, is the town noise limit of 65535.

Tschö, Auge
Should be fixed now.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

Whare
Engineer
Engineer
Posts: 70
Joined: 22 Feb 2003 14:43

Re: JGR's Patch Pack

Post by Whare »

Damn been such a long time since I have posted on here :( EDIT(damn worse than I thought just check my post history 10years have slipped by sorry guys)/EDIT

anyway lets get to the point ;)

JGR been trying to use the Scheduled Dispatch but I have seen there is a bug with the Day Length if you set the day length over 3 (I think) it makes all the dispatch times change personally I like to run really long days (40 to 50) and high tick (200+)

So

1. are you able to fix this (I think the author has corrected the issue in there patch but I have never been able to get my head around patching so I leave it to you guys that do no how to do it)

2. if an update is not an option has anybody found the sweet spot for a long ish day and high tick? (so that the times I input are what it sets as?)


Completely unrelated

what ever happened to the grass on old tracks patch I am guessing it just died off (No Pun Intended) that patch had some potential as it could very quick so you under used lines and was graphically pleasing to the eye

anyway if it did make a come back I would be happy to see it

Diesel Power
Traffic Manager
Traffic Manager
Posts: 194
Joined: 18 Jun 2016 19:05

Re: JGR's Patch Pack

Post by Diesel Power »

Auge wrote:
10 Feb 2020 10:08
Hello
JGR wrote:
09 Feb 2020 21:58
Diesel Power wrote:
09 Feb 2020 14:17
What's wrong with this picture?
I'm using 33.0.0
Could you elaborate as to what specifically you are drawing attention to?
The only thing I found, is the town noise limit of 65535.

Tschö, Auge
Bingo!
Auge wins a cookie!

Thanks for the fix JGR

mrjack2
Engineer
Engineer
Posts: 49
Joined: 21 Jan 2016 23:04

Re: JGR's Patch Pack

Post by mrjack2 »

Ooh, I had an idea. It'd be really good to be able to specify wait/travel times in minutes + ticks, rather than choosing one or the other in settings (I often have to switch between them multiple times when trying to fix a timetable).

My thinking would be to allow users to enter times with a colon for minutes and ticks, or a dot for non-integer number of minutes.

E.g. If I enter 2:50, it means 2 minutes and 50 ticks, while 2.5 means 2 and a half minutes (with appropriate rounding).

User avatar
ColdIce
Transport Coordinator
Transport Coordinator
Posts: 275
Joined: 25 Apr 2006 10:22
Location: Bucharest

Re: JGR's Patch Pack

Post by ColdIce »

Hy there,

I'm getting a crash.
Can you help me please? I don't know what is wrong.
Thank you

LE: In 0.33.0 I dont get any error. Must be something changed in 0.33.1
Attachments
crash.sav
(2.72 MiB) Downloaded 12 times
crash.txt
(44.67 KiB) Downloaded 5 times
error.png
error.png (16.1 KiB) Viewed 396 times
ImageImage

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

Re: JGR's Patch Pack

Post by JGR »

ColdIce wrote:
18 Feb 2020 13:49
Hy there,

I'm getting a crash.
Can you help me please? I don't know what is wrong.
Thank you

LE: In 0.33.0 I dont get any error. Must be something changed in 0.33.1
Thanks for the report, this should be fixed and will be in the next release.
Whare wrote:
11 Feb 2020 22:51
Damn been such a long time since I have posted on here :( EDIT(damn worse than I thought just check my post history 10years have slipped by sorry guys)/EDIT

anyway lets get to the point ;)

JGR been trying to use the Scheduled Dispatch but I have seen there is a bug with the Day Length if you set the day length over 3 (I think) it makes all the dispatch times change personally I like to run really long days (40 to 50) and high tick (200+)

So

1. are you able to fix this (I think the author has corrected the issue in there patch but I have never been able to get my head around patching so I leave it to you guys that do no how to do it)

2. if an update is not an option has anybody found the sweet spot for a long ish day and high tick? (so that the times I input are what it sets as?)
mrjack2 wrote:
15 Feb 2020 22:32
Ooh, I had an idea. It'd be really good to be able to specify wait/travel times in minutes + ticks, rather than choosing one or the other in settings (I often have to switch between them multiple times when trying to fix a timetable).

My thinking would be to allow users to enter times with a colon for minutes and ticks, or a dot for non-integer number of minutes.

E.g. If I enter 2:50, it means 2 minutes and 50 ticks, while 2.5 means 2 and a half minutes (with appropriate rounding).
I will look into these in due course, thanks for the bug reports/suggestions,
Whare wrote:
11 Feb 2020 22:51
Completely unrelated

what ever happened to the grass on old tracks patch I am guessing it just died off (No Pun Intended) that patch had some potential as it could very quick so you under used lines and was graphically pleasing to the eye

anyway if it did make a come back I would be happy to see it
It is not included. I do not have any plan to include it at present.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

_dp_
Traffic Manager
Traffic Manager
Posts: 145
Joined: 18 Dec 2013 12:32

Re: JGR's Patch Pack

Post by _dp_ »

JGR wrote:
21 Feb 2020 09:17
ColdIce wrote:
18 Feb 2020 13:49
Hy there,

I'm getting a crash.
Can you help me please? I don't know what is wrong.
Thank you

LE: In 0.33.0 I dont get any error. Must be something changed in 0.33.1
Thanks for the report, this should be fixed and will be in the next release.
Have you figured out what was causing it and whether it can be reproduced in vanila?

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

Re: JGR's Patch Pack

Post by JGR »

_dp_ wrote:
23 Feb 2020 08:42
JGR wrote:
21 Feb 2020 09:17
ColdIce wrote:
18 Feb 2020 13:49
Hy there,

I'm getting a crash.
Can you help me please? I don't know what is wrong.
Thank you

LE: In 0.33.0 I dont get any error. Must be something changed in 0.33.1
Thanks for the report, this should be fixed and will be in the next release.
Have you figured out what was causing it and whether it can be reproduced in vanila?
I have not tried to reproduce it.
The assertion in question `assert(amount - moving <= used_stations.size());` implies that the prior part of the algorithm is intended to distribute cargo such that the remainder is less than the number of stations to distribute to, however I cannot see how or why the prior part of the algorithm can be expected to maintain this invariant. Therefore I've removed the assertion and handled the case where the remainder is greater than or equal to the number of distributing stations. As this case presumably does not happen often I've gone for simplicity rather than strict fairness.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

_dp_
Traffic Manager
Traffic Manager
Posts: 145
Joined: 18 Dec 2013 12:32

Re: JGR's Patch Pack

Post by _dp_ »

JGR wrote:
23 Feb 2020 10:13
I have not tried to reproduce it.
The assertion in question `assert(amount - moving <= used_stations.size());` implies that the prior part of the algorithm is intended to distribute cargo such that the remainder is less than the number of stations to distribute to, however I cannot see how or why the prior part of the algorithm can be expected to maintain this invariant. Therefore I've removed the assertion and handled the case where the remainder is greater than or equal to the number of distributing stations. As this case presumably does not happen often I've gone for simplicity rather than strict fairness.
At that point unmoved amount can only contain bits of cargo that can not distributed precisely due to do integer rounding and those can't exceed 1 bit per station. So that assertion failing means that some assumptions preceding code relies on aren't true and should be investigated rather than just sweeping it under the rug.

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

Re: JGR's Patch Pack

Post by JGR »

_dp_ wrote:
23 Feb 2020 11:16
JGR wrote:
23 Feb 2020 10:13
I have not tried to reproduce it.
The assertion in question `assert(amount - moving <= used_stations.size());` implies that the prior part of the algorithm is intended to distribute cargo such that the remainder is less than the number of stations to distribute to, however I cannot see how or why the prior part of the algorithm can be expected to maintain this invariant. Therefore I've removed the assertion and handled the case where the remainder is greater than or equal to the number of distributing stations. As this case presumably does not happen often I've gone for simplicity rather than strict fairness.
At that point unmoved amount can only contain bits of cargo that can not distributed precisely due to do integer rounding and those can't exceed 1 bit per station. So that assertion failing means that some assumptions preceding code relies on aren't true and should be investigated rather than just sweeping it under the rug.
Sure, however in the short term, I had to do a release at short notice due to a different issue, and I could not leave this unmitigated. I do not want to keep receiving crash reports.

Looking at it now, I think that integer overflow in the multiplication stages could be a fruitful area to look into. I notice that this savegame has passenger generation turned up very high, and 100% station ratings.
Ex TTDPatch Coder, Grumpy Greymuzzle
Avatar by MoonsongWolf.
Patch Pack, Github
Dad-Coder since April 2018

_dp_
Traffic Manager
Traffic Manager
Posts: 145
Joined: 18 Dec 2013 12:32

Re: JGR's Patch Pack

Post by _dp_ »

JGR wrote:
23 Feb 2020 11:59
Looking at it now, I think that integer overflow in the multiplication stages could be a fruitful area to look into. I notice that this savegame has passenger generation turned up very high, and 100% station ratings.
Hmm, yeah, I guess it's possible for a newgrf to overflow it by producing > 256 units in 2E callback.
UPD. Nvm, that's capped at 256 as well. So afact there is no way to overflow it in vanilla.

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: N8king and 7 guests