verify that the program using the generated grf is new enough
Some of the NewGRF primitives were introduced with particular versions of ttdp or openttd. Perhaps we should also generate code that verifies the program version, to ensure the grf will work properly or fail to load, rather than causing undefined behavior.
#1 Updated by yexo about 9 years ago
- add an extra return value to all parse_* function that returns the minimum openttd/ttdpatch version. In this case it the version needed can be determined from the ast or the actionlist, whichever is easier
- Add a new function to all actions that returns the minimum openttd/ttdpatch version. The ast no longer exists at this point so all information should be determined from the actionlist.
I'd prefer the second option, although the first one is probably easier to implement.
We also have to decide where we set the baseline. If openttd 1.0.0 would the minimum version we support then we don't have to worry for all properties/variables added long before because it doesn't matter if they work in 0.6+ or only 0.7+.
#3 Updated by planetmaker about 9 years ago
But in order to elaborate on it: I don't think NML should go and decide for the programmer which minimum version requirement a newgrf should have. Otherwise one will need to make checks on all action7/9 things, too, know which feature will silently be ignored, even if declared but not recognize.
That's more hassle than it's worth. What WILL be nice, is possibly a warning(?) that <XXX> requires OpenTTD version YYY.
#4 Updated by yexo about 9 years ago
I agree with planetmaker, a warning in case something is not supported would be best. However we should have some easy syntax to check for minimum openttd/ttdpatch version like
minimum_openttd_version(1, 0, 1, 19839); which (in the global scope only) would check if the current host is openttd, then if the version is lower then specified skips the rest of the grf.
#5 Updated by Alberth over 8 years ago
- File versions.patch added
- % Done changed from 0 to 30
Hereby a patch for entering, parsing, and doing some basic storage for program versions.
The next step is in nml/ast/progversion, to extend get_action_list() that it outputs one or more actions from the version checks that have been collected in the progversions global. Before exiting the function, the global should be cleared to prevent other progversion objects from doing the same.
#6 Updated by Hirundo over 8 years ago
Could you use an expression_list token instead of hard-coding the number of parameters in the parser? The expressions should be handed to the AST as a list, which then checks that it is of the correct length.
Else, the user gets 'Syntax error' when he entered a parameter too few/many.
#8 Updated by Alberth over 8 years ago
Using an expression list seems like a good idea. I could use a bit of help with the action 7 code, please.
Agreed with Hirundo, that makes it also easy to make "revision" an optional argument.
Making 'revision' optional raises the following question with me:
How to decide whether a given trunk revision is new enough if a user does not specify it?
#9 Updated by Hirundo over 8 years ago
No revision set by user ==> stable.
i.e. version (1, 1, 0) with no revision specified will not work until 1.1.0 is actually out.
In code, this will mean a revision of 0x80000 (bit 19 set), see http://wiki.ttdpatch.net/tiki-index.php?page=Action7.