michael blunck wrote: ↑03 Dec 2020 10:49
JGR wrote:
All normal variables are 4 bytes/DWORD sized
Does that mean, there are indeed (some) variables which are not 4 bytes?
I mean, the nfo docs specify a lot of different var sizes, which I take consideration of in my m4nfo implementation. Which would be quite more simple in case all vars were indeed 4 bytes? Except the problem Eddi mentioned?
Variable 0x85 (TTDPatch flags) is one which comes to mind as clearly not 4 bytes, however this is special cased and only usable for bit tests.
michael blunck wrote: ↑03 Dec 2020 10:49
Another question regarding your custom feature implementation:
There are different names for features and associated property mappings. So, for checking a specific feature I'd have to use e.g. "action0_station_prop1B", and to check for success of its associated property mapping I have to use " station_min_bridge_height". There might be reasons for this, but couldn't the names be the same? I'm aware there are features which don't establish property mappings.
Is it needed to test both for the availability of a feature and then again for success of the mapping process?
And are programmable/restricted signals (as custom features) the same (signal type == 6), only different by setting bit 24 in var18? I.e. for a programmable signal I'd have to set signal type to 6 and also bit 24 in var18? So, there's no signal type 7? I mean the TT range is still quite empty? Or are programmable and restricted signals the same, internally? And thus need to be handled by the same signal type?
regards
Michael
The names are different are they are conceptually different things, though in retrospect the names could have been made the same. I'm a bit reluctant to change them now though as there are already GRFs using them.
The default property mapping fallback mode is such that mapping an unknown property or action 5 type and then using it is not an error, the property is simply skipped. (This is why all the values are length-prefixed).
Testing any one of these is sufficient, it's not necessary to test all/multiple of them:
* Testing the feature name 'property_mapping' or 'action5_type_id_mapping' respectively.
* Testing the mapping success via the SETT field and var 0x8D.
* Testing the feature name for the specific property.
If you're doing something more complicated than just setting properties you may need to do more than one test, or use a specific one instead of just 'any one of these'.
The redundancy of mechanisms is so that no matter what is being done and how complicated it is, there is a way to do it correctly which falls back on all of: trunk OpenTTD without property mapping, patchpack with property mapping and without feature, patchpack with property mapping and with feature.
michael blunck wrote: ↑03 Dec 2020 10:49
And are programmable/restricted signals (as custom features) the same (signal type == 6), only different by setting bit 24 in var18? I.e. for a programmable signal I'd have to set signal type to 6 and also bit 24 in var18? So, there's no signal type 7? I mean the TT range is still quite empty? Or are programmable and restricted signals the same, internally? And thus need to be handled by the same signal type?
Programmable pre-signals are signal type == 6.
Restricted signals are not a signal type. Any signal can have a routing restriction program attached. bit 24 in var18 indicates this if the feature is enabled.
Currently there is no signal type == 7.