Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Goober5000 on February 11, 2006, 09:18:07 pm
-
This was one of those things I always had at the back of my mind but only just recently got around to fleshing out. (Sort of like multiple docking, but nowhere near as complex. ;)) You now have the ability to insert comments in Freespace files that will be ignored by FS2 retail but parsed by FS2 open. Furthermore, you can specify the version within the comment so that your files are both forwards- and backwards- compatible.
As with a lot of features, this was driven by an ulterior motive: the desire to leave the FSPort music.tbl in the main folder without having retail choke on it. Well, this new feature will let you do that. :) Furthermore, I've made a few additions to the mission file so that you can import an FS1 mission which will play a standard FS2 track when run on retail and an enhanced FS1 track when run on the SCP. :) You won't want to miss the next version of the FSPort. ;)
/end of advertisement
Okay, so here's how it works. Add the prefix ;;FSO 3.6.8;; to the beginning of a line in any table or mission, where 3.6.8 corresponds to the version where the feature was first introduced. I've attached Sesquipedalian's SSLBeam to show you how it's done. Since beam tiling and translation was introduced in version 3.3, the SCP-enhanced version of the SSLBeams breaks the retail table parser. With version-specific commenting, the beams will parse properly in retail, yet use tiling and translation in the SCP.
Also, because of the version specification, it's not a "FSO = parse, retail = don't parse" deal; FSO will ignore lines with higher version numbers. This could be useful for campaigns that are in the process of putting together new modpacks with different tables than most of their staff is using. Additional lines can be added to the table which will only activate if a team member is using a recent build.
The main drawback of this is that builds prior to today's CVS will treat these lines just the same as retail (i.e. ignore them) so, for example, you won't be able to swap between retail and version 3.3 and have the beam translation toggled on and off. But hopefully this will become more useful as we add things in the future. :)
[attachment deleted by admin]
-
Very clever :yes:
What about adding an option to alert people if a mission or table actually requires a certain build?
-
Very clever :yes:
Thanks. :)
What about adding an option to alert people if a mission or table actually requires a certain build?
I think that's a separate concept. This thing is made to facilitate swapping between builds for people who need that sort of thing (e.g. the Port) so a message for every comment would be counterproductive.
One possibility would be to have the parser look for something like
#Required FSO Version: 3.7.0
at the beginning of every table file, but retail would choke on it. You could hide it with a version-specific comment, but then retail would plunge blindly ahead. :)
-
As with a lot of features, this was driven by an ulterior motive: the desire to leave the FSPort music.tbl in the main folder without having retail choke on it. Well, this new feature will let you do that. :)
While I love this feature I feel compelled to point out that your explaination for why you did it is like explaining why you felt the need to build a super strong metalllic condom to prevent you having problems when sticking your dick in the blender. :p
You should be using mod folders and mod inis so that this isn't an issue in the first place. :D
Thanks. :)
One possibility would be to have the parser look for something like
#Required FSO Version: 3.7.0
at the beginning of every table file, but retail would choke on it. You could hide it with a version-specific comment, but then retail would plunge blindly ahead. :)
Do it. :) If you've installed everything correctly retail should never see a file it can choke on.
-
I've started scripting mod.ini files for all my fs ports, mods, and even campaigns, and I think it works darn snazzy. I think the .rar campaign downloads should all come with a little graphic and their own mod.ini file. I wonder if the next launcher could give an option to type in command flags in the mod tab so that it modifies the mod.ini file of a mod folder, like it creates its own launcher6.ini file. If not necessary, I think this would be a handy feature. That way, you could just check boxes for which mod folders are to be used and the launcher would just toss their names in the mod.ini list. In conclusion, I need to learn to code.
-
While I love this feature I feel compelled to point out that your explaination for why you did it is like explaining why you felt the need to build a super strong metalllic condom to prevent you having problems when sticking your dick in the blender. :p
You should be using mod folders and mod inis so that this isn't an issue in the first place. :D
That's an... interesting comparison... :wtf: :lol:
But you may not have caught on to what I'm trying to do with the Port. I'm trying to set it up so that one download can be used with either retail or FSO.
For people that can only run retail FS2, mod folders aren't going to help them. I could make two separate downloads, one for retail and one for FSO, but that could lead to complications where someone downloads the wrong version (in addition to having to remember to update both downloads in case of a patch). Version-specific commenting requires more work at the beginning but makes things much easier from then on.
-
Ah. Fair enough. It's just that I wonder what else you need to do to the retail version.
Might be simpler to just freeze at the current version for retail and only update the SCP version :)
One question though. How hard would it be to have the parser take the version specific comment and then skip any further lines with lower numbers and the same token? So that you could have an entry like this.
;;FSO 5.6.8;; $Flags: ( "player_ship" "default_player_ship" "fighter" "show_ship" "supports_geomod")
;;FSO 3.6.8;; $Flags: ( "player_ship" "default_player_ship" "fighter" "show_ship")
$Flags: ( "player_ship" "default_player_ship" "fighter" )
-
Quite a bit harder actually. Not sure how you'd do that.
Probably modular tables would be better for that.
-
Ah. Fair enough. It's just that I wonder what else you need to do to the retail version.
Might be simpler to just freeze at the current version for retail and only update the SCP version :)
One question though. How hard would it be to have the parser take the version specific comment and then skip any further lines with lower numbers and the same token? So that you could have an entry like this.
;;FSO 5.6.8;; $Flags: ( "player_ship" "default_player_ship" "fighter" "show_ship" "supports_geomod")
;;FSO 3.6.8;; $Flags: ( "player_ship" "default_player_ship" "fighter" "show_ship")
$Flags: ( "player_ship" "default_player_ship" "fighter" )
Late post!
What would make a little more sense, at least from my perspective, would be something like
$Flags: ( "player_ship" "default_player_ship" "fighter" )
;;FSO 3.6.8;; $Flags: ( "show_ship")
;;FSO 5.6.8;; $Flags: ( "supports_geomod")
If the Flags field is a bit switch, then you'd make the additional parse the bitwise OR of the current line parse with what's already been read. And it would use less space.
Missions would benefit from this as well I'd think, so that non-retail SEXPs could be hidden from the retail executable. Sort of like the FSO-specific extensions I was trying to propose when Galemp asked that glowmaps be turned off when a ship is told to play dead because of how that affected the port.
-
Late post!
What would make a little more sense, at least from my perspective, would be something like
$Flags: ( "player_ship" "default_player_ship" "fighter" )
;;FSO 3.6.8;; $Flags: ( "show_ship")
;;FSO 5.6.8;; $Flags: ( "supports_geomod")
If the Flags field is a bit switch, then you'd make the additional parse the bitwise OR of the current line parse with what's already been read. And it would use less space.
While you want that.... the way it is would work better for things like:
;;FSO 3.6.8;;$Pof File: HTL-Mjolnir.pof
$pof file: Beamsaber.pof
No?
Replacive, rather than additive works best in this situation, and is more than likely much much less code to code. unless Goober wants to make it field dependant.
-
It wouldn't work, though, because any version >= 3.6.8 would read $Pof file twice.
That sort of thing is better done with modular tables.
-
In general, it's only new fields and new flags that's the issue, as that's what FS2 retail will choke on. Replacing things should be done with modular tables. Flags is the only place where you'd want to be able to parse the same field more than once, as it contains a lot of things that aren't necessarily retail-friendly.