JGR's Patch Pack

[Gwyd]

I'm not very experienced in the code side of things for OpenTTD, but could a patch pack have a specific GRF in-built in some way that a NewGRF can detect like any other NewGRF. Based on this, the NewGRF could activate or deactivate certain features

[Eddi]

that doesn't seem any more helpful than putting a random number in the code and calling that a "version"

[michael blunck]

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.

What is var A1 being set for your patch(es)?

regards
Michael

[Xaxa]

Oh boy! Bridges on top of train stations, yes! Great step forward for the flexible network I require. Thank you for the implementation!

Ultimately, will there be
Stations on top of stations? (Like stations on top of bridges?)
Stations in tunnels?

Inspirational stations:

[+] Spoiler

Amsterdam Sloterdijk (one of two flying X-stations in the Netherlands):


The other one would be Duivendrecht which is like a really neat cross looking at it from an earial angle.

[+] Spoiler

Triple layered Antwerpen Centraal. The top layers are both terminal. The lower layer for (amongst others) high speeds trains is roro.

I would also love a feature that makes longer platforms have A and B sides, that if a three tile train enters a seven tile platform, the three tiles (or four) on the other side are still usable. It would be an issue if both trains wanted to cross, but if you can program it properly and only have two final destination trains on each side (or have one terminal and one continuous train that departs later) it should be good. Of course the programming is up to the player's discretion. I can make a three tile - gap/waypoint/signal - three tile station instead, but that would disallow seven tile trains to use the entire platform in one go if you catch my drift.

[Eddi]

ok, quick thought here:

1. each patchpack chooses a 4-letter ID (we have plenty of those going around already) to represent itself (master could get "OTTD" or something)
2. the version number reported to NewGRFs will then be uncomparable between patchpacks, and ech pactchpack has the responsibility to provide an incremental version. (something here needs to change in openttd master anyway, since there is no automatic incremental revision number anymore)

major drawback here is that a NewGRF checking for feature availability must know every patchpack

another approach could be an Action6/7/9/D variable thatgets a parameter XXYY and acts like "is there feature X property Y in this version?" that might be extended to other stuff like new callbacks, but might not wrk for all types of spec changes

[michael blunck]

Isn´t that too complicated? We don´t have querying of features now. We only have revision numbers, and a newGRF has to know what revision supports a certain feature.

So, e.g. JGRPatch could choose a value for 9D (IIRC, NMF already has this), and use existing var A1 for revisioning.

Or is that too simple?

regards
Michael

[Eddi]

well, if the future of development goes into the direction that several long-term patchpacks live side-by-side, it is to expected that newgrf features will be introduced at different times, possibly also in different order.

there is probably no simple solution here. there is some coordination effort needed at some place, and i'm not sure how that really works out

[JGR]

I'm inclined to adopt a versioning system which sort of looks like the one I'm currently using for savegames.
Broadly speaking this is the unaltered trunk version numbers + a list of named features with an associated integer version number.
This is to the avoid the numerous issues in nearly all preceding patchpacks where savegame versioning was ham-fistedly forced into a linear model, such that backwards and forwards compatibility didn't really work very well, if at all.

For the same reasons, I'm not keen on trying to redefine the trunk linear version numbers or platform number, as this just creates compatibility headaches with GRFs versioned against trunk and when I come to merge future trunk changes.

My current thought is to use action 14 CSTM to encode something to the effect of:
Set bit N (where N >= 4) of variable 8D iff the feature identified by STRING exists and has a version number >= MIN_VERSION.
Bits of variable 8D can then be tested in the usual way, and will be 0 on implementations which don't have the feature or know about feature tests.

I will look to write up a proper proposal at a later time.

[michael blunck]

My current thought is to use action 14 CSTM to encode something to the effect of:
Set bit N (where N >= 4) of variable 8D iff the feature identified by STRING exists and has a version number >= MIN_VERSION.
Bits of variable 8D can then be tested in the usual way, and will be 0 on implementations which don't have the feature or know about feature tests.

Var 8D? You mean 9D?

Code: Select all

8D	B	TTD version, 0=DOS, 1=Windows
9D	D	TTD Platform, 0=TTDPatch, 1=OpenTTD

regards
Michael

[JGR]

My current thought is to use action 14 CSTM to encode something to the effect of:
Set bit N (where N >= 4) of variable 8D iff the feature identified by STRING exists and has a version number >= MIN_VERSION.
Bits of variable 8D can then be tested in the usual way, and will be 0 on implementations which don't have the feature or know about feature tests.

Var 8D? You mean 9D?

Code: Select all

8D	B	TTD version, 0=DOS, 1=Windows
9D	D	TTD Platform, 0=TTDPatch, 1=OpenTTD

regards
Michael

Either of them would be fine really, I suppose 9D is better as it's advertised as being wider.

[Emperor Jake]

Custom bridgeheads for rail are awesome, but naturally we managed to get carried away and break it again

The game crashes when placing or removing signals on bridges with custom bridgeheads in a certain way. To reproduce it, open the netsave (which should already be in the right location) and click on the tile shown using the remove signal tool.

crash.png (69.51 KiB) Viewed 2479 times

I can PM you any missing GRFs if needed. Version is 0.26.0 Win x64.

UPDATE: It seems signals on custom bridgeheads is completely broken, when I did manage to remove the top signal, the train got stuck at the other signal even though it was green, probably because the game can't handle a signal that's also on an intersection.

[JGR]

UPDATE: It seems signals on custom bridgeheads is completely broken, when I did manage to remove the top signal, the train got stuck at the other signal even though it was green, probably because the game can't handle a signal that's also on an intersection.

Signals are not permitted on junction tiles.
I thought that all ways of constructing that were disallowed but I must have missed something, I'll look into it.
Many thanks for the bug report.

[Emperor Jake]

Thanks for the quick response.

Another related minor issue: train wagons on custom bridges are out of alignment for some reason:

[JGR]

UPDATE: It seems signals on custom bridgeheads is completely broken, when I did manage to remove the top signal, the train got stuck at the other signal even though it was green, probably because the game can't handle a signal that's also on an intersection.

Signals are not permitted on junction tiles.
I thought that all ways of constructing that were disallowed but I must have missed something, I'll look into it.
Many thanks for the bug report.

This is now fixed.
Any bridges which came to exist with both signals and junction tiles should be removed carefully, things like signal updating, etc. most likely will not work properly, and the game may crash in some circumstances.

Thanks for the quick response.

Another related minor issue: train wagons on custom bridges are out of alignment for some reason:

Edit: Fixed now.
Thanks again for the bug report.

[le_harv]

Ever since I have upgraded from 25.2 to 26.0 I can't seem to place waypoints properly on a particular axis. I am using the windows binary you share.

Using the attached save as a test, in 25.2 no problem but when loaded in 26.0 I get an error saying, no suitable railway track found but only on the NW to SE axis.

WP Test.sav

(35.61 KiB) Downloaded 33 times

EDIT - To add my thanks too. The custom bridgeheads for both rail and road are a gamechanger addition.

[JGR]

Ever since I have upgraded from 25.2 to 26.0 I can't seem to place waypoints properly on a particular axis. I am using the windows binary you share.

Using the attached save as a test, in 25.2 no problem but when loaded in 26.0 I get an error saying, no suitable railway track found but only on the NW to SE axis.

WP Test.sav

EDIT - To add my thanks too. The custom bridgeheads for both rail and road are a gamechanger addition.

The waypoint issue is reported and fixed already, I'll do another release soonish with this in.

[JGR]

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

I can't reproduce this on Linux which means that I'm unlikely to be able to debug/resolve it.
Using Wine produced some odd performance behaviour but the cause was not obvious and I wasn't able to debug anything in that environment.

2. Fails to load a save game provided by me in this post.

I've attached a fixed savegame:

U-TIC Organization, Oct 7th, 2121 - fixed.sav

(1.35 MiB) Downloaded 37 times

[eshield]

I can't reproduce this on Linux which means that I'm unlikely to be able to debug/resolve it.
Using Wine produced some odd performance behaviour but the cause was not obvious and I wasn't able to debug anything in that environment.

Thanks for an attempt!

I've attached a fixed savegame: U-TIC Organization, Oct 7th, 2121 - fixed.sav

[SquireJames]

Hey there, No biggy if this can't be fixed or I did something impossible, but decided to upgrade from jgrpp-0.25.2-MINGW-win64 to jgrpp-0.26.0-MINGW-win64. My save game now crashes when trying to load. Attached is the log and dmp file. If you need a save file I can upload it to.

As I said, trundling along quite happily with 0.25.2 so, I'll revert to that for now.

[JGR]

Hey there, No biggy if this can't be fixed or I did something impossible, but decided to upgrade from jgrpp-0.25.2-MINGW-win64 to jgrpp-0.26.0-MINGW-win64. My save game now crashes when trying to load. Attached is the log and dmp file. If you need a save file I can upload it to.

As I said, trundling along quite happily with 0.25.2 so, I'll revert to that for now.

This looks like one of the issues that has been reported and fixed already, so it should load in the next release.
Thanks for the report though.