[deathspeed]

And yet this whole thread started because we have too many command-line options and an in-game options menu is one way to cut back on them.

At one point I thought the discussion was going toward using a menu to supplement the command-line options, not supplant them.  From my player-only (non-coder) perspective, this could be very helpful for people like me, who have been using FSO for years but don't have the slightest clue about what flags are available and what they do.  It would probably be even more helpful for new players who have found their way here from Steam or GOG.  Don't put things on it that are dependent on engine startup, or that potentially break things or tend to generate a lot of support requests.  Just my two cents.   

[chief1983]

Yeah, I mentioned in a previous comment that we would need to vet every option for whether it currently can be modified after game load without breaking things.  And certain options don't really make sense to be configurable in game either I think, so we'll probably always have some command line options around.  And I think we should maintain, if possible, command line options for pretty much anything.

[m!m]

All these options would be saved to some stable location anyway so some options could only become effective after restarting the game. I don't like the idea of keeping commandline options that users need to change. We always will need the -mod option but that will be set by the launcher. Everything else should be as configurable as possible with the exception of a few troubleshooting flags that are only needed in exceptional cases.

[Phantom Hoover]

Since you'll need to store the options in a file anyway you could always replace the relevant command line flag with some sort of in-launcher editor for that file. This would also help with getting rid of FSO's godawful system of reading command-line flags straight from a file as a way of keeping persistent options.

[Swifty]

I've been kind of holding my tongue on this because I don't like raining down anybody's parade but I'd be lying if I said that I wouldn't have any objections to having a full blown HTML/CSS/Javascript stack running in the engine.

HTML and CSS is probably now the golden standard for laying out UIs these days but do we honestly need all the features that HTML offers? Or CSS? How do we handle <a hrefs>? Or tables? Or weird tags that aren't pertinent to our engine like <h1> or <title>. Nor am I comfortable introducing yet another scripting language and introducing a whole slew of new bindings that interface with the engine that we have to maintain. Keeping the Lua interface up to date and bug free is a headache in of itself.

I feel if we are going to go in the direction of HTML and CSS, we should at least use an existing library that's been tailored for game UIs specifically that provides a subset of the HTML and CSS specification that we actually need. FSO doesn't need a full blown HTML5-compliant web renderer attached to it. Why don't we use something like libRocket and use our existing Lua system to interact with the markup? http://librocket.com/.

[The E]

I feel if we are going to go in the direction of HTML and CSS, we should at least use an existing library that's been tailored for game UIs specifically that provides a subset of the HTML and CSS specification that we actually need. FSO doesn't need a full blown HTML5-compliant web renderer attached to it. Why don't we use something like libRocket and use our existing Lua system to interact with the markup? http://librocket.com/.

That's ... a really good question. I guess the answer might be "Because none of us heard of libRocket before"

I do like what I am seeing there, though. Especially the whole MIT License thing.

[m!m]

I've been kind of holding my tongue on this because I don't like raining down anybody's parade but I'd be lying if I said that I wouldn't have any objections to having a full blown HTML/CSS/Javascript stack running in the engine.

HTML and CSS is probably now the golden standard for laying out UIs these days but do we honestly need all the features that HTML offers? Or CSS? How do we handle <a hrefs>? Or tables? Or weird tags that aren't pertinent to our engine like <h1> or <title>. Nor am I comfortable introducing yet another scripting language and introducing a whole slew of new bindings that interface with the engine that we have to maintain. Keeping the Lua interface up to date and bug free is a headache in of itself.

All rendering would be done according to the W3C standards as chromium handles that.
JavaScript will also not be running "inside" the engine as chromium uses a different process for rendering and executing JavaScript. Currently the JavaScript API will actually be exposed by Lua to keep the engine interface and to allow modders to implement their own API functions.

I feel if we are going to go in the direction of HTML and CSS, we should at least use an existing library that's been tailored for game UIs specifically that provides a subset of the HTML and CSS specification that we actually need. FSO doesn't need a full blown HTML5-compliant web renderer attached to it. Why don't we use something like libRocket and use our existing Lua system to interact with the markup? http://librocket.com/.

libRocket hasn't been updated in 4 years while chromium/CEF is actively developed. I don't want to introduce yet another library that the SCP will have to maintain.

[The E]

libRocket hasn't been updated in 4 years while chromium/CEF is actively developed. I don't want to introduce yet another library that the SCP will have to maintain.

Actually, libRocket's git repo shows activity as recently as April 26th, 2015.

[m!m]

Oh, I missed the link at the end of the page...
The API seems to be quite nice, did anyone actually work with that library and can tell us what HTML features it supports?

[jr2]

If you knew how FS2's menu system works, you'd know how hilariously infeasible this is.

Look, jr2, I appreciate your enthusiasm, but please try to remember that if a solution seems really simple and we haven't used or discussed it, chances are that it's not as simple as you might think it is.

Heh, maybe I like the HTML menu option because I can probably poke through that and semi-understand / modify HTML at this point, like I can sort of understand / modify table files.  And I'm sure there's others in my boat (that can at least Google / play with HTML until they get the result they want).

But whatever you guys end up going with will be great. 

[Goober5000]

I've been kind of holding my tongue on this because I don't like raining down anybody's parade but I'd be lying if I said that I wouldn't have any objections to having a full blown HTML/CSS/Javascript stack running in the engine.

HTML and CSS is probably now the golden standard for laying out UIs these days but do we honestly need all the features that HTML offers? Or CSS? How do we handle <a hrefs>? Or tables? Or weird tags that aren't pertinent to our engine like <h1> or <title>. Nor am I comfortable introducing yet another scripting language and introducing a whole slew of new bindings that interface with the engine that we have to maintain. Keeping the Lua interface up to date and bug free is a headache in of itself.

I feel if we are going to go in the direction of HTML and CSS, we should at least use an existing library that's been tailored for game UIs specifically that provides a subset of the HTML and CSS specification that we actually need. FSO doesn't need a full blown HTML5-compliant web renderer attached to it. Why don't we use something like libRocket and use our existing Lua system to interact with the markup? http://librocket.com/.

Thank you.  I had raised similar concerns in the past but they were not well received, probably because I didn't have any alternatives to suggest.  But libRocket is worth deeper investigation.

[BirdofPrey]

I've been kind of holding my tongue on this because I don't like raining down anybody's parade but I'd be lying if I said that I wouldn't have any objections to having a full blown HTML/CSS/Javascript stack running in the engine.

HTML and CSS is probably now the golden standard for laying out UIs these days but do we honestly need all the features that HTML offers? Or CSS? How do we handle <a hrefs>? Or tables? Or weird tags that aren't pertinent to our engine like <h1> or <title>.

I've been trying to say pretty much the same thing, but what I keep getting back seems to be along the lines of "unless you have something made of distilled awesome to suggest, we are just going to default to a full browser stack because it's comfortable and familiar rather than actually exploring other (potentially better) options"

(the examples I have been giving of the different types of things out there seem to keep getting taken as suggestions for what we should be using, when the main point I have been trying to make is a full browser stack is wholly unnecessary and FFS do some research and actually check to see what is the best solution rather than just settling, so here's a couple of ideas for where you might start looking)

A full browser stack isn't needed, because most of the functions provided by HTML aren't needed or useful for our purposes.
I can agree to a pared down library that uses HTML syntax but is pared down to only what is actually useful for our purposes.  I can't do any programming of the FSO engine, but I will at least look at that in some detail when I get the chance.


I obviously have no qualms raining on someone's parade if I think it might make things work better.
I'm kind of a dick like that.

Gmail.

Not exactly what I was looking for, thought you meant fully featured desktop programs.  I've seen tons of web apps for various different things, but they tend to be fairly lightweight applications whose primary purpose is interaction with web resources.

This is an antiquated notion of what a web browser, html, css and javascript are for. All of these things have made massive strides towards making it possible to build applications on them in recent years.

See above for examples of stuff that is useless for our purposes.  I know the W3C has expanded HTML CSS and javascript since their aim is to replace platform specific apps with web apps and depreciate browser pugins, so you can, for instance, open a browser rather than the app store to interact with things, and watch videos without flash.

Good goals, but, again, the language set contains WAY more than we would ever need to use, so you shouldn't be trying to use ALL of it.
Also note, FSO is not a web app, it's a rather intensive desktop application, and the suggestion is to use HTML rendering as a subsystem inside it rather than being the framework the program is actually built with.

There is no reason to invoke the HTML renderer unless it is specifically requested to run by a mod. Also, there are no real limitations on memory use; right now, the most complex FSO missions rarely use more than 2 GB of memory. We have some headroom to play with in that regard, I believe.

fair enough, just felt I had to bring it up since the early discussion was retail compatibility, and one reason to run retail is lack of computing power.



We may be over-thinking the entire thing, though.  The thing most familiar to FSO modders is going to be tables, and another possibility would be to distribute interface artwork in a similar manner to the assets already used, but replace the actions hardcoded into the engine with a table that says what space each button takes up, and what it does.

[m!m]

Thank you.  I had raised similar concerns in the past but they were not well received, probably because I didn't have any alternatives to suggest.  But libRocket is worth deeper investigation.

On thing to consider with libRocket is that all animation or user input handling would need to be done through Lua (as hardcoding such things is not an option) whereas most people familiar with HTML have at least a fundamental understanding of JavaScript which would be used to control the UI.

A full browser stack isn't needed, because most of the functions provided by HTML aren't needed or useful for our purposes.
I can agree to a pared down library that uses HTML syntax but is pared down to only what is actually useful for our purposes.  I can't do any programming of the FSO engine, but I will at least look at that in some detail when I get the chance.

As said before chromium has already been integrated into the engine, if someone would implement libRocket support we could evaluate the pros and cons of both solutions.
The only reason I see not to use chromium are potential issues with memory and computing power but every machine capable of running he MVPs will also be able to handle two more browser processes...

Gmail.

Not exactly what I was looking for, thought you meant fully featured desktop programs.  I've seen tons of web apps for various different things, but they tend to be fairly lightweight applications whose primary purpose is interaction with web resources.

Atom

We may be over-thinking the entire thing, though.  The thing most familiar to FSO modders is going to be tables, and another possibility would be to distribute interface artwork in a similar manner to the assets already used, but replace the actions hardcoded into the engine with a table that says what space each button takes up, and what it does.

That would require an insane amount of work as the system would need to be as flexible as possible so why should we invest that much effort if HTML is a much better solution?

[The E]

We may be over-thinking the entire thing, though.  The thing most familiar to FSO modders is going to be tables, and another possibility would be to distribute interface artwork in a similar manner to the assets already used, but replace the actions hardcoded into the engine with a table that says what space each button takes up, and what it does.

That would require an insane amount of work as the system would need to be as flexible as possible so why should we invest that much effort if HTML is a much better solution?

I completely agree. Sticking with syntax that modders are familiar with through exposure to the engine is good. But not when it requires reinventing the wheel; after all, in terms of expressiveness, such a table would be nothing but a subset of the functionality HTML gives us.

[BirdofPrey]

Thank you.  I had raised similar concerns in the past but they were not well received, probably because I didn't have any alternatives to suggest.  But libRocket is worth deeper investigation.

On thing to consider with libRocket is that all animation or user input handling would need to be done through Lua (as hardcoding such things is not an option) whereas most people familiar with HTML have at least a fundamental understanding of JavaScript which would be used to control the UI.

  Well it does mention it can work with other languages, though haven't checked to see how difficult it would be.
That said, I wouldn't say knowing Lua is asking that much.  It seems to be fairly common in many modding circles.

My initial impression is that the majority of modifications modders would make to the UI would be graphical in nature anyways rather than actually reprogramming the interface  since most of the time it would be changing the look and feel of the interface rather than it's actual functionality.  Hopefully they shouldn't have to do much script programming, just invoke the right commands.  For modularity reasons, I'd also think most of the scripting would not be contained within the HTML code (my .js is a bit rusty, though, so maybe I'm mistaken)

On a side note, would a UI overhaul cover mainhalls as well?

I also saw a comment in the chromium thread about using it to drive .svg rendering, though I'm not sure that'd be preferable to just rendering the graphics in the game engine rather than calling a separate layout engine.  Not sure if librocket would be useful for rendering the HUD (Needs more research).

We may be over-thinking the entire thing, though.  The thing most familiar to FSO modders is going to be tables, and another possibility would be to distribute interface artwork in a similar manner to the assets already used, but replace the actions hardcoded into the engine with a table that says what space each button takes up, and what it does.

That would require an insane amount of work as the system would need to be as flexible as possible so why should we invest that much effort if HTML is a much better solution?

I completely agree. Sticking with syntax that modders are familiar with through exposure to the engine is good. But not when it requires reinventing the wheel; after all, in terms of expressiveness, such a table would be nothing but a subset of the functionality HTML gives us.

Ah, Ok then.

[m!m]

Well it does mention it can work with other languages, though haven't checked to see how difficult it would be.
That said, I wouldn't say knowing Lua is asking that much.  It seems to be fairly common in many modding circles.

My initial impression is that the majority of modifications modders would make to the UI would be graphical in nature anyways rather than actually reprogramming the interface  since most of the time it would be changing the look and feel of the interface rather than it's actual functionality.  Hopefully they shouldn't have to do much script programming, just invoke the right commands. 

Lua isn't as common here. Most modders don't know Lua and without prior programming knowledge it's a bit hard to learn. JavaScript is in a similar situation but there are a lot of solutions out there which require much less programming knowledge than anything we could create with Lua.

For modularity reasons, I'd also think most of the scripting would not be contained within the HTML code (my .js is a bit rusty, though, so maybe I'm mistaken)

Where the scripts are stored depends on the modder as HTML is capable of including scripts in the source code or just reference them. For libRocket the Lua source would always be separate.

On a side note, would a UI overhaul cover mainhalls as well?

Yes.

[BirdofPrey]

I was under the impression Lua was supposed to be easy to learn (never learned it myself, mind you).  It's derived from C isn't it?
Still, how much knowledge would a modder need to just call a function that's already been written for the interface, and what sort of cases exist for a modder having to add additonal functions?

Regardless, as much of the script should as possible, should probably be kept out of the HTML file so modders can rewrite that without having to touch the majority of the scripting.

if someone would implement libRocket support we could evaluate the pros and cons of both solutions.

Dear god, NO!
Evaluate as many of the pros and cons as possible BEFORE actually doing the work, so you don't waste time.

[AdmiralRalwood]

if someone would implement libRocket support we could evaluate the pros and cons of both solutions.

Dear god, NO!
Evaluate as many of the pros and cons as possible BEFORE actually doing the work, so you don't waste time.

The path of minimal time-wasting is to just use Chromium, seeing as how it's already been successfully integrated with the engine.

[pecenipicek]

No offense, BirdOfPrey, but the relevance of your contributions to this discussion is dubious at best. You are saying "we should, it should, oh but i think this blah blah blah". Your "contribution" to this thread is borderline worthless.


Yes, i'm aware, mine isnt much better but you have made more than 4 posts worth of useless, unsubstantiated claims so far.

[edit] also, read one of your previous posts, you mention using SVG + JS. Now that, my friend, is truly spoken like somebody who has never worked with any of it. Please stop "brainstorming" and "throwing stuff at the wall and seeing what sticks". [/edit]




Now, for what its worth, throw me into the "chromium" part of the discussion, simply because there has been an implementation of that sorta made already. Someone has to make the first step otherwise half-solutions will stay.

Personally, i'm all for burning JS and forgetting it ever existed, but hooking lua to support output/manipulate css/html in non-roundabout/retarded ways?
Yeesh...

Also, the claim for the lovely "oh but JS is simpler, there are done solutions, etc etc", its just going to lead to rampant copypasta of crap from StackOverflow etc. Y'know, just like regular JS.

Also, consider how long has LUA been in the engine. Now consider whats the uptake of LUA scripting in mods. We have Axem, Axem, Axem, Spoon and small stuff around the rest. And thats in the very recent years.

No, i dont know where i'm going with this.
I'm not a fan of HTML/CSS and consider them to be the ****tiest solutions possible. But considering that alternatives are "learn yet another custom domain specific language", i'm strongly in favor of HTML/CSS and calling it quits.


PS, first one to pull jQuery into FSO gets an international slap from me

Oh, I missed the link at the end of the page...
The API seems to be quite nice, did anyone actually work with that library and can tell us what HTML features it supports?

from their github

libRocket uses the time-tested open standards XHTML1.0 and CSS2.0 (while borrowing features from HTML5 and CSS3), and extends them with features suited towards real-time applications.

[Phantom Hoover]

He's definitely right about HTML not being a system for defining UIs, though. HTML is a document markup language; it's up to the browser to provide a UI, which can differ radically between browsers.