Feature #1008

verify that the program using the generated grf is new enough

Added by Alberth about 9 years ago. Updated over 8 years ago.

Status:NewStart date:2010-06-12
Priority:LowDue date:
Assignee:-% Done:


Target version:-


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.

versions.patch Magnifier - parsing/storing of minimal version info (4.89 KB) Alberth, 2010-09-26 22:48

versions2.patch Magnifier - version 2 of the program version check frontend code. (5.95 KB) Alberth, 2010-10-03 14:08


#1 Updated by yexo about 9 years ago

Adding a few actions to check for openttd/ttdpatch and their versions is pretty easy, the real question is where to add such code? I think the most important places are action0/action2, as new properties/new variables are by far the best reason to require a certain version (also new features like railtypes/airports of course, but those don't happen that often).
  1. 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
  2. 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+.

#2 Updated by planetmaker about 9 years ago

adding support for OpenTTD 1.0.0+ is sufficient IMHO

#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

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.

#7 Updated by yexo over 8 years ago

Agreed with Hirundo, that makes it also easy to make "revision" an optional argument.

#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.

yexo wrote:

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.

#10 Updated by Alberth over 8 years ago

Patch updated

Also available in: Atom PDF