JGR's Patch Pack

[andythenorth]

I believe this is not that hard to check if cargo is accepted or not on unload.

I agree it's not obvious, but how would it be fixed?

(I cannot think of anything that could help the player in this situation)

[strabist]

The attached savegame has quite a few strange issues:

• It loads without any financial history, but retains delivered cargo and performance rating graphs
• It loads with a balance of $0 and loans disabled
• Vehicle count is erroneously displayed as 0 in the detailed performance rating
• No income is generated from cargo delivery (the cargo payment rates graph also shows a flat $0 for all cargos)
• Airplane running costs, infrastructure costs and interest (despite having no loan) are still deducted from the balance

The issues above can be reproduced simply by starting a new game, immediately saving and then loading the saved file. Games saved in previous versions of vanilla OpenTTD and JGRPP load fine.

I am currently running jgrpp-0.25.0 (compiled with clang-6.0.0) on MacOS 10.13.4. I have been compiling new versions roughly on a weekly basis for quite a while, and this is the first time I am experiencing this issue. Please let me know if you need any other information.

Thanks for your great work!

[JGR]

The attached savegame has quite a few strange issues:

• It loads without any financial history, but retains delivered cargo and performance rating graphs
• It loads with a balance of $0 and loans disabled
• Vehicle count is erroneously displayed as 0 in the detailed performance rating
• No income is generated from cargo delivery (the cargo payment rates graph also shows a flat $0 for all cargos)
• Airplane running costs, infrastructure costs and interest (despite having no loan) are still deducted from the balance

The issues above can be reproduced simply by starting a new game, immediately saving and then loading the saved file. Games saved in previous versions of vanilla OpenTTD and JGRPP load fine.

I am currently running jgrpp-0.25.0 (compiled with clang-6.0.0) on MacOS 10.13.4. I have been compiling new versions roughly on a weekly basis for quite a while, and this is the first time I am experiencing this issue. Please let me know if you need any other information.

Thanks for your great work!

I found an Apple-specific bug in my code which looks like it would plausibly cause issues similar to this.
I've updated the branch with this and some other changes (commit fd4d9591).
Can you update and then try saving/loading again?
Thanks for testing.

[ino]

You need a second (different) station to load the new coal industry and unload on that station, otherwise it will be a mess to handle...

I believe this is not that hard to check if cargo is accepted or not on unload.

That is not related to your problem though. There is already a setting "Unload if accepted" which is default setting for new order anyway.

Your problem is as follow:
1) At your power plant station, the order is "Unload and take cargo", so it pick up the coal stored in the station produced by your new mine.
2) The train travel to your original mine, and try to full load coal there. However, since that station does not accept coal, the coal on your train is not unloaded at all.
3) The train travel back to your power plant, then it unloaded all your coal. You get paid here, however, since the distance is very small and travel time is long, you end up being in the red.

Don't use 'unload and take cargo'. Use 'no loading'.

Thanks. "No loading" works really well! But, this "feature" kinda is not that obvious for user.

BTW, one of the golden rules when you are reporting bug to modification of original software, is that if it exist in the original version as well, then it should be reported to the original developer, not the developer of the modification. This is the case here, as this "feature" exist since original Transport Tycoon.

Also I believe your original setting would result in UI showing "Unload and take cargo", which is IMO as obvious as it could get that because that station now produce coal, it would load the coal onto your train.

[Wahazar]

Version 0.25.0 still cannot handle refit+full load+load trough.
Separate load trough+full load or refit+load trough works fine, except minor issue with full load+trough load with mixed trains - sometimes it stuck for a while with "cargo reserved to load" - probably because this cargo is waiting for cars which are still outside of the station.

Generally trough load is a very nice feature, not just eyecandy one, it is also useful to delay train load/unload in case of daylength (industry have latency between unload and production, train without delay would unload too fast and not catch an output). Of course delay can be forced by timetable, but unload trough is more convenient to set.

[ino]

JGR,

I am sorry to bother you on this, but can you explain quickly the current branching? I am looking at current commits and branches, and I cannot quite make sense of what happened in last month or so?

EDIT: Okay, I guess I could make some sense now, as I realised my GUI Git Client (GitKraken) doesn't like it when you time-travel commit (i.e. the parent commit is later than current commit).

[peter1138]

my GUI Git Client (GitKraken) doesn't like it when you time-travel commit (i.e. the parent commit is later than current commit).

Really? That's pretty common in git, with cherry-picks and the like. Wouldn't expect a git client to break on that.

[ino]

my GUI Git Client (GitKraken) doesn't like it when you time-travel commit (i.e. the parent commit is later than current commit).

Really? That's pretty common in git, with cherry-picks and the like. Wouldn't expect a git client to break on that.

Yeah I am not sure what is happening either, but basically: https://imgur.com/temDhhQ

[Xaxa]

I think I keep pushing conditional ordering beyond its limits and it's not working properly for me (and it's messing with the departure boards).

In the example all of the IC 28X and 29X trains should enter Bonn Vaysplatz. However, only 50% should continue onwards to Duisburg Moers, while the other 50% should go to Oberhausen-Bonn. However, with the current way I conditionally ordered the schedule, all trains go via Duisburg Moers every time.

It also messes up the departure boards, as it notifies that all trains that enter Dusseldorf go via Duisburg Moers and end at Oberhausen-Bonn, which is an impossible route. Meanwhile, the Oberhausen-Bonn departure boards show ghost trains to Dusseldorf before disappearing off the board altogether (see attachment 2).

In theory, could I make the conditional orders work this way with the departure boards showing the correct routes? And make it so that 285 goes to A, 286 goes to B, 287 goes to A, 288 goes to B, etc etc. (Instead of all trains going to A first, then B the second time they come around.)

[ino]

There's option for conditional order with departure board: Giving up (default), assume taken, and assume not taken.

And in theory, no, you cannot really realistically fix departure board with conditional order. This is especially true with current departure board implementation: the implementation is sub-optimal and is hard to do many changes (my scheduled dispatch was (improperly) hacked in, for example). I might get around re-writing departure board sometimes though, as this also bugged me a lot.

[vrn]

Unfortunately, the game can't know in advance whether conditional orders will be taken or not, which also messes with CargoDist for example. In your case, I would split your ICE's in two groups, one going to Duisburg and the other to Oberhausen-Bonn. I'm by no means an expert, but I think it should be possible to schedule the trains in a way that the arrivals of the first and the second alernate.

[Xaxa]

There's option for conditional order with departure board: Giving up (default), assume taken, and assume not taken.

And in theory, no, you cannot really realistically fix departure board with conditional order. This is especially true with current departure board implementation: the implementation is sub-optimal and is hard to do many changes (my scheduled dispatch was (improperly) hacked in, for example). I might get around re-writing departure board sometimes though, as this also bugged me a lot.

Yeah I currently have set mine to give up. I'm really happy with the departure boards, they're awesome, but they indeed do not cope with conditional orders well. Would love to see them updated to cope better, but I do understand that they cannot know where the trains are going until they depart from a station and decide where they're going.

Unfortunately, the game can't know in advance whether conditional orders will be taken or not, which also messes with CargoDist for example. In your case, I would split your ICE's in two groups, one going to Duisburg and the other to Oberhausen-Bonn. I'm by no means an expert, but I think it should be possible to schedule the trains in a way that the arrivals of the first and the second alernate.

I originally had them as two separate groups, but the problem is that I would have to schedule them every 60 minutes instead of 30 minutes with two different routes. As two separate groups where they depart 30 minutes from one another, they will take up 2 platforms at the terminus stations, rather than one if they're scheduled every 30 minutes. (When scheduled every 60 minutes in two groups they would have rerturn times of 40+ minutes, while in one group with two routes, they have turning times of around 15~ minutes which is a lot better.)

[JGR]

Version 0.25.0 still cannot handle refit+full load+load trough.
Separate load trough+full load or refit+load trough works fine, except minor issue with full load+trough load with mixed trains - sometimes it stuck for a while with "cargo reserved to load" - probably because this cargo is waiting for cars which are still outside of the station.

Generally trough load is a very nice feature, not just eyecandy one, it is also useful to delay train load/unload in case of daylength (industry have latency between unload and production, train without delay would unload too fast and not catch an output). Of course delay can be forced by timetable, but unload trough is more convenient to set.

The two savegames which you posted previously which use load through with full load any cargo and refit seem to behave fine here.
A savegame would be useful if it's different to those ones.
In general it's non-trivial to entirely avoid pathological edge cases at the game play level if you're using mixed cargo trains with full load any cargo. The "any" cargo which satisfies the full load requirement may not be the one which you had in mind.

my GUI Git Client (GitKraken) doesn't like it when you time-travel commit (i.e. the parent commit is later than current commit).

Really? That's pretty common in git, with cherry-picks and the like. Wouldn't expect a git client to break on that.

Yeah I am not sure what is happening either, but basically: https://imgur.com/temDhhQ

I tend to re-arrange my commit graph a bit before pushing, I can't see anything obviously wrong with the commits which appear to be referenced in your screenshot though.
gitk renders the DAG fine here.

I think I keep pushing conditional ordering beyond its limits and it's not working properly for me (and it's messing with the departure boards).

In the example all of the IC 28X and 29X trains should enter Bonn Vaysplatz. However, only 50% should continue onwards to Duisburg Moers, while the other 50% should go to Oberhausen-Bonn. However, with the current way I conditionally ordered the schedule, all trains go via Duisburg Moers every time.

It also messes up the departure boards, as it notifies that all trains that enter Dusseldorf go via Duisburg Moers and end at Oberhausen-Bonn, which is an impossible route. Meanwhile, the Oberhausen-Bonn departure boards show ghost trains to Dusseldorf before disappearing off the board altogether (see attachment 2).

In theory, could I make the conditional orders work this way with the departure boards showing the correct routes? And make it so that 285 goes to A, 286 goes to B, 287 goes to A, 288 goes to B, etc etc. (Instead of all trains going to A first, then B the second time they come around.)

Conditional orders are evaluated at the time which the train reaches them. In the general case it's not possible to predict which path the train will later take.
The affects departure boards (next destinations prediction), cargo loading (next singular destination prediction), and cargo dest (link capacity to predicted next destination estimation).
Personally I don't use conditional orders at all as it creates too many problems for only marginal benefit.
Your current setup is likely to cause problems with cargo loading at Bonn Vaysplatz as well as with the departure boards.

I would suggest using two separate groups for something like this.
With scheduled dispatch and a fixed timetable you could re-implement the alternation in a way which works with departure boards and cargodest.

[ino]

Really? That's pretty common in git, with cherry-picks and the like. Wouldn't expect a git client to break on that.

Yeah I am not sure what is happening either, but basically: https://imgur.com/temDhhQ

I tend to re-arrange my commit graph a bit before pushing, I can't see anything obviously wrong with the commits which appear to be referenced in your screenshot though.
gitk renders the DAG fine here.

The yellow commit (at the begining of white arrow I drawn is the parent of the teal commit which the arrow pointed to. It took me a while to realise that lol.

I originally had them as two separate groups, but the problem is that I would have to schedule them every 60 minutes instead of 30 minutes with two different routes. As two separate groups where they depart 30 minutes from one another, they will take up 2 platforms at the terminus stations, rather than one if they're scheduled every 30 minutes. (When scheduled every 60 minutes in two groups they would have rerturn times of 40+ minutes, while in one group with two routes, they have turning times of around 15~ minutes which is a lot better.)

Yeah that's kinda bugged me too, and if you use scheduled dispatch (which I assume you do), I do have a solution in mind, just that I have no time to implement it yet (it's kinda huge).

For now, you can actually schedule two runs to different destination for each vehicle. Departure board consider the last station before duplicated station as the terminal, so it should works fine too.

[strabist]

I found an Apple-specific bug in my code which looks like it would plausibly cause issues similar to this.
I've updated the branch with this and some other changes (commit fd4d9591).
Can you update and then try saving/loading again?
Thanks for testing.

Thanks. Upgraded to 0.25.1 now and saving/loading seems to work fine!

Side note: Games saved on buggy versions still do not work properly, with most of the errors intact and a new one in tow (see attached picture)

[JGR]

I found an Apple-specific bug in my code which looks like it would plausibly cause issues similar to this.
I've updated the branch with this and some other changes (commit fd4d9591).
Can you update and then try saving/loading again?
Thanks for testing.

Thanks. Upgraded to 0.25.1 now and saving/loading seems to work fine!

Side note: Games saved on buggy versions still do not work properly, with most of the errors intact and a new one in tow (see attached picture)

The lower 32 bits of all 64 bit quantities was written to savegames as 0 in that version on Apple/OSX.
There isn't a way to recover the savegames, unfortunately.
I should have checked the diff more carefully.
It's difficult to completely avoid regressions when I can't build or test on most platforms however.

I have another platform-specific regression (ARM and similar) which I need to sort out shortly as well.

[LSky]

Since 0.25.1 my game crashes when I hit 'Find missing content online', worked fine in 0.25.0

[eshield]

Since 0.25.1 my game crashes when I hit 'Find missing content online', worked fine in 0.25.0

It would be nice if you attach a save game or crash dump here.

[JGR]

Since 0.25.1 my game crashes when I hit 'Find missing content online', worked fine in 0.25.0

This is fixed and will be in the next release. Thanks for the report.

It was possible to trigger this error in earlier versions of the patchpack.
It's more noticeable now as there are multiplayer servers with large numbers of (potentially unknown) GRFs,

[Tintinfan]

Good Afternoon,

I'm guessing from this issue on GitHub https://github.com/JGRennison/OpenTTD-patches/issues/58 that font rendering has changed in 0.25.1? We've been having issues with client-end crashing on my server, usually caused by posting unique characters such as "@" or "`" or "§" to name a few. Additionally, everyone complained that the first letter of each sentence in the chatbox was coloured;



Oddly enough, this wasn't happening to my client unless I deleted my own .cfg file which has the following extra lines:

Code: Select all

small_font = Arial
medium_font = Tahoma Bold
large_font = Arial
mono_font = Courier New

Having now had everyone change these few lines in their .cfg as well, the issue has vanished. We're all happy playing with the hideous fonts I play with as they don't break the game, but I am worried someone might loose their mind with all that Tahoma Bold everywhere soon! I'll put the crash report in just below as well.

[+] Spoiler

Code: Select all

*** OpenTTD Crash Report ***

Crash at: Tue Jun 12 16:30:04 2018
In game date: 1950-01-05 (25, 0)

Crash reason:
 Exception: E1212012
 Location:  00007FF8D2C1F218
 Message:   Assertion failed at line 468 of /home/jgr/openttd/cross-win64/src/gfx_layout.cpp: runs.End()[-1].first == length

OpenTTD version:
 Version:    jgrpp-0.25.1 (0)
 NewGRF ver: 19000000
 Bits:       64
 Endian:     little
 Dedicated:  no
 Build date: Jun  8 2018 02:25:41
 Configure:  ./configure --host=x86_64-w64-mingw32 --prefix=/home/jgr/mingw64/ CFLAGS=-I/home/jgr/mingw64/include LDFLAGS=-L/home/jgr/mingw64/lib --without-sdl --without-icu --with-lzo2=/home/jgr/mingw64/lib/liblzo2.a

Stack trace:
 D68A9D20 00007FF8 00000016 00000000 D4104698 00007FF8 00000000 00000000
 E1212012 00000000 00000000 00000000 D2C1F218 00007FF8 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 80000000 00000000 00002308 00000000 D5F2699C 00007FF8
 038FC5F8 00000000 D6820568 00007FF8 00070F7A 00000000 D687F157 00007FF8
 00000000 00000000 00000000 00000000 00000000 00007FF8 00000001 00000000
 21ABAFAE 00007F1D 038FC740 00000000 00000016 00000000 D409A9E0 00007FF8
 00000000 00000000 49E515FB 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 D687AD87 00007FF8 00000000 00000000 00000000 00000000
 289FE200 00000000 28903DF0 00000000 289C18E0 00000000 038FD0C0 00000000
 000000FF 00000000 D409EDEB 00007FF8 00000001 00000000 49E515FB 00007FF8
 038FCC70 00000000 28974B38 00000000 D39923C4 00007FF8 00000000 00000000
 038FC6F8 00000000 00000008 0000007C D39923C4 00007FF8 045B0D80 00000000
 00000082 00000000 038FC708 00000000 00000000 00000000 03ADB5C0 00000000
 D68A9E80 00007FF8 D5F39B7F 00007FF8 00320EC0 00000000 00000001 00000000
 045B0D80 00000000 045B0D80 00000000 00000001 00000000 00000030 00000002
 00110F66 00000000 00000202 00000000 00000000 00000000 D6820568 00007FF8
 3098A898 0000049A 00000282 00000000 03ACB900 00000000 D5F7D600 00007FF8
 00000000 00000000 D5F10000 00007FF8 00320EC0 00000000 D5F399DE 00007FF8
 03ACB5D0 00000000 00000001 00000000 00000000 00000000 00000002 00000000
 00000001 00000000 00000001 00000000 00000000 00000000 038FCB20 00000000
 00000010 00000000 03ACB900 00000000 038FC900 00000000 D5F7F697 00007FF8
 00010003 00000000 038FC900 00000000 038FCB20 00000000 03ACB900 00000000
 038FCB20 00000000 00000000 00000000 00000017 00000000 00000109 00000000

Registers:
 RAX: 0000000000110F66 RBX: 0000000000000016 RCX: 0000A37000000000 RDX: 00007FF8D5F2457D
 RSI: 00007FF8D4104698 RDI: 0000000000000000 RBP: 00000000038FCF44 RSP: 00000000038FC540
 R8:  0000000000000000 R9:  0000000000000215 R10: 0000000000000000 R11: 0000000000000002
 R12: 0000000000000910 R13: 0000000000000000 R14: 0000000000554DE0 R15: 0000000000000001
 RIP: 00007FF8D2C1F218 EFLAGS: 00000206

 Bytes at instruction pointer:
 48 8B 8C 24 C0 00 00 00 48 33 CC E8 28 AB 03 00 48 81 C4 D8 00 00 00 C3

Operating system:
 Name:     Windows
 Release:  6.2.9200 ()
 Compiler: GCC 5.3.1 "5.3.1 20160211"

Configuration:
 Blitter:      32bpp-sse2-anim
 Graphics set: OpenGFX (5580)
 Language:     H:\OpenTTD JGRPP Latest Version - Copy - Copy\lang\english.lng
 Music driver: win32
 Music set:    NoMusic (0)
 Network:      server
 Sound driver: win32
 Sound set:    NoSound (2)
 Video driver: win32

Fonts:
 Small:  sprite
 Medium: sprite
 Large:  sprite
 Mono:   sprite

AI Configuration (local: 0) (current: 0):
  0: Human

Libraries:
 FreeType:   2.6.0
 LZMA:       5.2.1
 LZO:        2.09
 PNG:        1.5.23
 Zlib:       1.2.8

Module information:
 H:\OpenTTD JGRPP Latest Version - Copy - Copy\openttd.exe handle: 0000000000400000 size: 40309207 crc: 0DF3E834 date: 2018-06-08 01:36:24
 C:\WINDOWS\SYSTEM32\ntdll.dll handle: 00007ff8d6810000 size: 1946304 crc: 37839AC3 date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\KERNEL32.DLL handle: 00007ff8d45f0000 size: 720632 crc: E36109EF date: 2018-04-11 23:34:40
 C:\WINDOWS\System32\KERNELBASE.dll handle: 00007ff8d2be0000 size: 2568656 crc: FF178D73 date: 2018-04-11 23:34:20
 C:\WINDOWS\System32\ADVAPI32.dll handle: 00007ff8d3ca0000 size: 645208 crc: 88E62B78 date: 2018-04-11 23:34:44
 C:\WINDOWS\System32\msvcrt.dll handle: 00007ff8d4070000 size: 636936 crc: D6A3C60E date: 2018-04-11 23:34:20
 C:\WINDOWS\System32\sechost.dll handle: 00007ff8d4580000 size: 368352 crc: D55ED681 date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\RPCRT4.dll handle: 00007ff8d6530000 size: 1191168 crc: F7C82091 date: 2018-05-14 05:36:45
 C:\WINDOWS\System32\GDI32.dll handle: 00007ff8d3d50000 size: 155040 crc: C6B0F3EA date: 2018-04-11 23:34:08
 C:\WINDOWS\System32\gdi32full.dll handle: 00007ff8d2f60000 size: 1634800 crc: 36CDEBDB date: 2018-05-14 05:36:45
 C:\WINDOWS\System32\msvcp_win.dll handle: 00007ff8d38f0000 size: 642088 crc: E7CD7CF9 date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\ucrtbase.dll handle: 00007ff8d2e60000 size: 1018616 crc: C6C134F0 date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\USER32.dll handle: 00007ff8d5f10000 size: 1639448 crc: A440790A date: 2018-04-11 23:34:14
 C:\WINDOWS\System32\win32u.dll handle: 00007ff8d3990000 size: 124048 crc: FACB4E5F date: 2018-04-11 23:34:12
 C:\WINDOWS\System32\IMM32.dll handle: 00007ff8d5b50000 size: 173648 crc: C00419EB date: 2018-04-11 23:34:24
 C:\WINDOWS\System32\SHELL32.dll handle: 00007ff8d4710000 size: 21389360 crc: 993546F5 date: 2018-05-14 05:36:45
 C:\WINDOWS\System32\cfgmgr32.dll handle: 00007ff8d3c50000 size: 286744 crc: B7105488 date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\shcore.dll handle: 00007ff8d6660000 size: 678808 crc: 6676E00D date: 2018-04-11 23:34:15
 C:\WINDOWS\System32\combase.dll handle: 00007ff8d5b80000 size: 3296896 crc: 8F05F33A date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\bcryptPrimitives.dll handle: 00007ff8d3870000 size: 494400 crc: F7DA43B9 date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\windows.storage.dll handle: 00007ff8d3100000 size: 7436624 crc: 4EBE1418 date: 2018-05-14 05:36:45
 C:\WINDOWS\System32\shlwapi.dll handle: 00007ff8d6140000 size: 326496 crc: 9E999772 date: 2018-04-11 23:34:33
 C:\WINDOWS\System32\kernel.appcore.dll handle: 00007ff8d2bc0000 size: 57952 crc: 3B79A205 date: 2018-04-11 23:34:10
 C:\WINDOWS\System32\profapi.dll handle: 00007ff8d2ba0000 size: 115800 crc: F2EDFE5C date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\powrprof.dll handle: 00007ff8d2b20000 size: 300208 crc: 615A899E date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\FLTLIB.DLL handle: 00007ff8d2b70000 size: 31584 crc: F9E8EFD2 date: 2018-04-11 23:34:22
 C:\WINDOWS\System32\WS2_32.dll handle: 00007ff8d6230000 size: 430408 crc: BCF23F7A date: 2018-04-11 23:34:22
 C:\WINDOWS\SYSTEM32\USP10.dll handle: 00007ff8bea50000 size: 79360 crc: CBCCE40C date: 2018-04-11 23:34:24
 C:\WINDOWS\SYSTEM32\WINMM.dll handle: 00007ff8cf070000 size: 123584 crc: 94826B12 date: 2018-04-11 23:34:04
 C:\WINDOWS\SYSTEM32\WINMMBASE.dll handle: 00007ff8cf040000 size: 162240 crc: 20283370 date: 2018-04-11 23:34:04
 C:\WINDOWS\system32\uxtheme.dll handle: 00007ff8d0fd0000 size: 599040 crc: 688AC957 date: 2018-04-11 23:34:36
 C:\WINDOWS\System32\MSCTF.dll handle: 00007ff8d3d90000 size: 1523752 crc: 6FF09421 date: 2018-04-11 23:34:23
 C:\WINDOWS\System32\OLEAUT32.dll handle: 00007ff8d6710000 size: 788216 crc: EB44C960 date: 2018-05-14 05:36:45
 C:\WINDOWS\system32\dwmapi.dll handle: 00007ff8d12b0000 size: 146840 crc: 5A168920 date: 2018-04-11 23:34:20
 C:\WINDOWS\SYSTEM32\TextInputFramework.dll handle: 00007ff8b5d20000 size: 616800 crc: 6CE95817 date: 2018-04-11 23:34:08
 C:\WINDOWS\SYSTEM32\CoreUIComponents.dll handle: 00007ff8c0690000 size: 3283400 crc: CB0AEA00 date: 2018-05-14 05:36:45
 C:\WINDOWS\SYSTEM32\CoreMessaging.dll handle: 00007ff8d0ca0000 size: 885848 crc: DADF3D20 date: 2018-05-14 05:36:45
 C:\WINDOWS\SYSTEM32\ntmarta.dll handle: 00007ff8d1c10000 size: 187576 crc: 751ABC3F date: 2018-04-11 23:34:23
 C:\WINDOWS\SYSTEM32\wintypes.dll handle: 00007ff8cf0a0000 size: 1363632 crc: 331FB0F9 date: 2018-04-11 23:34:22
 C:\WINDOWS\system32\mswsock.dll handle: 00007ff8d23a0000 size: 401968 crc: 76C6C00A date: 2018-04-11 23:34:22
 C:\WINDOWS\SYSTEM32\MMDevAPI.DLL handle: 00007ff8cd420000 size: 469576 crc: D3E68B51 date: 2018-04-11 23:34:02
 C:\WINDOWS\SYSTEM32\PROPSYS.dll handle: 00007ff8ce5b0000 size: 1792808 crc: 76F69B51 date: 2018-04-11 23:34:10
 C:\WINDOWS\SYSTEM32\DEVOBJ.dll handle: 00007ff8d27a0000 size: 152440 crc: B6F9124E date: 2018-04-11 23:34:22
 C:\WINDOWS\SYSTEM32\wdmaud.drv handle: 00007ff8af9f0000 size: 253952 crc: 294BD9E8 date: 2018-04-11 23:34:04
 C:\WINDOWS\SYSTEM32\ksuser.dll handle: 00007ff8bfc70000 size: 23360 crc: DA1D21C1 date: 2018-04-11 23:34:04
 C:\WINDOWS\SYSTEM32\AVRT.dll handle: 00007ff8c1270000 size: 30056 crc: 1F1BBFD7 date: 2018-04-11 23:34:04
 C:\WINDOWS\SYSTEM32\AUDIOSES.DLL handle: 00007ff8ae250000 size: 1209280 crc: A85F2B63 date: 2018-04-11 23:34:04
 C:\WINDOWS\SYSTEM32\msacm32.drv handle: 00007ff8bfb60000 size: 29184 crc: 43AA51E1 date: 2018-04-11 23:34:02
 C:\WINDOWS\SYSTEM32\MSACM32.dll handle: 00007ff8affa0000 size: 106480 crc: 54E5FD19 date: 2018-04-11 23:34:04
 C:\WINDOWS\SYSTEM32\midimap.dll handle: 00007ff8bf120000 size: 25088 crc: 3F472519 date: 2018-04-11 23:34:02
 C:\WINDOWS\System32\clbcatq.dll handle: 00007ff8d60a0000 size: 635368 crc: 219EFEA4 date: 2018-04-11 23:34:20
 C:\Windows\System32\Windows.UI.dll handle: 00007ff8b5800000 size: 1128616 crc: 62A15344 date: 2018-04-11 23:34:39
 C:\Windows\System32\InputHost.dll handle: 00007ff8b5780000 size: 491744 crc: BEAA3FC5 date: 2018-04-11 23:34:12
 C:\WINDOWS\System32\ole32.dll handle: 00007ff8d3f10000 size: 1375544 crc: BBABDC4A date: 2018-04-11 23:34:19
 C:\WINDOWS\System32\psapi.dll handle: 00007ff8d45e0000 size: 18712 crc: AA3B87EF date: 2018-04-11 23:34:20

---- gamelog start ----
Tick 0: new game started
Revision text changed to jgrpp-0.25.1, savegame version 198, not modified, _openttd_newgrf_version = 0x19000000
New game mode: 1 landscape: 0
---- gamelog end ----

Recent news messages:

Command Log:
 Showing most recent 0 of 0 commands

*** End of OpenTTD Crash Report ***

Decoded stack trace:
[00] KERNELBASE           0x00007FF8D2C1F218 RaiseException + 104
[01] msvcrt               0x00007FF8D409A9E0 raise + 512
[02] msvcrt               0x00007FF8D409EDEB abort + 27
[03] openttd              0x0000000000544E0F error(char const*, ...) + 95 (/home/jgr/openttd/cross-win64/src/openttd.cpp:132)
[04] openttd              0x00000000004BA1EF FallbackParagraphLayout::FallbackParagraphLayout(unsigned int*, int, SmallMap<int, Font*, 16u>&) + 79 (/home/jgr/openttd/cross-win64/src/gfx_layout.cpp:468)
[05] openttd              0x00000000004BC140 FallbackParagraphLayoutFactory::GetParagraphLayout(unsigned int*, unsigned int*, SmallMap<int, Font*, 16u>&) (/home/jgr/openttd/cross-win64/src/gfx_layout.cpp:306)
[06] openttd              0x00000000004B678D GetStringLineCount(unsigned int, int) + 61 (/home/jgr/openttd/cross-win64/src/gfx.cpp:577)
[07] openttd              0x00000000004FD2F9 NetworkDrawChatMessage() + 441 (/home/jgr/openttd/cross-win64/src/network/network_chat_gui.cpp:239)
[08] openttd              0x0000000000683A1D VideoDriver_Win32::MainLoop() + 333 (/home/jgr/openttd/cross-win64/src/video/win32_v.cpp:1287)
[09] openttd              0x00000000005467E5 openttd_main(int, char**) + 5493 (/home/jgr/openttd/cross-win64/src/openttd.cpp:913)
[10] openttd              0x000000000055958F WinMain + 239 (/home/jgr/openttd/cross-win64/src/os/windows/win32.cpp:447)
[11] openttd              0x00000000004013ED __tmainCRTStartup + 573 (/build/mingw-w64-_1w3Xm/mingw-w64-4.0.4/mingw-w64-crt/crt/crtexe.c:332)
[12] openttd              0x00000000004014FB WinMainCRTStartup + 27 (/build/mingw-w64-_1w3Xm/mingw-w64-4.0.4/mingw-w64-crt/crt/crtexe.c:184)
[13] KERNEL32             0x00007FF8D4603034 BaseThreadInitThunk + 20
[14] ntdll                0x00007FF8D6881551 RtlUserThreadStart + 33

*** End of additional info ***