Page 119 of 127

Re: JGR's Patch Pack

Posted: 26 Aug 2019 00:10
by Aegir
AkipTsaqif wrote:
25 Aug 2019 12:45
JGR wrote:
24 Aug 2019 15:13
See here: https://github.com/JGRennison/OpenTTD-p ... angelog.md
The changes in 0.31.4 are included.
Alright thanks.

Anyway, whenever I use some building sets, only the first 4 of them were spawned in the cities, the rest doesn't appear at all. Is this a default behavior in the game code?
It's more just a matter of probabilities and what each buildings spawn chance/restrictions weigh them as. Some sets like the Swedish House set put the spawn odds on buildings relatively high, other sets like Japanset buildings put their spawn chances relatively low (a holdover from when I first coded the set). I haven't physically looked under the hood of Total Town Replacement Set but I suspect they have their odds set really high as well. Swedish Houses and TTRS as a result will dominate the building spawning on most maps. The newly re-released North American Building set tries to strike a ballance with sets so that if you are deliberately mix-and-matching sets you get the multicultural vibe rather than have NABS dominate the landscape like it always used to.

Likewise, if you have 3x3 grid generation set for towns instead of Better Roads you'll get plenty of 1x1 and 1x2/2x1 buildings, but bugger all 2x2's.

Re: JGR's Patch Pack

Posted: 26 Aug 2019 04:25
by AkipTsaqif
kamnet wrote:
25 Aug 2019 16:15
What sets did you use, which climate did you use, and what year did you launch the game?
Here is the building sets I've been using. I want to have a mix and match between low density and high skyscrapers buildings. The climate I used were mostly temperate.
Image

Re: JGR's Patch Pack

Posted: 26 Aug 2019 05:48
by kamnet
AkipTsaqif wrote:
26 Aug 2019 04:25
kamnet wrote:
25 Aug 2019 16:15
What sets did you use, which climate did you use, and what year did you launch the game?
Here is the building sets I've been using. I want to have a mix and match between low density and high skyscrapers buildings. The climate I used were mostly temperate.
Image
That's pretty close to what I run myself. Between Swedish Houses, TTRS and 1000 Buildings set, they're going to easily dominate the map when it first spawns. I'd try moving Canadian Cities and UK Town Set up into the top 5. Also, If you're using TTRS Early Mod, you don't need to use TTRS, you have both sets competing for the same buildings.

Re: JGR's Patch Pack

Posted: 26 Aug 2019 07:53
by AkipTsaqif
kamnet wrote:
26 Aug 2019 05:48
That's pretty close to what I run myself. Between Swedish Houses, TTRS and 1000 Buildings set, they're going to easily dominate the map when it first spawns. I'd try moving Canadian Cities and UK Town Set up into the top 5. Also, If you're using TTRS Early Mod, you don't need to use TTRS, you have both sets competing for the same buildings.
Thanks for recommending me that load order :D . Anyway, the Canadian City building gives me an error like this, why?

Image

Re: JGR's Patch Pack

Posted: 26 Aug 2019 09:20
by Aegir
AkipTsaqif wrote:
26 Aug 2019 07:53
kamnet wrote:
26 Aug 2019 05:48
That's pretty close to what I run myself. Between Swedish Houses, TTRS and 1000 Buildings set, they're going to easily dominate the map when it first spawns. I'd try moving Canadian Cities and UK Town Set up into the top 5. Also, If you're using TTRS Early Mod, you don't need to use TTRS, you have both sets competing for the same buildings.
Thanks for recommending me that load order :D . Anyway, the Canadian City building gives me an error like this, why?

Image
The person who coded the Canadian City Building set broke it deliberately for reasons I'm sure can only be speculated by the rest of us mere spectators.

The Canadian city set was basically a continuation of the original North American Building set that I released before I retired from making .grf's. After coming back and finding that these sets weren't available in working order anymore I rebuilt the original NABS from my sources, fixed some bugs, added some buildings that I had sprites for, and re-released it to Bananas. It's also up on github.

https://github.com/reldred/re_nabs

Re: JGR's Patch Pack

Posted: 03 Sep 2019 19:28
by pelya
I've finally decided to update Android version of JGR patchpack, which I've neglected for one year.
The problem was, my touchscreen patches were making it crash, and it was hard to debug, so I've removed all my touchscreen optimizations and published it as-is, with minimal changes just to make it compile for Android.
So now it is only playable if you have a mouse or use a laptop-style Android device with touchpad.
Even music does not work anymore. I wonder if anyone actually listens to these MIDI soundtracks.
Some users requested Android version of OpenTTD with full mouse support, which does not work so well in regular Android version, so let's call this the 'desktop' Android release from now on.

Google Play link: https://play.google.com/store/apps/deta ... nttd.jgrpp
Sources: https://sourceforge.net/projects/libsdl ... k/OpenTTD/

Re: JGR's Patch Pack

Posted: 04 Sep 2019 19:07
by alc
Hi JGR,
First of all, thanks for making this game even better. I started with TTD in 1997! Almos all the way long with TTDPatch, OpenTTD and recently I resume playing OpenTTD and discovered your patch pack.
I have a program crash. I have two coal trains going in circles around a station loading till reach 80% load with a jump order. At some point both got lost. On pause, I deleted the orders of one a re do it. On the second that was intended to go away of the loop, I shared the orders a inverted his way of circulation. When I unpaused, the game crashed.

Then I try to reopen the saved game and crash inmediately. I just realize that the .dmp and .png files were overwriten and are for this last crash.

See if it is usefull for you and if by any chance can clear the sav file for me I will appreciated.

Best regards,
Alberto

Re: JGR's Patch Pack

Posted: 04 Sep 2019 19:57
by alc
JGR,
I just find out my autosave file was just a few days from the crash!
The problem was in the orders as show on the MacDonaldxxxx.png file. 2. Maintain on depot; 3. Jump to 2 if ... Those circular conditions get them lost.

In the abouttocrash.sav is the closest situation before the crash but I can't recreate it.
On pause, I deleted the orders of train 68 and create new ones. I shared them with train 78 and I inverted his direction. Unpaused and crashed.

Thanks again,
Alberto

PS: I could not upload the save file when editing the previous post so I create a new one.

Re: JGR's Patch Pack

Posted: 04 Sep 2019 21:01
by JGR
alc wrote:
04 Sep 2019 19:07
Hi JGR,
First of all, thanks for making this game even better. I started with TTD in 1997! Almos all the way long with TTDPatch, OpenTTD and recently I resume playing OpenTTD and discovered your patch pack.
I have a program crash. I have two coal trains going in circles around a station loading till reach 80% load with a jump order. At some point both got lost. On pause, I deleted the orders of one a re do it. On the second that was intended to go away of the loop, I shared the orders a inverted his way of circulation. When I unpaused, the game crashed.

Then I try to reopen the saved game and crash inmediately. I just realize that the .dmp and .png files were overwriten and are for this last crash.

See if it is usefull for you and if by any chance can clear the sav file for me I will appreciated.

Best regards,
Alberto
Thanks for letting me know about this, I will investigate.
The most straightforward way to work around this and load your savegame is to load the game paused by holding the control key. Use the skip button on train 78's orders before unpausing.

In general, having trains looping round like that isn't really necessary, you would be better off simply using a full load order.

Re: JGR's Patch Pack

Posted: 05 Sep 2019 20:51
by alc
The most straightforward way to work around this and load your savegame is to load the game paused by holding the control key. Use the skip button on train 78's orders before unpausing.
Thanks for this tip. With this it is possible to recreate the program crash. :bow:
having trains looping round like that isn't really necessary, you would be better off simply using a full load order.
I played always with full load but my coal or iron ore mines never produce more than 12% due to low station rating (<80%). Us I understand with a full load order, a brand new or almost new train (13%) and Statue in town (10%) and less than 100 units of cargo waiting (16%) you have 39%. The 51% of less than 7.5 days from last pick up will not be get even if we have a train full loading on station per months.
If there is a better, easier and cheaper way, you all are welcome with recomendations.

I read in some earlier post that you are not willing to include bidirectional signals on bridges and tunnels due to the collision risks people may not take into account. To reduce the risk, it is necessary to create two slots, one for each direction and before letting a train enter, control that the opposite direction slot is empty. I tested on this saved game attached and works fine. Whenever someone wants to use them, it will need to take care of the contral as the patch won't do it. As a suggestion, warning sign may be displayed when installing them for the first time in a game.
Bidirectional.sav
(103.8 KiB) Downloaded 62 times
Thanks for the quick reply.

Re: JGR's Patch Pack

Posted: 05 Sep 2019 21:22
by JGR
alc wrote:
05 Sep 2019 20:51
Thanks for this tip. With this it is possible to recreate the program crash.
I have pushed a fix which should prevent copying or sharing orders getting the vehicle into an invalid state.
alc wrote:
05 Sep 2019 20:51
I played always with full load but my coal or iron ore mines never produce more than 12% due to low station rating (<80%). Us I understand with a full load order, a brand new or almost new train (13%) and Statue in town (10%) and less than 100 units of cargo waiting (16%) you have 39%. The 51% of less than 7.5 days from last pick up will not be get even if we have a train full loading on station per months.
If there is a better, easier and cheaper way, you all are welcome with recomendations.
The "Station rating tolerance to waiting time depends on cargo class" setting may help you here. It makes bulks cargoes such as coal, etc. less sensitive to collection frequency, and cargoes like passengers more sensitive.
alc wrote:
05 Sep 2019 20:51
I read in some earlier post that you are not willing to include bidirectional signals on bridges and tunnels due to the collision risks people may not take into account. To reduce the risk, it is necessary to create two slots, one for each direction and before letting a train enter, control that the opposite direction slot is empty. I tested on this saved game attached and works fine. Whenever someone wants to use them, it will need to take care of the contral as the patch won't do it. As a suggestion, warning sign may be displayed when installing them for the first time in a game.
Bidirectional.sav

Thanks for the quick reply.
Bidirectional signalling on bridges and tunnels is already implemented as of v0.26.0, over a year ago.
You should switch on the "Enable signals on bridges/tunnels advanced modes" setting, and use PBS signals (the kind which kind be passed from the rear side) on the bridge/tunnel.
As a special case, you do not need to use slots if your bidirectional line is solely a single bridge or tunnel, otherwise the slot layout you've used works fine. This was one of the key motivations for the slots feature.

Re: JGR's Patch Pack

Posted: 06 Sep 2019 20:06
by alc
The "Station rating tolerance to waiting time depends on cargo class" setting may help you here. It makes bulks cargoes such as coal, etc. less sensitive to collection frequency, and cargoes like passengers more sensitive.

Code: Select all

				uint waittime = ge->time_since_pickup;
				if (_settings_game.station.cargo_class_rating_wait_time) {
					if (cs->classes & CC_PASSENGERS) {
						waittime *= 3;
					} else if (cs->classes & CC_REFRIGERATED) {
						waittime *= 2;
					} else if (cs->classes & (CC_MAIL | CC_ARMOURED | CC_EXPRESS)) {
						waittime += (waittime >> 1);
					} else if (cs->classes & (CC_BULK | CC_LIQUID)) {
						waittime >>= 2;
					}
For Passengers Cargo class, to get 51% increase rating instead of 7,5 days become 2,5 days. For Refrigerated, 3,75; for Armoure and express, 15; For Bulk and Liquid, 30. Am I Correct?
Bidirectional signalling on bridges and tunnels is already implemented as of v0.26.0, over a year ago.
You should switch on the "Enable signals on bridges/tunnels advanced modes" setting, and use PBS signals (the kind which kind be passed from the rear side) on the bridge/tunnel.
I have it on but I didn't try it as I have read it were not implemented. Excellent but...

I have a crash with bidirectional tunnels. I have two trains in opposite directions on the same track as I incorrectly program the signals. Both were stopped by signals, train 111 was inside the right tunnel and I manage to pull it out. But train 40 remained waiting for free path. I remove to PBS signals in between the tunnels and nothing. Then I remove the tunnel signal and crash the game.
crash.dmp
(19.52 MiB) Downloaded 85 times
crash.png
(1.59 MiB) Not downloaded yet
crash.sav
(2.13 MiB) Downloaded 50 times
Have nice weeked

Re: JGR's Patch Pack

Posted: 07 Sep 2019 00:20
by JGR
alc wrote:
06 Sep 2019 20:06
For Passengers Cargo class, to get 51% increase rating instead of 7,5 days become 2,5 days. For Refrigerated, 3,75; for Armoure and express, 15; For Bulk and Liquid, 30. Am I Correct?
I couldn't confirm absolute values offhand, but the ratios look correct. Except that mail/armoured/express would be 5 instead of 15.
alc wrote:
06 Sep 2019 20:06
I have a crash with bidirectional tunnels. I have two trains in opposite directions on the same track as I incorrectly program the signals. Both were stopped by signals, train 111 was inside the right tunnel and I manage to pull it out. But train 40 remained waiting for free path. I remove to PBS signals in between the tunnels and nothing. Then I remove the tunnel signal and crash the game.
crash.dmp
crash.png
crash.sav

Have nice weeked
That should be fixed already, I'd suggest upgrading to v0.31.5.

Re: JGR's Patch Pack

Posted: 07 Sep 2019 11:51
by stefino_cz
Do you have a plan to add road signals? I had this patch in the past and have a nice graphics for it, but it is little bit useless when no good patchpack has it (it i don't count road signals patch).
Thanks, stefino :)

Savegame compatibility question

Posted: 07 Sep 2019 13:12
by SciFurz
For savegame compatibility of my patch I need to set game versions on this variable but I can't figure out how exactly.
From my debugging output it should be here in the SLXI chunk;
{ XSLFI_VARIABLE_DAY_LENGTH, XSCF_NULL, 2, 2, "variable_day_length", nullptr, nullptr, nullptr },

What's the correct syntax to set SLV_ on extended features?

Re: JGR's Patch Pack

Posted: 07 Sep 2019 13:34
by JGR
stefino_cz wrote:
07 Sep 2019 11:51
Do you have a plan to add road signals? I had this patch in the past and have a nice graphics for it, but it is little bit useless when no good patchpack has it (it i don't count road signals patch).
Thanks, stefino :)
If you mean traffic lights, I'm not planning on including them in their current form as they are only really decorative and don't usefully aid or control traffic flow.
SciFurz wrote:
07 Sep 2019 13:12
For savegame compatibility of my patch I need to set game versions on this variable but I can't figure out how exactly.
From my debugging output it should be here in the SLXI chunk;
{ XSLFI_VARIABLE_DAY_LENGTH, XSCF_NULL, 2, 2, "variable_day_length", nullptr, nullptr, nullptr },

What's the correct syntax to set SLV_ on extended features?
Extended feature version numbers are by design orthogonal to the trunk linear version number. You should not change the trunk linear version number except by performing merges with trunk, as otherwise this breaks backwards compatibility with trunk savegames.
In the case above the feature save version is 2, and the maximum supported feature load version is also 2. See the documentation of struct SlxiSubChunkInfo.
If your implementation of daylength or other features have diverged from mine, you should probably add new feature(s) which identify your particular implementation, and then bump the version of that feature(s) as necessary,
There is some introductory text at the top of extended_ver_sl.cpp which explains the scheme.

Re: JGR's Patch Pack

Posted: 07 Sep 2019 15:26
by SciFurz
JGR wrote:
07 Sep 2019 13:34
SciFurz wrote:
07 Sep 2019 13:12
For savegame compatibility of my patch I need to set game versions on this variable but I can't figure out how exactly.
From my debugging output it should be here in the SLXI chunk;
{ XSLFI_VARIABLE_DAY_LENGTH, XSCF_NULL, 2, 2, "variable_day_length", nullptr, nullptr, nullptr },

What's the correct syntax to set SLV_ on extended features?
Extended feature version numbers are by design orthogonal to the trunk linear version number. You should not change the trunk linear version number except by performing merges with trunk, as otherwise this breaks backwards compatibility with trunk savegames.
In the case above the feature save version is 2, and the maximum supported feature load version is also 2. See the documentation of struct SlxiSubChunkInfo.
If your implementation of daylength or other features have diverged from mine, you should probably add new feature(s) which identify your particular implementation, and then bump the version of that feature(s) as necessary,
There is some introductory text at the top of extended_ver_sl.cpp which explains the scheme.
I made it a new savegame version because that would make incompatible variables easier to detect, and the whole thing includes a modification of core functions. When I just changed the latest variable sizes it always ended up in crashes/unloadable savegames. Also, several variables are eliminated ike day_lenght_factor, timetable_subticks, schdispatch_start_date_ticks, the wallclock timing, and even _date_fract and _tick_counter, which are replaced just like I did for the vanilla 1.9.2 patch (I prefer to keep the two patches as similar as possible).

I'll have a look through the comments and see if I can get it to work as a feature for your patchpack. Thanks for the pointers.

Re: JGR's Patch Pack

Posted: 09 Sep 2019 17:16
by eshield
Hello,

I've ran into crash. Dunno what I did to raise it. Maybe logs will be useful.
OpenTTD JGR.rar
(2.3 MiB) Downloaded 44 times

Re: JGR's Patch Pack

Posted: 09 Sep 2019 19:19
by JGR
eshield wrote:
09 Sep 2019 17:16
Hello,

I've ran into crash. Dunno what I did to raise it. Maybe logs will be useful.
OpenTTD JGR.rar
Thanks for reporting this. I've reproduced it in this patchpack (0.32 branch) and in trunk.
I will look into a fix and/or bug report upstream.

Re: JGR's Patch Pack

Posted: 11 Sep 2019 11:35
by Argus
Crashing while starting
Crashlog http://leteckaposta.cz/932839200