JGR's Patch Pack

[wallyweb]

You should change the category to "expert" to show all settings.

That's it! Thanks.

Edit: I've moved them to the advanced category now.

Does this mean that I am no longer an expert?

[ISA]

JGR thanks for the fix! All running fine now
One little problem tough and I'm not sure its related Your patch pack.
After update I cant build waypoints in \ direction (see picture below). Other way around its all okay.

This seems to be a known issue https://github.com/OpenTTD/OpenTTD/pull ... -141317975, I'll see about applying a fix soonish.

Edit: Fix applied

Thanks again!

[michael blunck]

[bridges over stations]
NMF introduces a new property "bridge height" (prop 1B). It defines minimum clearances required for a bridge for each tile type of this station (or zero to not allow any bridge).

I can look into implementing something equivalent to this.
That said, the property doesn't appear to be in the spec. What is to stop there being a ID collision when trunk decides to add an unrelated station property, which would most likely also be numbered 1B?

It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.

Other than this, since 2013 there hasn´t been any new property added for stations in trunk. Last one was prop1A (advanced sprite layout, still "to be documented").

Since the next free property number was "1B", this one had been chosen by cirdan. Or would you prefer a different one?

I'm keen to avoid creating compatibility problems for myself in the future, especially when it comes to problematic areas like NewGRFs.

But then again, why introduce a problematic feature (bridges over stations) without allowing for the needed framework to ensure proper functionality for newgrfs? Given the fact, that station newgrfs are heavily being used?


BTW, at that time, cirdan implemented another proposal for stations in NMF:

The second feature request (disallow station building for certain track types) seems to be a much easier task IMO. There is already a note in the code (in newgrf_station.cpp):

Code: Select all

case 0x42: return 0;                // Rail type (XXX Get current type from GUI?)

because, at that point, the railtype of the station tile to be built is already known, and could be made avalailable to CB 13 (in var10 or var18, as the station isn´t built yet).

In fact, available vars for CB13 are totally unspecified in the nfo/grf specs, and I think ATM only the current date could be used here. Now, with OTTD´s railtype feature available since years, it doesn´t make sense to have the same station graphics available for every railtype. Being able to check station availability with regards to the current railtype would be very helpful here, both for the coder and the player, in linking special stations with fitting rail types.

The attached patch should do what you want, I think. It should make variable 42 return the railtype for stationless station resolution (as in the GUI or just before building a station).

In case this isn´t already included in your patch (I can´t check it ATM), could you please include that check for var42?

regards
Michael

[Emperor Jake]

Thanks for letting me know about these, they are fixed and will be in the next release.

Thanks for the quick fix, I'm pretty sure the different crashes were caused by the same issue

I notice now though that it is possible to build bridges over airports, which seems a bit daft. That should be fixed shortly..

Awww. That could have made for some interesting April 1 scenarios.

I'll enjoy it while I can (although for some reason they disappear when on an airport - on the other hand docks and road stations work great)

airport bridges.PNG (118.08 KiB) Viewed 2643 times

But then again, why introduce a problematic feature (bridges over stations) without allowing for the needed framework to ensure proper functionality for newgrfs? Given the fact, that station newgrfs are heavily being used?

I'm in favour of leaving it up to the discretion of the player whether it looks good or not. It wouldn't make sense in a trunk release but it does here, especially for the more advanced playerbase who use patchpacks with experimental features and newGRFs. This leaves it compatible with older NewGRFs which won't ever be updated to support the new feature, and also allows creators to enable the new property to prevent glitches.

[JGR]

It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.

Other than this, since 2013 there hasn´t been any new property added for stations in trunk. Last one was prop1A (advanced sprite layout, still "to be documented").

Since the next free property number was "1B", this one had been chosen by cirdan. Or would you prefer a different one?

I'm keen to avoid creating compatibility problems for myself in the future, especially when it comes to problematic areas like NewGRFs.

But then again, why introduce a problematic feature (bridges over stations) without allowing for the needed framework to ensure proper functionality for newgrfs? Given the fact, that station newgrfs are heavily being used?

If the user turns on the setting and then creates a high station under a low bridge, it is the user's responsibility, and other than it looking bad, nothing untoward will happen.

If you as a NewGRF author and I as a patchpack developer agree to use property 1B (or some other free ID) to mean one thing, if later on trunk (or an unrelated patchpack) decide to use that ID to mean something else, the GRF which uses the private meaning of the property could malfunction potentially quite badly when loaded in the newer trunk/other patchpack, in the worst possible case causing crashes or game-breaking behaviour.
In my patchpack I would then have to either give up on using the property for the privately agreed meaning, or try to implement some heuristics magic to infer whether the NewGRF author meant the meaning in the spec, or the privately agreed meaning.

Probably the easiest solution is to document it as "reserved but not implemented (in trunk)" in the same way as property 19.
I don't know who is the NewGRF spec gatekeeper these days.

BTW, at that time, cirdan implemented another proposal for stations in NMF:

The second feature request (disallow station building for certain track types) seems to be a much easier task IMO. There is already a note in the code (in newgrf_station.cpp):

Code: Select all

case 0x42: return 0;                // Rail type (XXX Get current type from GUI?)

because, at that point, the railtype of the station tile to be built is already known, and could be made avalailable to CB 13 (in var10 or var18, as the station isn´t built yet).

In fact, available vars for CB13 are totally unspecified in the nfo/grf specs, and I think ATM only the current date could be used here. Now, with OTTD´s railtype feature available since years, it doesn´t make sense to have the same station graphics available for every railtype. Being able to check station availability with regards to the current railtype would be very helpful here, both for the coder and the player, in linking special stations with fitting rail types.

The attached patch should do what you want, I think. It should make variable 42 return the railtype for stationless station resolution (as in the GUI or just before building a station).

In case this isn´t already included in your patch (I can´t check it ATM), could you please include that check for var42?

regards
Michael

It isn't implemented in my patchpack at present, but it seems reasonable, and ought to not cause regressions. I will look into it.

[Eddi]

there is no reason why the newgrf specs should solely represent the status of trunk.

there are a lot of features that are in the specs, but were never implemented in OpenTTD

just be careful it doesn't turn into a wishlist.

[michael blunck]

there is no reason why the newgrf specs should solely represent the status of trunk.

I´m with Eddi here.

Probably the easiest solution is to document it as "reserved but not implemented (in trunk)" in the same way as property 19.

Yes, of course it needs to be documented. Could somebody please do it then?

I don't know who is the NewGRF spec gatekeeper these days.

I have seen different people making additions/modifications to the specs over the last years. In the end "it´s a Wiki!".

I'm in favour of leaving it up to the discretion of the player whether it looks good or not. [...] This leaves it compatible with older NewGRFs which won't ever be updated to support the new feature, and also allows creators to enable the new property to prevent glitches.

Obviously, "older" newGRFs had been designed under the prerequisite that stations couldn´t be built under bridges (or bridges over stations). There´s no need to question it now. OTOH, the implementation of a new feature which could break it (even "only" visually) should be assisted by means to ensure proper functionality of said feature. At least that would be common behaviour.

regards
Michael

[randomallfront]

I'll take a look into this, thanks for the bug report.

Edit: It appears to be caused by the change in https://github.com/OpenTTD/OpenTTD/pull/6763
Note point 1 in the "So what it actually changes" section.
Probably this is something to raise with the GS developers, if you need town growth rates slower than 880 days per growth event.

I see. Well what can I say, I'm a patient gamer. And renewable city growth works really well when averaging values ranging from 72 to 6000, especially with games starting in the late 18th century. Its a shame, but thank you for looking into it!

[MagicBuzz]

Hello,

I think I found an issue with timetable and especially separation patch.

On long routes (about 50 000 ticks to complete) I often have trains with an enormous early timer instead of being a bit late.

After a very quick look in the code (not actually in the involved code, but some random lines about timetable and late counter) I found some strange types used.


The Ticks type is an alias of int32.

2147483647 ticks for a timetable is very enougth. Even for a complete game I guess.


But when I look at timetable computing, other types are involved :

Code: Select all

this->timetable_duration += o->GetTimetabledWait() + o->GetTimetabledTravel();

GetTimetabledWait() returns a uint16, so 65536 as max value.
GetTimetabledTravel() returns a uint16 too.

So if there is more 65536 ticks between two orders, there will be an overflow. And when computing lateness or separation, the whole table length is analyzed, so if using uint16 where will be problems.

Thus, I'm not sure, but when doing some subtraction between uint16, the values might be casted to int16 before calculation in order to handle properly negative values.

Vehicle lateness_counter is a int32.

I don't know exactly what happens and where, but I'm almost sure there is an overflow somewhere.

In any case, IMHO all time related variables and properties should be expressed in Ticks rather than int32, uint16, etc.

Here is a save game with the problem.

[eshield]

Hello, JGR.

I've noticed few issues with 0.26.0win:
1. Entire game is lagging and stutters on mouse move. 0.25.2 does not have such issue. Re-tested 3 times on 3 diff PC (not VM). Video: https://drive.google.com/file/d/11KJbPy ... xl4YT/view
2. Fails to load a save game provided by me in this post.


Tested on freshly installed Win10x64 1803.

[FulliAutomatix]

I've been getting some crashes on a multiplayer server, all come up with "signal.cpp" and it's been hindering playing multiplayer as the save now just crashes about a minute after loading and I don't know why.
We've also been having an issue where you can't place waypoings on the NW-SE axis for some reason, so we've been using stations with "go via non-stop" orders. Waypoints on NE-SW axis have been fine though.
I hope this helps in some way or another

Here's the crash log and the save.

[+] Spoiler

*** OpenTTD Crash Report ***

Crash at: Tue Jul 31 10:40:08 2018
In game date: 2050-02-01 (0, 0)

Crash reason:
Exception: E1212012
Location: 000007FEFCE1A06D
Message: Assertion failed at line 797 of /home/jgr/openttd/cross-win64/src/signal.cpp: _globset.IsEmpty()

Within context:
0: DeleteVisibleTrain: veh: 1019: (INVALID PTR: 0000000009aaaf60)
1: DoCommandP: tile: 0 (0 x 0), p1: 0x50002, p2: 0x2, company: 5 (GWR ), cmd: 0x151 (CmdCompanyCtrl), my_cmd: 1

OpenTTD version:
Version: jgrpp-0.26.0 (0)
NewGRF ver: 19006d64
Bits: 64
Endian: little
Dedicated: no
Build date: Jul 27 2018 08:22:43
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:
00000016 00000000 00000000 00000000 00000008 00000000 00000000 00000000
E1212012 00000000 00000000 00000000 FCE1A06D 000007FE 00000000 000007FE
00000009 57DE7DC0 76CC1352 00000000 00012010 00000000 00000130 000007FE
00000000 00000000 0000002C 00000000 00000000 00000000 FFFFFFFF 000007FE
00012010 00000000 76EC141A 00000000 00012010 00000000 957DE7DC 00000000
0022C958 00000000 0000002C 00000000 00000000 00000000 FEC705E9 000007FE
00000001 00000000 FEC91925 000007FE 00000016 00000000 957DE7DC 00000000
FECE5180 000007FE 01E987A0 00000000 00000003 00000000 76EBBC9A 00000000
FECE6180 000007FE 00000314 00000000 00DA6A48 00000000 00000040 00000000
00000040 00000000 01E987A0 00000000 00DA6A48 00000000 FEC953AA 000007FE
00000001 00000000 0022CFB0 00000000 00372A17 00000000 00DA6A48 00000000
0393BEE0 00000000 038E0230 00000000 00000000 00000000 00000000 00000000
76EC6988 00000000 00000001 00000000 0022CA58 00000000 24000024 00000003
76C5CB3A 00000000 76C69059 00000000 03D6FFE8 00000000 0022CA88 00000000
00000000 00000000 A10006A7 00000000 00000082 00000000 00000000 00000000
00000000 00000000 00000000 00000000 76EC6BA8 00000000 76C7505B 00000000
00000000 00000000 02000002 00000000 00000001 00000000 00000001 00000000
00000001 00000000 A70A0321 FFFFFFFF 000B0318 00000000 00000202 00000000
00000000 00000000 000C0021 00000000 0000001B 00000000 00000195 00000000
00000000 00000000 00000000 00000000 76C50000 00000000 039353D0 00000000
00000000 00000000 76C74ED1 00000000 00000000 00000000 76CC3448 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000003 00000000 00000010 00000000 00010007 00000000 00000001 00000000
039353D0 00000000 76CC29A9 00000000 038E0000 00000000 FFFFFF01 FFFFFFFF

Registers:
RAX: 000000007E19130A RBX: 0000000000000016 RCX: 000000000022C280 RDX: 0000000000000000
RSI: 0000000000000000 RDI: 0000000000000008 RBP: 0000000000000000 RSP: 000000000022C890
R8: 0000000000000000 R9: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286
R12: 000007FEFECE1130 R13: 000000000055D210 R14: 0000000000000001 R15: 0000000000000314
RIP: 000007FEFCE1A06D EFLAGS: 00000206

Bytes at instruction pointer:
48 81 C4 C8 00 00 00 C3 90 90 90 90 90 90 90 90 90 90 90 48 83 EC 28 65

Operating system:
Name: Windows
Release: 6.1.7601 (Service Pack 1)
Compiler: GCC 5.3.1 "5.3.1 20160211"

Configuration:
Blitter: null
Graphics set: OpenGFX (5580)
Language: C:\Servers\OpenTTD Patch Pack\lang\english.lng
Music driver: null
Music set: OpenMSX (96)
Network: server
Sound driver: null
Sound set: OpenSFX (87)
Video driver: dedicated

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

Map size: 0x400000 (2048 x 2048)

AI Configuration (local: 255) (current: 5):
0: Human
1: Human
2: Human
3: Human
4: Human
5: Human
6: Human
7: Human
8: Human

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

Module information:
C:\Servers\OpenTTD Patch Pack\openttd.exe handle: 0000000000400000 size: 40786292 crc: 3B4FB2D0 date: 2018-07-27 07:24:01
C:\Windows\SYSTEM32\ntdll.dll handle: 0000000076e70000 size: 1665344 crc: E11DD72B date: 2018-06-08 16:22:54
C:\Windows\system32\kernel32.dll handle: 0000000076d50000 size: 1163264 crc: 11F5C09B date: 2018-06-08 16:20:22
C:\Windows\system32\KERNELBASE.dll handle: 000007fefce00000 size: 419840 crc: B67E14FC date: 2018-06-08 16:20:22
C:\Windows\system32\ADVAPI32.dll handle: 000007fefe3b0000 size: 880640 crc: 35A1C26A date: 2018-06-08 16:18:42
C:\Windows\system32\msvcrt.dll handle: 000007fefec50000 size: 634880 crc: 9D1B448A date: 2011-12-16 08:46:06
C:\Windows\SYSTEM32\sechost.dll handle: 000007fefec20000 size: 113664 crc: 978CFAE5 date: 2009-07-14 01:41:53
C:\Windows\system32\RPCRT4.dll handle: 000007fefd260000 size: 1211904 crc: 4B255610 date: 2018-06-08 16:20:45
C:\Windows\system32\GDI32.dll handle: 000007fefe5f0000 size: 405504 crc: DA49854F date: 2017-09-08 15:30:44
C:\Windows\system32\USER32.dll handle: 0000000076c50000 size: 1009152 crc: 69D3286F date: 2016-11-10 16:32:41
C:\Windows\system32\LPK.dll handle: 000007fefe490000 size: 41472 crc: AD98949B date: 2018-03-09 18:07:21
C:\Windows\system32\USP10.dll handle: 000007fefe4a0000 size: 806912 crc: 0E85A76E date: 2017-08-16 15:29:31
C:\Windows\system32\IMM32.dll handle: 000007fefe5c0000 size: 167424 crc: 41B2805A date: 2009-07-14 01:41:09
C:\Windows\system32\MSCTF.dll handle: 000007fefe930000 size: 1068544 crc: 23BC0724 date: 2017-09-13 15:28:01
C:\Windows\system32\ole32.dll handle: 000007fefcf00000 size: 2066432 crc: 702B949C date: 2018-06-08 16:20:40
C:\Windows\system32\SHELL32.dll handle: 000007fefd390000 size: 14185984 crc: 69B01066 date: 2018-06-13 16:20:34
C:\Windows\system32\SHLWAPI.dll handle: 000007fefd100000 size: 448512 crc: 086DF743 date: 2010-11-21 03:24:22
C:\Windows\system32\WINMM.dll handle: 000007fefa5f0000 size: 217600 crc: 7BC1529F date: 2009-07-14 01:41:56
C:\Windows\system32\WS2_32.dll handle: 000007fefe570000 size: 296448 crc: EE1BC529 date: 2016-05-11 17:02:50
C:\Windows\system32\NSI.dll handle: 000007fefec40000 size: 13312 crc: C65F00AA date: 2017-08-11 06:35:01
C:\Windows\system32\mswsock.dll handle: 000007fefc2d0000 size: 327168 crc: 2E4865A8 date: 2016-05-11 17:02:42
C:\Windows\System32\wshtcpip.dll handle: 000007fefba90000 size: 13312 crc: 5D1E2C55 date: 2009-07-14 01:41:58
C:\Windows\System32\wship6.dll handle: 000007fefc2c0000 size: 13824 crc: E3FBF123 date: 2009-07-14 01:41:58
C:\Windows\system32\DNSAPI.dll handle: 000007fefc150000 size: 357888 crc: 3F7840AD date: 2018-06-08 16:19:35
C:\Windows\system32\IPHLPAPI.DLL handle: 000007fef9c20000 size: 145920 crc: 000D9F17 date: 2010-11-21 03:24:16
C:\Windows\system32\WINNSI.DLL handle: 000007fef9c10000 size: 25600 crc: 81C33575 date: 2017-08-11 06:35:06
C:\Windows\System32\fwpuclnt.dll handle: 000007fef95a0000 size: 324096 crc: 8B6CFD3A date: 2018-01-01 02:18:20
C:\Windows\system32\rasadhlp.dll handle: 000007fef73e0000 size: 16384 crc: C5FD1616 date: 2009-07-14 01:41:53
C:\Windows\system32\CRYPTBASE.dll handle: 000007fefc9e0000 size: 43520 crc: 72375646 date: 2018-06-08 16:19:20
C:\Windows\system32\psapi.dll handle: 0000000077020000 size: 9216 crc: 84B5E9BA date: 2009-07-14 01:41:53

---- gamelog start ----
Tick 0: new game started
Revision text changed to jgrpp-0.25.2, savegame version 198, not modified, _openttd_newgrf_version = 0x19000000
New game mode: 2 landscape: 1
Added NewGRF: GRF ID 4F472B34, checksum 136D889FDAEAA3491F8320248A04425C, filename: opengfx_landscape-1.1.2\ogfx-landscape.grf (md5sum matches)
Added NewGRF: GRF ID 504A5143, checksum 7E018F7AB3A045ACBED32E2932883516, filename: qatenary-0.1\qatenary_v0_1.grf (md5sum matches)
Added NewGRF: GRF ID 44442303, checksum 90300B85C4DE1DD192691827B054522D, filename: uk_railway_set_tracks-2.0\pb_trax.grf (md5sum matches)
Added NewGRF: GRF ID 52554B54, checksum D513D5491DDDC372EF69B555292A7BA0, filename: representitive_uk_trainset-0.3.0\rukts.grf (md5sum matches)
Added NewGRF: GRF ID 444410C1, checksum 8196125601AFC0328257C1A8C6012EC0, filename: uk_revival_set_ukrs3-200\sunshine.grf (md5sum matches)
Added NewGRF: GRF ID 44441000, checksum DA36131A815D2D5FC158C7A27D67B5AF, filename: ukrs2__the_uk_railway_set-1.05\proj1000.grf (md5sum matches)
Added NewGRF: GRF ID 44441001, checksum 83915879F68DD174C953868C0629A4C9, filename: ukrs2_uk_railway_addon_set-gobi\pj1kadd.grf (md5sum matches)
Added NewGRF: GRF ID 44441002, checksum 6B0A40195BB5B54E6FBDF9E47A7FEC1C, filename: faster_ukrs2_express_car-1\fueceap.grf (md5sum matches)
Added NewGRF: GRF ID 4D420100, checksum 1A5D28D0719FCDB928F59AEFDBE07B7C, filename: bobs_british_buses-0.2.1\bbbw.grf (md5sum matches)
Added NewGRF: GRF ID 58534453, checksum 2E100BCA91DB8371CD9D57DBEC3AB0C8, filename: dutch_stations_set-1.0.0alpha\dutchstatw.grf (md5sum matches)
Added NewGRF: GRF ID 504A0110, checksum E8244C5278CB2408A818854DC11F8940, filename: dutch_station_addition_set-0.8\dstatadd_v0_8.grf (md5sum matches)
Added NewGRF: GRF ID 504A0112, checksum 80D0B8699A417CC03CD06BC74E8796D0, filename: dutch_station_addition_part_2-0.4\dstatadd_part2_v0_4.grf (md5sum matches)
Added NewGRF: GRF ID 504A0113, checksum 0B65D0779D65427BC135FC624278FEA3, filename: dutch_station_addition_part_3-001\dstatadd_part3_v001.grf (md5sum matches)
Added NewGRF: GRF ID 535A0224, checksum 69B70AE56EEB9310B62A8A93AD6A4500, filename: speed_for_suspension_bridges-v1\susp_brg.grf (md5sum matches)
Added NewGRF: GRF ID 414E0101, checksum 5D665C64693A438E3046C22666F46E08, filename: fish_ship_set-0.9.2\fish.grf (md5sum matches)
Added NewGRF: GRF ID 72777473, checksum EBEAB33B398DE7F2921F853C496F6F91, filename: uk_town_set-2.2\ukts_2.2.grf (md5sum matches)
Added NewGRF: GRF ID 504E0001, checksum E7781323D2B0086E2E76342DAA036054, filename: uk_waypoints-1\ukwaypointsw.grf (md5sum matches)
Added NewGRF: GRF ID FBFB9905, checksum F747797A14AAA646402DC4E16DE5E82C, filename: longer_girder__steel_bridge.1\longergirdersteelbridge.grf (md5sum matches)
Added NewGRF: GRF ID 4642FB21, checksum 117F6F1F07C18A9C15ADC6127AFBAE97, filename: modern_tram_set-3.1\motraset_r3.1.grf (md5sum matches)
Added NewGRF: GRF ID FE16215C, checksum 69D13699AC16604E825F7657E6AACA72, filename: city_tram_set-b02\cts02.grf (md5sum matches)
Added NewGRF: GRF ID 43415000, checksum 4DA9FE9A87DD330EBAD43916771BAF21, filename: opengfx_airports-0.4.2\ogfx-airports.grf (md5sum matches)
Added NewGRF: GRF ID 4C530301, checksum F1BD2B034BAFB1041071447AE952B208, filename: brick_tram_depot-1.0.0\bricktramdepot.grf (md5sum matches)
Added NewGRF: GRF ID 686D6301, checksum ECFF8464F08FD6772E7A133C46FA43F2, filename: more_british_town_names-1.0\morebritishtownnames_1.grf (md5sum matches)
Added NewGRF: GRF ID 4D635769, checksum F5886B56AD955607AFD19C43187A0FEA, filename: wired-1.1\wired.grf (md5sum matches)
Added NewGRF: GRF ID 4A4D0101, checksum AFE4E75999A3FF92D4B01DBEE9A803E9, filename: sailing_ships-0.62\ss.grf (md5sum matches)
Added NewGRF: GRF ID 554B5201, checksum 0D9C15FF1DC9AA50702780A730D9C650, filename: uk_roadset.1.1\ukroadsetw.grf (md5sum matches)
Added NewGRF: GRF ID 4A4B0501, checksum 018B81283FF5710BFC102AA1FD823787, filename: total_bridge_renewal_set_ukrs-1.0.0\total_bridges.grf (md5sum matches)
Added NewGRF: GRF ID 4A430002, checksum 93EAC5F5396584B92D4C5F0AAAF3F6C5, filename: industrial_stations_renewal-1.0.2\indstatr.grf (md5sum matches)
Added NewGRF: GRF ID 4D420000, checksum BCB0AC917F3DA91A3197C6A07D06BCE8, filename: bobs_random_vehicles_-0.9\brbvw.grf (md5sum matches)
Added NewGRF: GRF ID 504A0107, checksum 92B822D319E71F920908801AD5751D26, filename: beach_objects-1.2\beach_v1_2.grf (md5sum matches)
Added NewGRF: GRF ID 0100403A, checksum 26B8CB3E29FA6DAD15DFE2F08F0BF1ED, filename: city_objects-b08.1\co08.1.grf (md5sum matches)
Added NewGRF: GRF ID 424B5462, checksum 83FE5AA7CAFF0A307B44B297F2A259D6, filename: bk_enhanced_tunnel_set-1.0\bktunw.grf (md5sum matches)
Added NewGRF: GRF ID 4A44E801, checksum 36E1A192D8DE7D70C6F39B7C591C8D5C, filename: invisible_leading_engine-0.21\blank-engine.grf (md5sum matches)
Added NewGRF: GRF ID 44442411, checksum E6A38D0DC67DE54DD2928447BB72F924, filename: tai_uk_houses-gamma1\tai_uk.grf (md5sum matches)
Added NewGRF: GRF ID 504A5457, checksum D795341420C564012E262FAB630018C5, filename: town_walls_objects-0.1\townwalls_v0_1.grf (md5sum matches)
Added NewGRF: GRF ID FBFB0501, checksum 60082E7DF1D3976274AB86843C3E07B2, filename: dutch_road_furniture-0.7.1\dutchroadfurniture.grf (md5sum matches)
Added NewGRF: GRF ID FBFB0502, checksum 55AE61673CBCDE4A7231DEA85973278C, filename: dutch_road_furn._uk_signs_addon-1.0.0\dutchroadfurnitureuksignsaddon.grf (md5sum matches)
Added NewGRF: GRF ID 4D42000A, checksum F8E5047F895179305042A6AB83EF46A6, filename: bats-0.7\batsv0.7w.grf (md5sum matches)
Added NewGRF: GRF ID 304FE908, checksum F7BCFC491F02F1EDC2D47B28EE2E91D8, filename: city_hqs-rb\chq01.grf (md5sum matches)
Added NewGRF: GRF ID 504A0103, checksum 7040A4DC88302927794941CD853A47CF, filename: isrstyle_dock-1.4\isrdock_v1_4.grf (md5sum matches)
Added NewGRF: GRF ID 504A0013, checksum E2FB4F9E66207F8016B7303323FDD00C, filename: isrdwestyle_objects-1.0\isrdwe_objects_v1_0.grf (md5sum matches)
Added NewGRF: GRF ID 504A4641, checksum 457DE3A141B99D6BE258981C993B6761, filename: fake_airport_objects-0.1\fakeairportobjects_v0_1.grf (md5sum matches)
Added NewGRF: GRF ID 57A50001, checksum 318F3C3F17CA68EAD533BAC88B093094, filename: was_world_airliners_set-0.1\was.grf (md5sum matches)
Added NewGRF: GRF ID 4D656F91, checksum 945EFBE06B03EC2AC3598EA578B969C0, filename: ecs_town_vector-1.219feb2012\ecstown.grf (md5sum matches)
Added NewGRF: GRF ID 4D656F9F, checksum 357601291B0DD95B8FEF49A6A7A7F9DE, filename: ecs_basic_vector_ii-1.219feb2012\ecsbas2.grf (md5sum matches)
Added NewGRF: GRF ID 4D656F95, checksum 6F5472D7F2F3F9236AAFE7A81DF9AE84, filename: ecs_wood_vector-1.219feb2012\ecswood.grf (md5sum matches)
Added NewGRF: GRF ID 4D656F9C, checksum 833CD4C1C7E2C0E9AABA35FCE7B6A9BB, filename: ecs_chemical_vector_ii-1.219feb2012\ecschem2.grf (md5sum matches)
Added NewGRF: GRF ID 4D656F97, checksum B73EA6BCD8DCAE4151EEC0C93DBF3073, filename: ecs_agricultural_vector-1.219feb2012\ecsagri.grf (md5sum matches)
Added NewGRF: GRF ID 4D656F96, checksum 682C2B4B460032782186BF03AE2C156C, filename: ecs_construction_vector-b527dec2010\ecsconstw.grf (md5sum matches)
Added NewGRF: GRF ID 52544E41, checksum 8688D02E69049A3D8A57819F995D8226, filename: rukts__extension-1.0.0\ruktsnma.grf (md5sum matches)
Added NewGRF: GRF ID 4D4D9910, checksum 3CD3F4D0D98DDC0DB08E9AD74B88A9E2, filename: the_lighthouse_set-1.2\the_lighthouse_set_v1.2.grf (md5sum matches)
Added NewGRF: GRF ID 535A4002, checksum 246CC1DCDF2994AB930E521A6008B56C, filename: famous_cars-33\famouscars.grf (md5sum matches)
Added NewGRF: GRF ID 535A4005, checksum FD19731D859D1C2140BFE483C19F5F84, filename: cars_cars-76\carscars.grf (md5sum matches)
Added NewGRF: GRF ID 535A4004, checksum 5F492AFD485EA548187863D845F2FB0E, filename: racing_cars-27\racingcars.grf (md5sum matches)
Added NewGRF: GRF ID 535A4003, checksum C4EAA6F0C65868F01A63AFD0A46B942B, filename: super_cars-39\supercars.grf (md5sum matches)
Tick 1280: GRF config changed
GRF parameter changed: GRF ID 4F472B34, filename: opengfx_landscape-1.1.2\ogfx-landscape.grf (md5sum matches)
Tick 1280: game loaded
Revision text changed to jgrpp-0.26.0, savegame version 200, not modified, _openttd_newgrf_version = 0x19006d64
New game mode: 1 landscape: 1
---- gamelog end ----

Recent news messages:
(2050-01-08) StringID: 667, Type: 4, Ref1: 4, 1736, Ref2: 0, 4294967295
(2050-02-01) StringID: 134307, Type: 9, Ref1: 4, 202, Ref2: 0, 4294967295
(2050-02-01) StringID: 134137, Type: 8, Ref1: 4, 1288, Ref2: 0, 4294967295
(2050-02-01) StringID: 634, Type: 3, Ref1: 0, 4294967295, Ref2: 0, 4294967295

Command Log:
Showing most recent 20 of 20 commands
0 | 2050-02-01, 0, 0 | -ms---- | 0 x 0, p1: 0x00050002, p2: 0x00000002, cc: 16, lc: 255, cmd: 0x00000051 (CmdCompanyCtrl)
1 | 2050-01-21, 27, 0 | ------- | 1619 x 1208, p1: 0x0025CE53, p2: 0x000000C1, cc: 1, lc: 255, cmd: 0x10D10100 (CmdBuildRailroadTrack)
2 | 2050-01-21, 15, 0 | ------- | 1620 x 1208, p1: 0x00000001, p2: 0x00000000, cc: 1, lc: 255, cmd: 0x10D10102 (CmdBuildSingleRail)
3 | 2050-01-21, 8, 1 | ------- | 1621 x 1208, p1: 0x00000001, p2: 0x00000005, cc: 1, lc: 255, cmd: 0x10D10102 (CmdBuildSingleRail)
4 | 2050-01-21, 0, 1 | ------- | 1621 x 1209, p1: 0x00000001, p2: 0x00000001, cc: 1, lc: 255, cmd: 0x10D10102 (CmdBuildSingleRail)
5 | 2050-01-20, 69, 1 | ------- | 1621 x 1210, p1: 0x00000001, p2: 0x00000002, cc: 1, lc: 255, cmd: 0x10D10102 (CmdBuildSingleRail)
6 | 2050-01-20, 42, 1 | ------- | 1620 x 1210, p1: 0x00000001, p2: 0x00000000, cc: 1, lc: 255, cmd: 0x10D10102 (CmdBuildSingleRail)
7 | 2050-01-01, 0, 1 | -m----- | 0 x 0, p1: 0x00000010, p2: 0x00000000, cc: 255, lc: 255, cmd: 0x0000013E (CmdPause)
8 | 2050-01-01, 0, 1 | -m----- | 0 x 0, p1: 0x00000004, p2: 0x00000000, cc: 255, lc: 255, cmd: 0x0000013E (CmdPause)
9 | 2050-01-01, 0, 1 | -ms---- | 0 x 0, p1: 0x00000010, p2: 0x00000000, cc: 255, lc: 255, cmd: 0x0000003E (CmdPause)
10 | 2050-01-01, 0, 1 | -ms---- | 0 x 0, p1: 0x00000004, p2: 0x00000000, cc: 255, lc: 255, cmd: 0x0000003E (CmdPause)
11 | 2050-01-01, 0, 1 | -m----- | 0 x 0, p1: 0x00000004, p2: 0x00000001, cc: 255, lc: 255, cmd: 0x0000013E (CmdPause)
12 | 2050-01-01, 0, 1 | -ms---- | 0 x 0, p1: 0x00000004, p2: 0x00000001, cc: 255, lc: 255, cmd: 0x0000003E (CmdPause)
13 | 2050-01-01, 0, 1 | -m----- | 0 x 0, p1: 0x00000010, p2: 0x00000001, cc: 255, lc: 255, cmd: 0x0000013E (CmdPause)
14 | 2050-01-01, 0, 1 | -m----- | 0 x 0, p1: 0x00000010, p2: 0x00000001, cc: 255, lc: 255, cmd: 0x0000013E (CmdPause)
15 | 2050-01-01, 0, 1 | -ms---- | 0 x 0, p1: 0x00000010, p2: 0x00000001, cc: 255, lc: 255, cmd: 0x0000003E (CmdPause)
16 | 2050-01-01, 0, 0 | -m----- | 0 x 0, p1: 0x00000002, p2: 0x00000000, cc: 255, lc: 255, cmd: 0x0000013E (CmdPause)
17 | 2050-01-01, 0, 0 | -m----- | 0 x 0, p1: 0x00000001, p2: 0x00000000, cc: 255, lc: 255, cmd: 0x0000013E (CmdPause)
18 | 2050-01-01, 0, 0 | -ms---- | 0 x 0, p1: 0x00000010, p2: 0x00000001, cc: 255, lc: 255, cmd: 0x0000003E (CmdPause)
19 | 2050-01-01, 0, 0 | -ms---- | 0 x 0, p1: 0x00000002, p2: 0x00000000, cc: 255, lc: 255, cmd: 0x0000003E (CmdPause)

*** End of OpenTTD Crash Report ***

Decoded stack trace:
[00] KERNELBASE 0x000007FEFCE1A06D RaiseException + 61
[01] msvcrt 0x000007FEFEC91925 raise + 565
[02] msvcrt 0x000007FEFEC953AA abort + 46
[03] openttd 0x000000000054D01F error(char const*, ...) + 95 (/home/jgr/openttd/cross-win64/src/openttd.cpp:133)
[04] openttd 0x000000000060703F UpdateSignalsOnSegment(unsigned int, DiagDirection, Owner) + 79 (/home/jgr/openttd/cross-win64/src/signal.cpp:797)
[05] openttd 0x0000000000667575 DeleteVisibleTrain(Train*) + 853 (/home/jgr/openttd/cross-win64/src/train_cmd.cpp:5066)
[06] openttd 0x0000000000483E3F ChangeOwnershipOfCompanyItems(Owner, Owner) + 2319 (/home/jgr/openttd/cross-win64/src/economy.cpp:412)
[07] openttd 0x000000000046CEEF CmdCompanyCtrl(unsigned int, DoCommandFlag, unsigned int, unsigned int, char const*) + 367 (/home/jgr/openttd/cross-win64/src/company_cmd.cpp:904)
[08] openttd 0x0000000000469180 DoCommandPInternal(unsigned int, unsigned int, unsigned int, unsigned int, void (*)(CommandCost const&, unsigned int, unsigned int, unsigned int), char const*, bool, bool, unsigned int) + 688 (/home/jgr/openttd/cross-win64/src/command.cpp:931)
[09] openttd 0x0000000000469E90 DoCommandP(unsigned int, unsigned int, unsigned int, unsigned int, void (*)(CommandCost const&, unsigned int, unsigned int, unsigned int), char const*, bool, unsigned int) + 368 (/home/jgr/openttd/cross-win64/src/command.cpp:779)
[10] openttd 0x000000000046A2C7 DoCommandP(CommandContainer const*, bool) + 55 (/home/jgr/openttd/cross-win64/src/command.cpp:727)
[11] openttd 0x00000000005078FF NetworkExecuteLocalCommandQueue() + 143 (/home/jgr/openttd/cross-win64/src/network/network_command.cpp:227)
[12] openttd 0x0000000000501A53 NetworkGameLoop() + 259 (/home/jgr/openttd/cross-win64/src/network/network.cpp:1018)
[13] openttd 0x0000000000550EE1 GameLoop() + 161 (/home/jgr/openttd/cross-win64/src/openttd.cpp:1666)
[14] openttd 0x0000000000696905 VideoDriver_Dedicated::MainLoop() + 469 (/home/jgr/openttd/cross-win64/src/video/dedicated_v.cpp:307)
[15] openttd 0x000000000054EA55 openttd_main(int, char**) + 5493 (/home/jgr/openttd/cross-win64/src/openttd.cpp:923)
[16] openttd 0x00000000005619BF WinMain + 239 (/home/jgr/openttd/cross-win64/src/os/windows/win32.cpp:447)
[17] openttd 0x00000000004013ED __tmainCRTStartup + 573 (/build/mingw-w64-_1w3Xm/mingw-w64-4.0.4/mingw-w64-crt/crt/crtexe.c:332)
[18] openttd 0x00000000004014FB WinMainCRTStartup + 27 (/build/mingw-w64-_1w3Xm/mingw-w64-4.0.4/mingw-w64-crt/crt/crtexe.c:184)
[19] kernel32 0x0000000076D659CD BaseThreadInitThunk + 13
[20] ntdll 0x0000000076EC383D RtlUserThreadStart + 29

*** End of additional info ***

[TrainLover]

Random question, but if I changed all the int variables to longs, does that "increase" the hardcoded limits?

[ino]

Random question, but if I changed all the int variables to longs, does that "increase" the hardcoded limits?

No. First, you need to modify the save/load code to deal with new limits. And there surely will be many code where they assume the limit (I can tell you, for my scheduled dispatch patch, if you increase the Max. Day length factor (currently max is 125) it will definitely have problem due to how data is packed when send to DoCommandP)

[JGR]

Hello,

I think I found an issue with timetable and especially separation patch.

On long routes (about 50 000 ticks to complete) I often have trains with an enormous early timer instead of being a bit late.

After a very quick look in the code (not actually in the involved code, but some random lines about timetable and late counter) I found some strange types used.


The Ticks type is an alias of int32.

2147483647 ticks for a timetable is very enougth. Even for a complete game I guess.


But when I look at timetable computing, other types are involved :

Code: Select all

this->timetable_duration += o->GetTimetabledWait() + o->GetTimetabledTravel();

GetTimetabledWait() returns a uint16, so 65536 as max value.
GetTimetabledTravel() returns a uint16 too.

So if there is more 65536 ticks between two orders, there will be an overflow. And when computing lateness or separation, the whole table length is analyzed, so if using uint16 where will be problems.

Thus, I'm not sure, but when doing some subtraction between uint16, the values might be casted to int16 before calculation in order to handle properly negative values.

Vehicle lateness_counter is a int32.

I don't know exactly what happens and where, but I'm almost sure there is an overflow somewhere.

In any case, IMHO all time related variables and properties should be expressed in Ticks rather than int32, uint16, etc.

Here is a save game with the problem.

I don't think that this is a numeric overflow/type width issue.

It looks to me more like the timetabled wait time at each end times the number of trains is much too large for the number of platforms.
Having trains queueing at one end or the other makes the flow lumpy rather than evenly distributed and causes oscillatory effects.
I think that increasing the number of platforms, reducing the wait time, and/or reducing the number of trains will improve matters.
Adding an intermediary waypoint or two might help as the auto-separation would have a better idea of where trains actually are.

I've been getting some crashes on a multiplayer server, all come up with "signal.cpp" and it's been hindering playing multiplayer as the save now just crashes about a minute after loading and I don't know why.

I hope this helps in some way or another

Here's the crash log and the save

This is fixed now and will be in the next release.

The case where a train was deleted from a signalled tunnel/bridge due to company bankruptcy/deletion wasn't fully correctly implemented.

We've also been having an issue where you can't place waypoings on the NW-SE axis for some reason, so we've been using stations with "go via non-stop" orders. Waypoints on NE-SW axis have been fine though.

That one is fixed already.


[I will respond to the remaining bug reports, soon]

[JGR]

It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.

Other than this, since 2013 there hasn´t been any new property added for stations in trunk. Last one was prop1A (advanced sprite layout, still "to be documented").

Since the next free property number was "1B", this one had been chosen by cirdan. Or would you prefer a different one?

This is not in Cirdan's code, it does not look like he has implemented it, unless he's done so privately and not published it.
I had a quick search on the forums and couldn't find any reference to this.

If there is some existing code that you're aware of it'd be very useful if you could link it so that I could make sure that my implementation is compatible with the existing one (in lieu of documentation which is yet to be written).

The second feature request (disallow station building for certain track types) seems to be a much easier task IMO. There is already a note in the code (in newgrf_station.cpp):

Code: Select all

case 0x42: return 0;                // Rail type (XXX Get current type from GUI?)

because, at that point, the railtype of the station tile to be built is already known, and could be made avalailable to CB 13 (in var10 or var18, as the station isn´t built yet).

In fact, available vars for CB13 are totally unspecified in the nfo/grf specs, and I think ATM only the current date could be used here. Now, with OTTD´s railtype feature available since years, it doesn´t make sense to have the same station graphics available for every railtype. Being able to check station availability with regards to the current railtype would be very helpful here, both for the coder and the player, in linking special stations with fitting rail types.

The attached patch should do what you want, I think. It should make variable 42 return the railtype for stationless station resolution (as in the GUI or just before building a station).

In case this isn´t already included in your patch (I can´t check it ATM), could you please include that check for var42?

regards
Michael

I've added an implementation of this, but it hasn't been tested.
I've partly based it on Cirdan's implementation.

[wallyweb]

This is not in Cirdan's code, it does not look like he has implemented it, unless he's done so privately and not published it.
I had a quick search on the forums and couldn't find any reference to this.

You have a PM.

[p4nzer]

Does the signal routing restrictions patch have an if and only if command? I think it should, if possible.

[vrn]

Does the signal routing restrictions patch have an if and only if command? I think it should, if possible.

You can set 'Deny' at the top level and then explicitly allow special cases. Of course, others may have a different approach to this.

[Auge]

Hello

Does the signal routing restrictions patch have an if and only if command?

You can set 'Deny' at the top level and then explicitly allow special cases.

Thinking it the other way around – and especially the illustrating screenshot – is very helpful for me. Thank you.

Tschö, Auge

[JGR]

It´s not in the spec, because nobody put it there. I would have done it myself, but I seem to be "excluded" from the wiki for some unknown reason.

Other than this, since 2013 there hasn´t been any new property added for stations in trunk. Last one was prop1A (advanced sprite layout, still "to be documented").

Since the next free property number was "1B", this one had been chosen by cirdan. Or would you prefer a different one?

This is not in Cirdan's code, it does not look like he has implemented it, unless he's done so privately and not published it.
I had a quick search on the forums and couldn't find any reference to this.

You have a PM.

This is implemented now as per the new specs in the wiki.

However, there isn't currently a way for GRFs to feature-detect it.

I think that it would be useful to develop a suitable feature detection strategy for this and other/future NewGRF features which may or may not end up in trunk and/or various patchpack(s).
Comparing linear version numbers or using patchpack-specific magic seems a bit unsatisfactory.

Defining some sort of structured versioned feature test mechanism via action 14/CSTM as suggested in the documentation sounds quite doable.
Twiddling variable 8D/9D as a success indicator is a bit more problematic as it doesn't compose very well.
I'm open to thoughts/suggestions on all this.