Quote Originally Posted by DarkDragon View Post
The problem with checking the quest version is that it fixes old quests, but breaks quests that are loaded into ZQuest and then re-saved, without recompiling the scripts. And it's a silent failure, without any warning to the author that they are about to corrupt their quest.

If by "Zscript version number" you mean V_FFSCRIPT and CV_FFSCRIPT, this is not especially useful, since it also is set at the time the quest is saved, and does not necessarily match the version of ZScript at the last time the scripts were compiled (and moreover, the scripts might have been compiled at different times using different version of ZQ, due to the behavior of preserving missing scripts that are not found anymore on the hard drive).

A quest rule is one option, as Saffith suggests. We could also modify ZASM to store more metadata with each script, including a version number, which could be used for these kinds of changes in behavior.
Good point. I'll write a quest rule and rewrite the function in the near future. I used the quest header's ZC_VERSION, which is what Saffith originally advised, because I had issues with V_FFSCRIPT. This instead, caused problems when the quest author, @Mitsukara recompiled the scripts withotu changing the input values.

The issue with LayerMap, and SetComboSolid, was that it was targeting invalid map IDs with its old calcs. A quest rule seems the best solution to that for the present, although given the state of flux of ZC< I hesitate to add them--we have far too many as is, for things that should be handled by the object editors... I would be in favour of storing that kind of datum, and on consideration, it's probably the best option.

You need to chat with @Grayswandir and ensure that you both keep on the same page with the parser though. I don't want to see you two working on things that are mutually-exclusive, given that the script parser, at the least, should be maintained as directly compatible between main and 2.future; so that exporting between versions is always possible. (We already do this, for 2.50.x compatibility exporting.)