Andrew350 wrote:
I don't see (or rather, understand) how you check for these sub-parameters explicitly.
You need to understand bit operations for this as you need to mask out the bits you're not interested in and check for that result:
(grfparam[GRF_OGFXL, 0] & 0x00000001) will set every bit to 0 except the least significant one (bit 0). So you can then test the variable for either 0 or 1.
(grfparam[GRF_OGFXL, 0] & 0x00000002) similarily can only have the values 0 or 2, checking bit 1
(grfparam[GRF_OGFXL, 0] & 0x00000004) similarily can only have the values 0 or 4, checking bit 2
(grfparam[GRF_OGFXL, 0] & 0x00000008) similarily can only have the values 0 or 8, checking bit 3
In the latter cases some shifting might then be interesting to end up again at 0 or 1:
((grfparam[GRF_OGFXL, 0] & 0x00000002) >> 1) will give values 0 or 1, checking bit 1
((grfparam[GRF_OGFXL, 0] & 0x00000004) >> 2) the same, checking bit 2
((grfparam[GRF_OGFXL, 0] & 0x00000008) >> 3) the same, checking bit 3
Also, I notice in OpenGFX+ Airports that the check for another NewGRF uses grf_future_status, whereas I am using grf_current_status. What is the benefit to using one or the other, is the one I'm using correct?
The difference is in the order in which NewGRFs are activated in the list of NewGRFs. grf_current_status only returns true if the grf you check for is above yourself in the user's list, grf_future_status will additionally also return true when it is below you and become active.
And one more, about this bit of code,
Is 254 a fixed parameter number for finding the specific version number of a GRF? I couldn't find anything anywhere about how to do that when I originally coded up the GRF, not that is was important then. It might be useful in the future though.
Yes, parameter #254 is the version number, and yes it's not documented anywhere, waiting for a nicer, more user-friendly way to make this available