Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Valathil on December 08, 2011, 05:53:41 pm
-
So in the process of making shadow parameters accessible I'm thinking about doing a graphics option menu in the style of the f3 lab for ingame parameter tweaking. I'm thinking of replacing some of the graphic cmdline options with this framework to ease the issue of configuration for normal users. So what would be really great from you guys would be suggestions of stuff that i can put in there besides the shadow stuff. Interface design suggestions would also be very welcome.
-
Just a few questions for clarity:
1. Why make a saparate in game options menu in addition to the launcher parameters and the retail options menu?
2. What sort of parameters would fall under this menu? Anything goes graphics wise? Or do you have something specific in mind?
3. Would you want to overlap the launcher graphics options for any reason? (I don't know why, just asking)
4. What prompted you to want to do this?
Answer all some or none of them. Thanks :D
-
Hmm. The following could be useful tweakable parameters:
-bloom on/off, intensity
-FXAA on/off, intensity
-explosion distortion on/off
-thruster distortion on/off* (especially since it has no flag in launcher at this point)
-(eventually) sunshafts on/off
-
will this allow on the fly tweaking of graphics settings, such as during mission?
regardless its about damn time. then we can move to deprecating launcher flags :D
-
Just a few questions for clarity:
1. Why make a saparate in game options menu in addition to the launcher parameters and the retail options menu?
The problem is that there's no way to extend the standard options menu without redesigning the UI graphics. Using something similar to the lab is a much easier way of doing things.
2. What sort of parameters would fall under this menu? Anything goes graphics wise? Or do you have something specific in mind?
Anything from the graphics-related launcher sections that we can cram in there.
3. Would you want to overlap the launcher graphics options for any reason? (I don't know why, just asking)
I believe the best thing would be to just ditch the launcher as the main tool for setting up stuff. It's convenient for first-time setup stuff, but it is my belief that all settings should be changeable within the game.
-
3. Would you want to overlap the launcher graphics options for any reason? (I don't know why, just asking)
I believe the best thing would be to just ditch the launcher as the main tool for setting up stuff. It's convenient for first-time setup stuff, but it is my belief that all settings should be changeable within the game.
As a launcher writer, I am on the fence. We either need to put everything changeable from the game or make nothing changeable and have the launcher directly start the engine in a campaign/mission, skipping the mainhall.
At that, I do request that whatever is added here, is accessible in a sane format by the launcher, either in the registry/registry equivalent or in a file. I also ask, that the names and valid values are documented (in the code or otherwise) so that the launcher doesn't need to fumble around in the dark.
-
As a launcher writer, I am on the fence. We either need to put everything changeable from the game or make nothing changeable and have the launcher directly start the engine in a campaign/mission, skipping the mainhall.
Wut. Skip the mainhall? What purpose would that possibly serve? That cuts the techroom, campaign switching & lab to name a few. Things I use quite often.
-
At that, I do request that whatever is added here, is accessible in a sane format by the launcher, either in the registry/registry equivalent or in a file. I also ask, that the names and valid values are documented (in the code or otherwise) so that the launcher doesn't need to fumble around in the dark.
im currently thinking of either futzing with the cmdline file the launcher saves now when saving the options or doing another file tho thats still up for discussion
-
As a launcher writer, I am on the fence. We either need to put everything changeable from the game or make nothing changeable and have the launcher directly start the engine in a campaign/mission, skipping the mainhall.
Wut. Skip the mainhall? What purpose would that possibly serve? That cuts the techroom, campaign switching & lab to name a few. Things I use quite often.
I am not saying the idea if fully baked, but it would allow for more/different things to be done without having to deal with the limitations of being in the engine itself.
-
As a launcher writer, I am on the fence. We either need to put everything changeable from the game or make nothing changeable and have the launcher directly start the engine in a campaign/mission, skipping the mainhall.
Wut. Skip the mainhall? What purpose would that possibly serve? That cuts the techroom, campaign switching & lab to name a few. Things I use quite often.
this is a feature id love to have for dev purposes. launch the game directly into the mission your working on, save a ****load of time there.
-
What about the lighting option that are currently *not* supported by the launcher as discrete options?
I'm talking about the lighting parameters usually entered into the command line:
-no_emissive_light
-ambient_factor
-ogl_spec
-spec_exp
-spec_point
-spec_static
-spec_tube
-bloom_intensity
Being able to tweak these in-game (and seeing the result) could be a godsend for mods to achieve a specific "look" (...or for users to make the game look as they want it). Maybe the F3 techroom could be re-purposed to serve as a lighting lab?
-
this is a feature id love to have for dev purposes. launch the game directly into the mission your working on, save a ****load of time there.
Already implemented, try -start_mission. Pass it the name of the mission to start. Seems its not documented in the wiki, will have to do that later.
What about the lighting option that are currently *not* supported by the launcher as discrete options?
wxL is working on that, though we have nothing to show for it yet. But I think they were already in the plan for this menu anyway, even if he will probably have to write a slider control to adjust the ones that require parameters.
-
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.
-
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)
-
***Warning**** -------____The following post may content bad idea____--------
Beeing able to see a preview would be really nice but why not including a background mission, so you can see the result fps wise.
having on the right side of the screen 3 button (skirmish) (usual) (boe) , when a button is 'hit' it loads a the mission in the background and you can see the fps impact of your settings.
The graphic option still rendered on the left side of the screen.
-
***Warning**** -------____The following post may content bad idea____--------
Beeing able to see a preview would be really nice but why not including a background mission, so you can see the result fps wise.
having on the right side of the screen 3 button (skirmish) (usual) (boe) , when a button is 'hit' it loads a the mission in the background and you can see the fps impact of your settings.
The graphic option still rendered on the left side of the screen.
i cringe before the thought of loading a mission OUTSIDE of a mission. its a great idea but not feasible with how the engine handles state and everything and checking framerate is best done in mission anyway i will try though to make the menu accessible in mission somehow
-
The engine is already capable of loading in a mission as the freaking mainhall :p
Whatever solution is decided upon it really needs to be possible to make both the existing interface the new one look the same. The Lab currently looks more ugly than need be because you're stuck with that interface for it.
-
Hmm a mission as a mainhall? Wonder how that turns out in combination with a cutscene'd mission then..
-
Just like you'd expect, I imagine.
-
Whatever solution is decided upon it really needs to be possible to make both the existing interface the new one look the same.
Yeah, definitely. One rather involved solution would be to ditch the old rigid interface entirely and just design a completely new dynamic interface to replace it. Not gonna happen, but just saying. Seems like one of the only ways to do it.
-
i would love too... ^^
After the many things that have been awesomely (not sure about this word ) improved with fsO , the default interface remain the one that would benefit a refresh :)
something easyer to mod, who would not strectch amongst the whole screen (actual menu in triplehead are terrible ^^ )
But yeah i guess it won't happen.
-
Mission as mainhall or as background to a mainhall is a horrible concept. Loading time is increased (ie. instead of normal loading time, it now gets to normal loading time + model reading (if not done previously) + actual mission loading). All with normal error and warning checks which far more often than it should means that debug builds (or any one actually doing debugging) will choke on it.
As for using scripting there currently exists a blank state (scripting state) just for doing interfaces etc. via scripting.
-
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 (http://nukedspace.fsmods.net/svn/trunk/script_include/data/scripts/nukeui.lua) 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? :D
-
Maybe use something like http://berkelium.org (http://berkelium.org),
it would make it possible to create the ui in javascript and html.
I think they are the most future proof way to build ui's today.
-
Hell, then even I could help with the UI :P
-
Just curious: if/when significant changes to the options UI end up happening, would the current options UI have to be retained and made accessible somehow, in order to comply with the Don't Break Retail rule?
-
Just curious: if/when significant changes to the options UI end up happening, would the current options UI have to be retained and made accessible somehow, in order to comply with the Don't Break Retail rule?
Probably. Based on how we have delt with that kind of change in the past, whatever replaces it would have to be functionally identical to the retail version when faced with retail data, and the easiest way of doing that would be to just leave the retail version available.
-
new interface modes would override stock. you really dont want to kill stock since you need it to run in vanilla. this is another reason to go the console route if going with scripting, or pulldown menus going with table based interface configs. generic unskinned varients can be used with vanilla to give the same control.
-
400 lines of code later: PROGRESS!!!
[attachment deleted by a basterd]
-
Woohoo, outlines!
-
Mission as mainhall or as background to a mainhall is a horrible concept. Loading time is increased (ie. instead of normal loading time, it now gets to normal loading time + model reading (if not done previously) + actual mission loading). All with normal error and warning checks which far more often than it should means that debug builds (or any one actually doing debugging) will choke on it.
I didn't say it was a good idea. Just that the engine can already do it.
-
More Progress :D
[attachment deleted by a basterd]
-
i hope these interface elements are scriptable. id hate to see 3 interface systems (stock, this, scripted) running simultaneously because there was no integration.
-
You know, while the new interface is nice and all, there really is nothing stopping us generating the assets for making this as a typical, retail style UI based menu. The interface system isn't all that complicated, and there's precedent for adding new stuff (See assign loadout to wing, the fiction viewer etc. etc.)
It's doable and not a massive amount of work, from a 2d perspective. Not sure about the coded backend, of course.
-
im doing it so the mod groups DONT have to create different kinds of backgrounds and designs for it. There will be a simple table or script that defines the colors and style so adapting will be as streamlined as possible. besides whats stopping me from coding in support for texture skins.
-
that was the idea behind nukui, provide generic, primitive-based ui elements, and if skins were provided that followed some naming convention, then they would be used instead of the procedural graphics. of course doing it in scripting i dont really have a way to use bitmap masks to denote what can and cannot be clicked on (scripting doesnt have a getPixel operation as of yet, and so we cannot use masks in scripted interfaces), and so the bitmaps must conform to the primitives, and that kinda limits what you can do. you pretty much just stick to 2d vector bounding boxes to denote important areas of the interface element, like dragable/moveable areas.
actually i wouldn't mind supporting vector image formats for interface art, as they are scalable and could probably be rendered with opengl. it could also utilize simple textures for fill, provide polygonal masks, and would look pretty good at all resolutions.
-
so are you telling me you are already working on this? how far are you along ? maybe we should work together
-
well mine is scripted and so far i have two kinds of interface elements working (buttons and sliders). you can download the nukui mod from my svn in my siggy and its pretty much a stand alone mod. go to the lab to play with it. right now it just prints messages to the debug console. nukui.lua contains the actual script, and lab_init gives an example of what the interface creator needs to do to setup an interface. its pretty much: call function to set up an element, create event functions, bind those functions to pre-defined events, ???, profit. its still somewhat preliminary and would still require a way to issue interface commands.
i was kind of holding off work on the thing because i was not sure which way the coders would go (do everything in c and use a table to configure the interface vs. do a command interface in c and everything else in scripting and use scripts configure the interface), seems many of the more influential coders would rather just do everything in c even though this was one of the many reasons why lua scripting was added in the first place. the big issue was you didnt want to allow the script to change a setting outside of established range. so i figured the command interface would require a query to provide information about available settings (by which interface elements could be configured), followed by a setting command (which is internally qualified) to actually change the setting. this would be safer than just letting the script brute force an exposed variable.
-
so little progress report to let you guys know how its going on. First a little video: http://youtu.be/0b1lOAPypbc?hd=1
As you can see i got events working i can click and receive mouse overs etc. I'm now moving towards implementing the scripting environment so this can all be used from lua then i gotta think about what options i will integrate and how to do them without crashing the game :P
-
coo'
-
oh goodie so it will be scriptable from the ground up.
-
its more like i give you every feature in the scripting api that you have in C (except adding something to the ui code yourself of course) the ui itself is coded in C and i just expose an API to you in lua that you can use to register elements how you want them and when something happens i call you script back and say hey button id 12 was just mouseovered or clicked or whatever and you have to handle the event.
-
sounds good. thats pretty much how my lua based system would have worked.
-
Thumbs up guys, I'll definitely will be watching this topic. :yes:
Maybe use something like http://berkelium.org (http://berkelium.org),
it would make it possible to create the ui in javascript and html.
I think they are the most future proof way to build ui's today.
Novalogic's DF:BHD through DF:X2 has used an XML based ui for its pre-game menus and some of its in-game menu's too.
I've also heard that several of the new fps games use sometime similar... but I don't know if XML support is worth discussing here.
-
im not a fan of the "me too" xml approach. xml is a great way do dynamically define datasets but not really good to enable dynamic responses i a ui. sure you could define the layout of the ui with xml and script the rest but why dont we just define the layout in the script as well and skip the "me too" part
-
I got the first script hooks for presentation working. Here is the graphics options menu i posted earlier reinplemented in script with the script in question so you can get a feeling for the syntax. Lot of numbers, most of them are the colors for the borders and windows. Im thinking of writing a wrapper in lua so you can use tables to predefine colors. Thing is you have to include this bit of code yourself so i am open for any suggestions that could simplify passing colors to the functions.
[attachment deleted by a basterd]
-
cant wait till it hits trunk, can use it to configure script related things. how will events be handled?
as for the wrapper theres my lua-based table parser which is quite functional right now. though there is still much room for improvement. especially needs better documentation. i intent to have a qualification system in place that enforces certain values and ranges of values of a specific type and generates proper error messages for modders. as usual my svn should have the latest version of the script under script include. i posted it somewhere on the scripting forum but its probably an old version. as of right now i dont know if anyone is using it. id love some feedback and bug reports from other scripters to help improve it.
http://nukedspace.fsmods.net/svn/trunk/script_include/data/scripts/parser.lua
-
i kinda just had an idea about how to better handle apperance of scripted elements. what if we have table based style sheets that define the default and alternate styles (including color data and bitmaps) for the various interface elements, so that scripting can just needs to concern itself with things like form layout and and event handling. this way a mod can define the interface style and if that mod uses any scripted forms then they would also use the same style in order to keep the interface elements somewhat uniform. have an interface style object to use as an argument to the button registering function, you could load any style defined in the table. you could probably also have ui functions to create styles from scratch in the code. this would eliminate a lot of redundant data in the script and make the ui scripts a little bit easier to read.
-
good idea i thought about that myself but was too lazy to implement it till is saw the numbers mess that i created.