As near as I can tell this in-game menu would require its own assets, right? That means that for new graphics options (ie, whatever brilliant beautiful thing valathil does next. Side note: Shadows+Lightrays? Awesome.) to be used in game, say on a nightly test build, you'd still need to use the launcher/a custom command line. As such, I'd think that an ingame menu should be used as a tweaking thing (like flaser was talking) rather than as the sole general end-user settings point of contact - that's only really a good idea if you're dealing with a finished game and a fixed feature set.
Now that being said, I would LOVE the ability to custom-tweak all those little lighting display tags and see real-time (or even set, hit apply, screen refreshes, set again, etc.) changes in the effect they have, instead of having to close out, tweak the command line/launcher settings, relaunch, etc, until by the time I'm through pilot selection and so on, I've half forgotten what the old settings looked like and I can't compare 'em effectively.
Pie-in-the-sky dreaming here, but would it be possible to have the settings window have, either in a 1/4-sized preview panel or as a togglable screen, a nice big battle with lots of flak and beams and stuff flying all around so as to make sure that A: everything looks nice and pretty and B: the framerate's good.
oh of course im gonna do a preview window. i was thinking about taking a random ship and displaying it + custom things that would serve to highlight the current mouseovered parameter i.e. checkerboard surface below a ship to see shadow parameters or an animated beam swishing around for spec_tube. as for assets im really trying hard to create the menu with antialiased lines and polygons alone so i wont need a graphics artist and so everything remains dynamic and can be modified at will in code. though i wouldnt say a skin system would be out of the question after its done (do i hear screams of MODULAR INTERFACE SCREENS or is that just me)
im of the opinion of do a text based command interface (sort of an ingame console), and make it possible to talk to it from scripting, and let the scripters do the rest. but thats just me.
the console itself would be typical of something you would find in many games, a kestroke pulls down a screen where the user can read information about what the engine is doing and issue commands. think of it as the debug console, only in the game and with a command prompt. you can open it type in anything you want to change and close it. it could also talk to events or scripts currently running (though this would be hidden from the user unless they open the console and read the information there).
it would work like this
1. a script wants to set a variable or issue a command
2. for variables, script queries the console for parameters, or if a command, asks the console if the command the script wants to issue is valid and currently available (for example "end_mission" would not be available if not in mission).
3. the console returns data to the script (probibly as text), if a command is good, bad, or unavailable, or for variables, the type of variable and allowed values and ranges and what the variable is currently set to.
4. the script uses that data to issue a command and also for setup purposes
5. if the command fails it will report an error to the console (script would interpret this as a return value). this is why you want to query the console before issuing commands. this ensures the script cant do anything its not allowed to do (if you try to do it it will fail anyway).
now you just need a
gui script and youre all set. modders probably dont want to learn script to create a custom interface. so you have a small community effort to create a base interface to be issued with the media vps. modders want to customize the interface, they can change the base interface graphics. some mods might get adventurous and script their own interface. having a base interface script gives them a starting point. want to run in vanilla? you still have the console and can issue the commands the stock interface doesn't support.
the alternative is adding a gui table, which for the most part would work. most gui apis really just have you place gui elements and you say what you want where you want it and what it does when you interact with it. doing it with scripting makes it versatile as ****, doing it this way makes it a little bit more restrictive. but im not gonna write it so what do i care?
