Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Unknown Target on December 12, 2010, 10:04:56 pm
-
Man it's been so long since I've posted here I don't know if it's still the right forum for a feature suggestion.
Anyway, I proposed this awhile back, but maybe you folks would be more willing to do it now, what about an interface standardization system, like a simple "new game" "Load campaign" "tech room" text (you could probably do this with LUA, and then have a mission be able to be displayed in the background running through a camera, or a video, or something like that - basically like Source games. In fact, I totally could think of HOW to do this in LUA conceptually but couldn't write it.
Anyway, I think something like this would do great to allow mods to get great looking, unique interfaces without having to redo all of the normal menu stuff, at least for the main menu and then branching out from there.
-
Mission mainhalls are already doable (and done), the load times are just kinda irritating.
-
Yep.
http://www.hard-light.net/forums/index.php?topic=56122.msg1259873#msg1259873
-
i think this is one of the first things that was demonstrated with lua. i think its even older than hud pong.
-
I'd like an option to enable it as default, however. I don't know how to do LUA. Is that possible? For the less code-inclined of those amongst us?
-
Something like this should never be the default. As General B said, the loading times are atrocious (as the mainhall mission has to be reloaded everytime you enter or leave the mainhall). The script, as posted, is enabled by default if saved as "mainhall-sct.tbm" in a tables folder in your load path.
Even so, it's going to need a coder to tweak it so it can be used with FS2 (the version I posted there was made to work with TBP). So, no. Without some more codework, this won't be easy to set up or work with.
-
I'd still like it so that I could release standalone mods without having to redo the entire interface, are there any other options for doing that?
-
No. Not at this time. Scripting does not have access to the necessary functions to build a full UI; until it does, there's no way around the thousands of interface files. Sorry.
-
So then why not...add those functions? The idea has merit and would improve the game a lot in many ways.
-
Because it's tedious work that is thoroughly unsexy? Because designing this in a way that it doesn't break stuff (and, more importantly, doesn't allow a bad script to break stuff) is a non-trivial exercise? Because even if all that was done, you'd still have to write the necessary scripts to stitch it all together?
-
as i said in other threads, id like to see a console interface, much like what you would find in quake/unreal engines. aside from a fast text based interface for tweaking game settings and displaying internal messages (much like the contents of the debug console), it would also provide a scripting interface to them as well, you could post a command to the console and then gain access to the returned strings. you might ask for information about a specific settings, like the default and the allowed range of values, and set up the gui based on that information, and if the setting is changed in the gui, a command can be issued to the console.
for gui you could do a pure scripted gui (i started one), or you could use wmcgui (what the lab uses) functions that have been made accessible to scripting.
Because it's tedious work that is thoroughly unsexy? Because designing this in a way that it doesn't break stuff (and, more importantly, doesn't allow a bad script to break stuff) is a non-trivial exercise? Because even if all that was done, you'd still have to write the necessary scripts to stitch it all together?
this is the other issue, even with the system in place, it would still be a huge undertaking as far as scripting goes. you would need to script a complete gui, provide graphics for it, test it on every resolution possible, debug it, and make damn sure it doesnt screw anything up. thats the idea behind the console interface, because it allows a command from the script to the engine to fail non-catastrophically. if the command issued to the console is invalid, then it posts an error to the console.
-
I'd like to remind you lot that Flaming Sword released interface templates to make creating new interface much easier than it used to be.
http://www.hard-light.net/forums/index.php?topic=67991.0
-
I'd like to remind you lot that Flaming Sword released interface templates to make creating new interface much easier than it used to be.
http://www.hard-light.net/forums/index.php?topic=67991.0
that really only allows for a re-skin. it doesn't change the interface layout or capabilities. its a nice tool if you want to create replacement interface art for a tc in a hurry. but it doesnt improve upon what the interface can do.
-
It would be akin to rewriting the render code to switch the game from DX to OpenGL, yes, but it would provide just as many benefits.
-
While I appreciate the fact it would be a difficult, non trivial task, what it would bring to the table is equally non-trivial. The interface is definitely one of the most obsolete parts of fso these days, and the effort to bring it up to snuff should definitely be worth it, and much appreciated by many projects.
-
There are a large number of feature requests, bug reports, and maintenance issues placing demands on the SCP's time. The implementation of a feature such as this is far, far down on the priority list.
And the interface is just fine as-is. It works, it's moddable, and it has very few, if any, bugs. Contrast this with sections of the codebase like the collision code or even the asteroid code. Those are badly in need of rewrites, yet there is currently no manpower available to rewrite them.
Consider that even with the pilot code, which was not only one of the most frequently requested upgrades but also one of the hardest, it has taken nearly eight years before someone finally finished a robust, capable, and comprehensive upgrade. The multiple ship docking feature is peanuts compared to it.
-
Fair enough, you guys do know a lot better than me how much work this is. Just wanted to give support to an idea I thought would be rather nice if implemented. We can certainly live with the interface as is for the time being. Maybe some day..
-
(I realize this topic is 8 months old but I figured best to post under an existing topic than create a new one.)
Just out of curiosity, has an interface upgrade along the lines of Mac OS's Dashboard ever been suggested?
(Waiting to get hit with empty beer cans and bottles.)
What I mean by this is: maybe it would be easier to create a new interface system that simply renders itself on top of the old one. It doesn't need to run constantly, only when activated (like a console) with mouse-movable modules instead of hardcoded displays.
If done correctly, it should allow for newer interfaces to be built (including in-game huds) without breaking old code. I'm thinking something along the lines of how post-processing is achieved.
(If it already exists then never mind. It's just a suggestion. I know you are busy rewriting that asteroid code.)
-
New HUD code has already been written which allows a lot of HUD customization.
-
Uhh, what?
No, I do not think that will work. The dashboard is a widget layer; what we will need to do is recode the desktop, as it were. It's a much larger piece of work. And given that, as Goober said, there are areas of the code that are more deserving (or rather, more in need) of work, the interface is quite definitely on the backburner for now.
And yeah, the HUD is already as customizable as it can be, I believe.
-
Okay. Being new to the board I'm reading a lot of older posts but it's very hard to get a feel of the games "current state."
Having installed antipodes/mediaVP's/BP/BP WIH and played through a lot of recommended campaigns it's easy to see where some of the improvements are (in game graphics is the easiest) but it's hard to see what's available (Alternative HUDs/ cockpits/ launchers) to get a feel for "What's right." (I.e. things start to look awesome.)
At the same time though, the overall look of the interface and the HUD haven't changed much since the game was originally released and a lot of the older mods have rather dated graphics/CG so as a new user it makes me feel like I'm missing something.
Rewrites like Doomsday (for Doom) still use the original games graphics 100% and keep a solid feel but it also has a console on top where you can change additional settings and...more importantly...easily see all of the new options rather than looking through the Forums to see what things have been updated, which can take hours after reading through irrelevant comments.
For me, as a new guy, these forums are "part of Freespace's interface" so to speak. While they contain a wealth of information it's spread out over a huge number of pages spanning an even larger number of posts, many of which become irrelevant with time.
(I've spent about 3 hours reading old posts just tonight.)
...
So...
When I suggested a Widget style interface to be put on top of the game (mainly for the HUD and game options) it's because it sounds like a plausible approach to adding new in-game adjustments without breaking existing code. I'd really like, for instance, to be able to see what different lighting profiles look like using sliders in real time or reorganize the HUD using a mouse.
Anyway, I hope that clears up why I made the suggestion.
-
Actually people have looked at using the shiplab as an ingame graphics option menu. But a lot of the stuff like the new HUD code is going to be available in the next release (3.6.14), so you'd have to get a nightly build to use it right now.
-
The existing FreeSpace gui elements are widgets, and they have been since FS1. They're in a folder in the source tree called snazzyui. They are what I used to compose the additional screens such as the scrollable command briefing, the fiction viewer, the apply-loadout-to-wing option, and several additional popup windows.
So it is certainly possible to build onto the UI if desired. It's just that, as I said earlier in the thread, it's a very low priority. People are way too obsessed with the graphical appearance of the engine and depressingly unconcerned about the parts that are in dire need of attention.
-
im more concerned with the functionality of the interface over the outright appearance of it. take the options menu for example, id love to have a more up to date set of options that can be changed on the fly, especially graphics options. setting things in the launcher might be all fine and dandy, and you might have it set up to give you good performance for your typical missions. but there are those epic missions that sometimes require reduced settings to get any kind of framerate out of, be nice to hit f2 and be able to quickly switch off normal maps for example, instead of aborting the mission, quitting the game, and restarting with new settings. id be happy if freespace had a console with a command line interface for advanced options. menus might be preferable, since such an interface already exists (lab ui). id just like to see other ways of setting game settings other than launcher flags, regedit, and tables, for options capable of on the fly tweaking.
-
From what I heard, the problem here isn't about the interface, but the order in which stuff are loaded in FSO. When you reach even just the player menu, all the launcher settings are already loaded and applied, and it's not possible to change them anymore. Having them changeable on-the-fly would require some heavy re-coding.
-
From what I heard, the problem here isn't about the interface, but the order in which stuff are loaded in FSO. When you reach even just the player menu, all the launcher settings are already loaded and applied, and it's not possible to change them anymore. Having them changeable on-the-fly would require some heavy re-coding.
really it depends on the settings. some things do need to be handled at game init, but not all. if its something that affects the textures sounds or other media that are currently loaded, youre looking at at least a mission re-init, or at most a restart of the game. if your changing a variable that is used every frame to do something like set the mipmap distance, you could probably change it on the fly.
-
Rewrites like Doomsday (for Doom) still use the original games graphics 100% and keep a solid feel but it also has a console on top where you can change additional settings and...more importantly...easily see all of the new options rather than looking through the Forums to see what things have been updated, which can take hours after reading through irrelevant comments.
So I mostly just lurk on these boards, but I think maybe my experience as someone relatively new to HLP might be useful here. I understand that an ingame console is a massive undertaking and not high on the priority list. However, I do think that it would be useful (and much more doable) to make it a little easier to find graphics and/or engine tweaks if there was some kind of centralized place they could be posted (with a note about whether they are stable or still being tested). I've found a number of these over the past year, but often it requires a lot of searching on the forums and sometimes a question or 2 asked in IRC to get them. It would seem the most logical place for something like this might be a page on the wiki with links to (files or mods in some cases, just instructions on how to turn them on in others) or the board threads regarding those tweaks. Another option would be a sticky somewhere.
Please don't get mad or defensive if this suggestion is either unreasonable or is already in effect. Just a n00b making a suggestion here. This community and project is fanfreakingtastic. :yes:
-
We do plan on adding a new interface screen accessible off the mainhall similar to the F3 Lab where you can adjust all the stuff that is currently controlled by custom flags and the like.
-
thats good to hear