[Unknown Target]

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.

[General Battuta]

Mission mainhalls are already doable (and done), the load times are just kinda irritating.

[The E]

Yep.

http://www.hard-light.net/forums/index.php?topic=56122.msg1259873#msg1259873

[Nuke]

i think this is one of the first things that was demonstrated with lua. i think its even older than hud pong.

[Unknown Target]

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?

[The E]

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.

[Unknown Target]

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?

[The E]

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.

[Unknown Target]

So then why not...add those functions? The idea has merit and would improve the game a lot in many ways.

[The E]

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?

[Nuke]

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.

[Fury]

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

[Nuke]

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.

[Unknown Target]

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.

[newman]

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.

[Goober5000]

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.

[newman]

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..

[docfu]

(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.)

[General Battuta]

New HUD code has already been written which allows a lot of HUD customization.

[The E]

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.