Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Some NewGRF variables concerning railtypes #7000
The intent is to use this in, varaction 2 for e.g. CB36.
Without this var, railtype labels have to be checked individually, which:
I second the "skip the redundant part".
This variable seems to be about comparing two railtypes.
In addition it may make sense to extend 4A with more attributes about the present railtype:
Maybe - but not necessarily - related:
i don't think "track has catenary" is a property of a railtype that can be meaningfully extracted from the arbitrary NewGRF data.
my previous idea about that was a vehicle state variable with values:
possibly also add a bitset of what the reason for "cruising" is?
i feel like there was another ticket where that discussion would fit better
independent of that, adding railtype max speed to var4A should be possible, however
referenced this pull request
Jan 7, 2019
5 times, most recently
Jan 15, 2019
changed the title
Add: Var 6A, a clone of Var 4A for querying poweredness compared to a…
Jan 15, 2019
Removed the lookup bit, and renamed the var to 63, because there's not enough relation to var 4A left to warrant a similarity in name.
Added "has catenary" flag and railtype speed limit to var 4A (doesn't have to be the speed limit currently affecting the train, so i don't know how useful that is)
So, i have no idea if this is the correct way to make a translation between grf railtype and game railtype.
Also, i have added a variable that makes that translation and then a reverse translation, this might be useful for checking whether two "logical" railtypes are mapped to the same internal railtype. this might need some more extensive testing
Well, my use case would be a wagon that can run on a 15t, 18t, 20t or 22t railtype, with different capacities. but if the railtype GRF doesn't provide any distinguished weight class types (as per the standardized railtype scheme), the different variations could be omitted.
Slightly more elaborate answer, let's assume i have the following railtype table in my GRF (pseudocode):
now, NML will happily generate code to detect the presence of the railtypes with the existing checks, and fill in the fallback types as needed.
now the cases i want to detect here are:
case 3 is not detectable with the current methods
So how it is meant to work now is, assuming same railtype table as above, and the following action D:
then the result in parameter 00 should be 0 if both are mapped to the same type (case 1 or 3 above) or non-0 if different (case 2 above), which then could be checked in a following action 6,7 or 9, as appropriate