JGR's Patch Pack

[JGR]

Further to the industry mouseover issue, it's still not 100% (maybe due to changes in trunk?).

If the setting is 'right-click', right clicking on an industry does nothing, right clicking on an option shows the tooltip.
Setting it to 'hover X msecs' will show the industry info window but also shows tooltips over every other option (which is intensely annoying).

As neither setting gives a satisfactory display, I've reverted to 29.0 as it shows industry info windows and no tooltips.

A fix for this has already been implemented, it'll be in the next release.

I've just been trying this pack and noticed a problem with auto scheduling and seperation. If I turn it on for planes/buses or set it to automatically on in settings then quite often the vehicle does not empty at its destination and collect money. Often it takes the people back to their original airport and it costs money when/if it unloads.

Been playing with the original today and haven't seen that happen at all.

Could you post a savegame? I'll look into it.

Heya! Just throwing a crash report this way! First time happening, didn't see anything too weird leading up to it except occasional pausing, but that might be normal.

Thanks for reporting this, it will be fixed by the next release.
In the meantime turning disasters off should prevent further crashes.

I tried to compile the latest version on macOS Sierra 10.12.6 after ./configure --without-liblzo2 (as it refuses to use it for whatever reason) and ran into the following issue while compiling rev.cpp.
The same issue occurred on another copy with ./configure --enable-static --without-liblzo2

Code: Select all

[SRC] Compiling progress.cpp
[SRC] Compiling rail.cpp
[SRC] Compiling rail_cmd.cpp
[SRC] Compiling rail_gui.cpp
[SRC] Compiling rev.cpp
/Users/Val/Downloads/OpenTTD-patches-jgrpp/src/rev.cpp:91:72: error: expected
      expression
  ..._openttd_newgrf_version = 1 << 28 | 10 << 24 | 0 << 20 |  << 19 | 28004;
                                                               ^
1 error generated.
make[1]: *** [rev.o] Error 1
make: *** [all] Error 1

Does anyone have an idea what the root of the above issue is and how it can be fixed?

I found a solution that fixed the issue for me. Bit 19 in row 91 of src/rev.cpp is not defined at the moment:

Code: Select all

const uint32 _openttd_newgrf_version = 1 << 28 | 10 << 24 | 0 << 20 | !!ISSTABLETAG!! << 19 | 28004;

According to row 84 and 87-89, Bit 19 is defined as follows:

Code: Select all

84: *    19 1 if it is a release, 0 if it is not.
87: * The 19th bit is there so the development/betas/alpha, etc. leading to a
88: * final release will always have a lower version number than the released
89: * version, thus making comparisons on specific revisions easy.

It looks like this bit must be defined in order for Mac users to compile the patchpack successfully. After I replaced !!ISSTABLETAG!! with 1, changing Line 91 as follows, it worked (JGRpp v0.29.3).

Code: Select all

const uint32 _openttd_newgrf_version = 1 << 28 | 10 << 24 | 0 << 20 | 1 << 19 | 28004;

Thanks for reporting this, it is fixed and will be in the next release.

Hi JGR

I noticed since a couple versions that the company ratings are a bit wonky, their is a 5% rating not attributed sometimes to times, and randomly it seems

This looks like it is probably related to this: https://github.com/OpenTTD/OpenTTD/pull/7382 which is already fixed upstream.

Hi guys, hi JGR!

I enjoy playing JGRPP so much. So first, let me thank you, JGR, for allowing me to finally enjoy OTTD the way I always wanted - with challenge and depth. So thanks!

I have a question about ffpp's "Template based train replacement" patch you are using in your pack. Would it be possible for you to update it to the latest version with your next or future JGRPP updates? There is at least one crucial feature in the latest version of "ffpp's TBTR" that I would, personally, love to see in the game. It allows for creating template clones from trains that contain obsolete vehicles. The version you are using currently in JGRPP does not allow this. It would be an extremely useful feature for us who love to play with the templates feature.

Thank you for your time and effort!

Best regards

The implementation of TBTR which I have is loosely based on https://github.com/flitzpiepe/OpenTTD_T ... d82a6a59aa partly updated to match KeldorKatarn's fork (JokerPP) (971ba4928a5c7c7916fea55d91a3b6dd5bba140c), with a few dozen changes/fixes on top.
The commit in KeldorKatarn's branch is now gone as he periodically rebased it.
I don't know what version this may correspond to in terms of the forum thread.
Enabling creating templates with obsolete vehicles seems doesn't seem like a big change. If there is a commit where it's implemented and it is compatible I could cherry pick it, otherwise I can look into the possibility of implementing it directly in due course.

[OzTrans]

Programmable Signals ...

Maybe a bug, maybe not ...

I have implemented programmable signals, using Action5 Type ID mapping.

My signals have a permanent blue plaque on the mast and a lit blue light if programmed (restricted).

Below, all signals are programmable signals, the 2 top signals are programmed (restricted), the bottom ones have just a change of signal state applied. The 2 left signals are implemented in group 1 (light signals), the right ones in group 0 (semaphore signals).

The signal top right should have its blue light on; the other 3 signals show correct aspects.

Have the recolour sprites in tracerestrict been applied to semaphores too, or just to light signals ?

Prog Signals.png (8.39 KiB) Viewed 4685 times

Note: Tested with official version of jgrpp-0.29.3 [22 Mar 2019]

[JGR]

Programmable Signals ...

Maybe a bug, maybe not ...

I have implemented programmable signals, using Action5 Type ID mapping.

My signals have a permanent blue plaque on the mast and a lit blue light if programmed (restricted).

Below, all signals are programmable signals, the 2 top signals are programmed (restricted), the bottom ones have just a change of signal state applied. The 2 left signals are implemented in group 1 (light signals), the right ones in group 0 (semaphore signals).

The signal top right should have its blue light on; the other 3 signals show correct aspects.

Have the recolour sprites in tracerestrict been applied to semaphores too, or just to light signals ?

Prog Signals.png
Note: Tested with official version of jgrpp-0.29.3 [22 Mar 2019]

Thanks for reporting this.
It looks like the routing restriction recolour is being applied to programmable light signals even when they are overridden by a GRF.
I've added a fix so that the behaviour matches the other light signals.

[Davie_UCF]

Could I have some help with 'scheduled dispatch' ?
What causes the amount of early? over 1000 minutes early.



The timetable has all the values inputted.

Another question, when doing timetables without scheduled dispatch I keep them in multiples of 60. Do you have to do this for scheduled dispatch or will it keep them departing on the slots if you've set 30 minutes past an hour for example.

Cheers

[JGR]

Could I have some help with 'scheduled dispatch' ?
What causes the amount of early? over 1000 minutes early.



The timetable has all the values inputted.

Another question, when doing timetables without scheduled dispatch I keep them in multiples of 60. Do you have to do this for scheduled dispatch or will it keep them departing on the slots if you've set 30 minutes past an hour for example.

Cheers

Thanks for reporting this, which version are you using and can you provide a savegame?

[p4nzer]

Could I have some help with 'scheduled dispatch' ?
What causes the amount of early? over 1000 minutes early.



The timetable has all the values inputted.

Another question, when doing timetables without scheduled dispatch I keep them in multiples of 60. Do you have to do this for scheduled dispatch or will it keep them departing on the slots if you've set 30 minutes past an hour for example.

Cheers

To your last question, you don't need your timetables in multiples. It might even be better to intentionally NOT use multiples in order to allow for the trains to catch up if they arrive late.

[Redirect Left]

I'd like to make this suggestion that i suggested for stock OpenTTD, incase you're able/willing to add it to JGR, as i think it'd make scenario creation much quicker! viewtopic.php?f=32&t=85110

[Denswillow]

Game crashes when clicking a station, no crash report, version 0.30.1. Multiple companies use the same station, is that the problem?
Save game:

[acs121]

If your game crashes, normally you should have a crash report. If it just ends without any message asking for an emergency save or something like that, that's definitely not normal.

[Denswillow]

If your game crashes, normally you should have a crash report. If it just ends without any message asking for an emergency save or something like that, that's definitely not normal.

Yes, the game just shuts down with no warning. It only happens at one station(Keski-Fort Ringborough Bay)

[acs121]

So that confirms what I said. That's not normal. Are you absolutely sure there isn't a thing such as a crash.log or crash.sav in your OpenTTD folder ?

EDIT : I just opened your save and I see what happens. It looks weird.

EDIT 2 : I typed "gamelog" in the console and it appears your savegame is loaded from an emergency savegame. Just saying, but emergency savegames have their purpose in their name. It's just for debugging purposes - loading an emergency savegame is generally highly disreccomended.

[JGR]

If your game crashes, normally you should have a crash report. If it just ends without any message asking for an emergency save or something like that, that's definitely not normal.

Yes, the game just shuts down with no warning. It only happens at one station(Keski-Fort Ringborough Bay)

It appears to be a stack overflow due to a runaway recursive call, it is not all that surprising that no crash log/save is generated.

I've reproduced the issue using your save game, and will look into it further shortly.

Thanks for the report.

I'd like to make this suggestion that i suggested for stock OpenTTD, incase you're able/willing to add it to JGR, as i think it'd make scenario creation much quicker! viewtopic.php?f=32&t=85110

I'll look into the possibility in due course, thanks for the suggestion.

[SimYouLater]

My save from the Alpinea server is bugged. I have not changed any NewGRFs since starting the server, so I can only assume the "ghost utility pole depots" are the PP's fault.

Uploaded a save. NewGRFs are in a handy collection here. Help?

[JGR]

My save from the Alpinea server is bugged. I have not changed any NewGRFs since starting the server, so I can only assume the "ghost utility pole depots" are the PP's fault.

Uploaded a save. NewGRFs are in a handy collection here. Help?

I've loaded your savegame and nothing looks obviously wrong, can you clarify what the problem is?

[Wahazar]

I can confirm, that something is was wrong with Alpinea server.
When I checked missing newgrfs, all were marked red.
Suprisingly other "yellow" servers also gone "red".
Even when I checked online content - no content at all, like no connection to bananas.
After client restart, all was ok (with bananas and other servers) until I checked Alpinea newgrf - again broken online content.

[JGR]

I can confirm, that something is was wrong with Alpinea server.
When I checked missing newgrfs, all were marked red.
Suprisingly other "yellow" servers also gone "red".
Even when I checked online content - no content at all, like no connection to bananas.
After client restart, all was ok (with bananas and other servers) until I checked Alpinea newgrf - again broken online content.

Wrong colours in the UI seem to be caused by the "NewCC" NewGRF.
You should remove that GRF to fix that issue.

[SimYouLater]

I can confirm, that something is was wrong with Alpinea server.
When I checked missing newgrfs, all were marked red.
Suprisingly other "yellow" servers also gone "red".
Even when I checked online content - no content at all, like no connection to bananas.
After client restart, all was ok (with bananas and other servers) until I checked Alpinea newgrf - again broken online content.

Wrong colours in the UI seem to be caused by the "NewCC" NewGRF.
You should remove that GRF to fix that issue.

I don't think you understand. It's not wrong colors in the UI, something corrupted the save file for the Alpinea Server.

[JGR]

Game crashes when clicking a station, no crash report, version 0.30.1. Multiple companies use the same station, is that the problem?
Save game:

I've added a mitigation/fix for this issue which will be in the next release.

I don't think you understand. It's not wrong colors in the UI, something corrupted the save file for the Alpinea Server.

If you could be specific about what has been corrupted and what is wrong with the savegame which you've posted it would make it much easier for me to understand.
I am not familiar with the vast majority of the GRFs which you are using and I do not know what they are supposed to look like.
You mentioned "ghost utility pole depots", what does that mean?

[SimYouLater]

Game crashes when clicking a station, no crash report, version 0.30.1. Multiple companies use the same station, is that the problem?
Save game:

I've added a mitigation/fix for this issue which will be in the next release.

I don't think you understand. It's not wrong colors in the UI, something corrupted the save file for the Alpinea Server.

If you could be specific about what has been corrupted and what is wrong with the savegame which you've posted it would make it much easier for me to understand.
I am not familiar with the vast majority of the GRFs which you are using and I do not know what they are supposed to look like.
You mentioned "ghost utility pole depots", what does that mean?

It means I didn't take a screenshot, but depot graphics were appearing where there were no depots, and the ghost depots could not be demolished.

It means a single square of wagonway became a square of planning tracks.

It means a couple squares of one way road became two squares of just road.

It means someone kept having desync errors.

Here, I found another one...

It may not look like much, but that tile was wagonway a few in-game months prior.

[4$] qWorks, 06_13_1726.png (178.17 KiB) Viewed 2976 times

Here's a mockup of the ghost depots because I can't reproduce the bug.

Mockup of "ghost depots" from brain memory.

[4$] qWorks, 07_30_1726.png (207.33 KiB) Viewed 2969 times

Ignore the transparency, that's working like it should.

[Wahazar]

I don't think you understand. It's not wrong colors in the UI, something corrupted the save file for the Alpinea Server.

Well, let me be more specific. I wanted to report, that some of your newgrf on Alpinea server caused totally havoc with client-bananas connection.

It is not an issue with just wrong colors in gui, it is not possible to list online content.