Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nuke on November 08, 2011, 03:32:17 pm
-
you know how in c you can use macros to blot out sections of code you need disabled or select from a series of code blocks based on some option? what if we could do that with tables?
often modders end up working across multiple versions of the engine during the course of mod development. say you want to use features in an experimental build, but still do most of your deving under stable. you ususally end up getting the way you want them and then commenting them out until they hit trunk. what about we do something like:
$tried and true setting that works in stable build: 42
?ifvers: 3.6.13
$tag that works in only in 3.6.13 and should be ignored everywhere else: 69
?endif
?ifhighervers: 3.6.13
$tag that only works in builds after 3.6.13: 3.14159
?endif
?iflowervers: 3.6.12
$tag that was deprecated after 3.6.12 and shouldnt be used anymore: "your mom"
?endif
the syntax starts with some character that would otherwise be treated as a comment and skipped such as, "?" (i used ? but it could just as easily be an @ or a &), followed by the comparation type:
if: true if values match
ifnot: true if values do not match
ifgreater: true if value is higher than attribute
iflesser: true if value is lower than attribute
the next part defines the attribute that is being checked against. i used the games version number (the short version, in practice the long version would be better). i figure you might also want mediavp version, or versions from other mods you are using. this would be followed by the ":" character and then the value which would be parsed as a string and handled differently depending on the attribute name.
so we got:
"?"+comparation type+attribute name+":"+value
;text block containing table tags
?end
and if the conditional statement is true, the text block is parsed, otherwise its treated as a comment and skipped. you might also do ?else and ?elseif statements, but those could be constructed from these primitives. just an idea, not gonna assume modders would understand or use this. many of them would likely go "wtf?!?". but for large scale mod projects deving off of multiple versions i think it would come in handy.
-
Doesn't something like this exist?
Like these version tags.
;;FSO 3.6.8;;
-
Doesn't something like this exist?
Like these version tags.
;;FSO 3.6.8;;
I thought the semicolons in table files were... comments.
-
Doesn't something like this exist?
Like these version tags.
;;FSO 3.6.8;;
I thought the semicolons in table files were... comments.
They are, but a double semicolon with that pattern is treated as a conditional by new engines (3.6.10> IIRC), similar to what Nuke is proposing . The reason that the current system uses the comment characters is because it allows older binaries (retail in particular) to still parse the table. If I recall correctly, this is how Silent Thread: Reborn is able to remain retail compatible but still supporting some of the newer goodies. I believe this is also how FRED implements the "compatibility modes" that are listed in the File menu.
Unfortunately I am not closely familiar with the details and I can't find a wiki page about it (I didn't look that hard though). If you bug Goober5000 (the one that implemented it) or Karajorma they will be able to provide more information.
One problem with what Nuke proposes (beyond the fact that we already have as similar system) is what happens to binaries that don't understand the new syntax? They will just fail if I understand what Nuke is proposing.
-
One problem with what Nuke proposes (beyond the fact that we already have as similar system) is what happens to binaries that don't understand the new syntax? They will just fail if I understand what Nuke is proposing.
Could you have the conditional bits of code "commented out" (so that retail thinks its just a comment?)
-
One problem with what Nuke proposes (beyond the fact that we already have as similar system) is what happens to binaries that don't understand the new syntax? They will just fail if I understand what Nuke is proposing.
Could you have the conditional bits of code "commented out" (so that retail thinks its just a comment?)
Yea, which is how the currently implemented system works around that problem.
-
gotta love secret undocumented features :P
Doesn't something like this exist?
Like these version tags.
;;FSO 3.6.8;;
I thought the semicolons in table files were... comments.
They are, but a double semicolon with that pattern is treated as a conditional by new engines (3.6.10> IIRC), similar to what Nuke is proposing . The reason that the current system uses the comment characters is because it allows older binaries (retail in particular) to still parse the table. If I recall correctly, this is how Silent Thread: Reborn is able to remain retail compatible but still supporting some of the newer goodies. I believe this is also how FRED implements the "compatibility modes" that are listed in the File menu.
Unfortunately I am not closely familiar with the details and I can't find a wiki page about it (I didn't look that hard though). If you bug Goober5000 (the one that implemented it) or Karajorma they will be able to provide more information.
One problem with what Nuke proposes (beyond the fact that we already have as similar system) is what happens to binaries that don't understand the new syntax? They will just fail if I understand what Nuke is proposing.
i figure if you check for the conditional character before comment are removed then you could comment out the conditional. you could also use a compound character like ;?.
some issues might crop up from using the same character which a majority of modders would interpret as just being a comment and not recognizing the pattern has significance. using a ;? ?; enclosure would be more intuitive, but would still be interpreted as a comment on older builds.
if anything id expand the current system to allow for build number in addition to version, and perhaps support some additional logic features (greater than, less than, not). unless of course those already exist.
-
gotta love secret undocumented features :P
inorite?
i figure if you check for the conditional character before comment are removed then you could comment out the conditional. you could also use a compound character like ;?.
some issues might crop up from using the same character which a majority of modders would interpret as just being a comment and not recognizing the pattern has significance. using a ;? ?; enclosure would be more intuitive, but would still be interpreted as a comment on older builds.
What's wrong with the current ;;FSO system? (Just curious why a change would be necessary on the syntax)
if anything id expand the current system to allow for build number in addition to version, and perhaps support some additional logic features (greater than, less than, not). unless of course those already exist.
Those additions could be useful.
-
no real reason to change the syntax if it works. it just doesnt seem intuitive is all. some modders might confuse it for a comment. im sure if the feature was documented better it would confuse modders less, and eliminate the need for any changes.
-
IIRC this was how FS1 music tables were made to work with FSO; I think it was FSO 3.6.8 or .9, I really can't remember. Might even have been .7
EDIT: And, if you put a short description in each table, that would work for documentation, no?
;To use version-specific features, use a double semi-colon ( ;; ) at the beginning of the line
;followed by the version desired, e.g. ;;FreeSpace Open 3.6.8
Copy + paste something similar to that to all tables?
-
The ;;FSO tag does work in a greater than mechanic, fyi. If a feature is tagged as 3.6.8, it will only work in builds that are 3.6.8 or greater.
As for instituting a feature that will only operate on earlier builds, I can't exactly see why you would want to do that especially if it's been deprecated or converted to a newer feature function.
And yes, there are any number of "hypothetical" situations that could be thrown at that statement. But I can't think of anything (other than $Decals which didn't work even in .10) that got removed in such a way that it would cause any problems to require version tagging their entry to being pre-.10 loadable only, since people would be (at this time) using either .12 or .14 RC1.
In fact the only thing I could think of where it would be useful is in any changes to value types for conditions. I accidentally $Special Explosions: values for instance, which caused Axem no small amount of inconvenience, and that could have been avoided with a pre-version tag maybe, but that would have been an erroneous work-around and wouldn't have really addressed the larger problem presented by the change.