Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Phantom Hoover on May 04, 2015, 06:53:10 am
-
FSO also has some pretty questionable command-line options already, like the dual scanlines or the 3D radar.
-
FSO also has some pretty questionable command-line options already, like the dual scanlines or the 3D radar.
Is that an argument for keeping an IBX commandline option, or an argument for getting rid of it and both the aforementioned?
-
I read it as an argument for not adding more stupid things to the commandline.
Command line options have their place but far too often we've allowed things to remain in the command line that have absolutely no business being there.
-
Indeed. I once suggested moving some of those options to mod.tbl or hud.tbl and was quickly shot down because people couldn't handle the idea of playing a mod where the creator didn't enable dual scan lines... :rolleyes:
This is no different. Dragon is afraid of change despite the stacking evidence that this change is extremely minimal, bordering unnoticeable.
-
Yep and when someone starts pushing for this sort of silly change, we should push back. Cause while I agree with you about sticking such things in a table, and I couldn't give a stuff about people who think that sort of thing should be a user option, if we were to change it now, we would have (hopefully minor) problems with the launcher reporting unknown commandline entries. Better to stop nonsense ever becoming a commandline in the first place.
-
Indeed. I once suggested moving some of those options to mod.tbl or hud.tbl and was quickly shot down because people couldn't handle the idea of playing a mod where the creator didn't enable dual scan lines... :rolleyes:
No, that's reasonable. These are preferences to set by the user, not by mod authors; they should be somewhere in the ingame HUD settings.
-
Ideally, that's where they'd be, just as a lot of other switches should be accessible in-game.
However, to the best of my knowledge, noone has started something like that yet.
-
Indeed. I once suggested moving some of those options to mod.tbl or hud.tbl and was quickly shot down because people couldn't handle the idea of playing a mod where the creator didn't enable dual scan lines... :rolleyes:
No, that's reasonable. These are preferences to set by the user, not by mod authors; they should be somewhere in the ingame HUD settings.
Well, I'm going to disagree knowing full well that this is the internet where you don't actually listen to others, you just entrench... but whatever. I don't have a horse in this race other than to clean up the over-filled commandline.
Most (not all) of these commandline features were implemented in the Wild West era of FSO when all kinds of things were put in the commandline. If they were created now, they would most definitely be put in a table and no one would bat an eye. Everyone is so used to them being a "user option" that they can't stand the idea of letting a mod creator to choose between single and dual scan lines. (Dear lord, why does anyone ever care this much about a scan line thing... thank you internet.) I would argue that mod creators should have some degree of choice for changing some of these settings to fit the style of their mod...
There is no way I'll believe anyone who insists that dual scan lines or flash upon warp are game breaking to the user experience. I just don't buy it. The biggest argument for users is 3D radar and maybe rearm timer... possibly 3D warp, but I'm not sold on that. Models for ship/weapon selection? That one I absolutely believe should be modder choice (and to an extent already is if the modder doesn't make icons).
But now I'm waaay off topic. My original point was that cache files don't need a commandline option because it's been proven that this speed stuff is negligible. Which is all I was wanting to see with my original hesitation.
-
So what you're really saying is that you don't believe FSO should have any user-configurable options? I mean take the orb radar: some people like it, others prefer the original 2D one. It's insane to have mod authors setting it on a per-mod basis! The problem is that right now in FSO it's a choice between tables or the command line for any and all miscellaneous settings, when neither are really appropriate. It'd be a significant amount of work to properly extend the ingame settings to cover that kind of stuff and I understand why it's low on the priority list, but pretending everything's fine as it is gains us nothing.
-
So what you're really saying is that you don't believe FSO should have any user-configurable options? I mean take the orb radar: some people like it, others prefer the original 2D one. It's insane to have mod authors setting it on a per-mod basis! The problem is that right now in FSO it's a choice between tables or the command line for any and all miscellaneous settings, when neither are really appropriate. It'd be a significant amount of work to properly extend the ingame settings to cover that kind of stuff and I understand why it's low on the priority list, but pretending everything's fine as it is gains us nothing.
:wtf: That's... not at all what I said...
I... Oh whatever. You're on your own, dude.
-
The new index buffer generation code is actually in the soft shadows and deferred lighting pull request. However, I'm realizing it might be prudent to separate that and the microsecond resolution profiling code into separate pull requests.
As for making IBX files a command-line option, no, I'm going to strip out the IBX file code. The IBX file generation code ended up having two code paths for generating vertex attributes for submodels. When I created the GPU submodel transformation code, I only updated one of those code paths because it wasn't clear that the index buffer code necessitated two different paths. As a result, weird rendering bugs started occuring when cache files were initially being generated and I couldn't find the problem until I produced this fix.
So no, I don't want to maintain two different code paths anymore. Let's reduce the entropy of code and minimize the potential for bugs. Let's keep it clean.
-
Any way to easily make an in-game 'menu' w/out interface art temporarily?
Like, press shift-F2 to bring up the alternate, barebones config menu? Then when it's done being created, map it to the regular F2 menu instead.
Or replace the system with a parallel interface art that is more easily customizeable with simple or complex themes. That's what is happening eventually, right? As in, we aren't redoing the current in-game UI, but replacing it with a better, easily updated / maintained / skinned, visually identical/upgraded (for FS1/2 campaigns) in-game UI?
-
FSO can't break retail. That means no messing with interface, because the original art still needs to be sufficient for running FSO. Unless some way of getting around that is found, command line is here to stay.
The biggest argument for users is 3D radar and maybe rearm timer... possibly 3D warp, but I'm not sold on that.
3D warp might have used to be a performance option. There certainly used to be a time where such a thing would matter. Regarding the others, I very much like them where they are. Dual scan lines are not a big deal (though they are nice), but what is really important is the 3D radar. Personally, I can't stand it. If a modder tried to force me to use that, I'd probably have to edit the mod to get an actually usable radar back. Some people think otherwise, but that's why it can be toggled. FSO needs more user customization options for things like that, not less. Minor visual things that don't affect gameplay, but which some people like one way, some the other.
-
FSO can't break retail. That means no messing with interface, because the original art still needs to be sufficient for running FSO. Unless some way of getting around that is found, command line is here to stay.
The MVPs exist, you know?
-
FSO can't break retail. That means no messing with interface, because the original art still needs to be sufficient for running FSO. Unless some way of getting around that is found, command line is here to stay.
By that logic the lab feature can't exist.
jr2 does have a good idea, one that I'm sure has been mentioned before, using something similar to the lab's code to generate an interface on the fly. I don't think anyone has shown any interest in doing something along those lines so far though.
-
A new interface configuration screen was one of Taylor's unfinished projects, but then he got burned out.
Stuff like -dualscanlines could be put in hud_gauges.tbl, since that didn't exist at the time Phreak added that feature (which was one of the very first things added to FSO IIRC). But IMHO the 3D radar should be user preference.
-
As I recall, Valathil was once working on an in-game UI that could even control lighting settings.
-
...but what is really important is the 3D radar. Personally, I can't stand it. If a modder tried to force me to use that, I'd probably have to edit the mod to get an actually usable radar back. Some people think otherwise, but that's why it can be toggled. FSO needs more user customization options for things like that, not less. Minor visual things that don't affect gameplay, but which some people like one way, some the other.
I disagree about 3D Radar. It's not so good with just blips, but with radar icons, it works rather well. Unknown contacts that can't be locked are a little harder, but can still be deciphered with some effort.
-
Unknowns (for me at least) require pitching and yawing a bit to see beyond the center "yourself" that gets in the way -- a few times back and forth and I can usually gather the general idea of where something is.
Honestly, I would love it if you could flip 2D/3D on the fly, as sometimes a glance at 2D would be nice (back when I was playing a lot I always flew with 3D on but sometimes wished I could toggle just for a second or two).
-
You know... with the new HUD.tbl stuff, a modder could probably SEXP that up pretty simply.
-
That would be really cool.
-
What sort of interface art change would be needed to add most of the FSO command line options to the in game menus? I had started some work on making the menus higher resolution and wide screen before being told the game couldn't handle that.
I'm already hoping for a better interface for MVP use, but even without that, I at least have a work flow set up to make and modify the menus.
-
To be honest, I think a procedurally generated screen would be easier, otherwise you have the problem of needing to distribute artwork to work with retail data. While that can be embedded into the source, it's not very elegant and bloats the size of the source. I think the current idea is to use something like the F3 lab framework for a new options menu.
-
Not sure why we would need new screens for retail. That shipped with a UI, the same one we're complaining about now. Though, admittedly I don't understand what retail has to do with it at all. When people say don't break retail I always assumed it meant the original campaign should work right. No matter what we do adding more settings is not retail.
Anyways, I agree a render on demand UI is a good idea. As I mentioned, I did some work to make upgraded assets, but right now it's going to leave me with separate assets for 4:3 16:9 and ultra wide screen which while easy to create, is a needless duplication of assets. Being able to generate from image elements would be much better.
I know there's been some talk of using HTML, but I wonder why we would use a Web format rather than a format specifically designed for UIs.
-
Procedurally generated with optional add-on artwork? (Like a MediaVPs for the menu).
That seems a bit much work for just a menu, though, if procedural can get close to stock look & feel that'd probably be easier all around.
-
Well I was thinking more along the lines of a full UI overhaul which a new settings screen would be a part of.
If it's made of image elements rather than a single full screen image with overlays for the buttons, it is easier to maintain has less duplication of the same items (for instance each screen has its own options button which is exactly the same), and can be rendered to fit the screen rather than trying to stretch it, which can cause problems.
-
Oh, I wasn't saying it that way. It was an idea I had (procedural generated screens with optional graphics add-ons), and then I was saying 'on the other hand, that might be a lot of work if just procedurals look good enough'
-
Can we replicate the look of the FS2 interface with pure procedural generation?
I'm sceptical which is why I mentioned image elements and a layout engine.
I can make basic graphical elements fairly easily, so if you need any of that done it shouldn't be a problem. It's just the back end coding I can't do.
-
Not sure why we would need new screens for retail. That shipped with a UI, the same one we're complaining about now. Though, admittedly I don't understand what retail has to do with it at all. When people say don't break retail I always assumed it meant the original campaign should work right. No matter what we do adding more settings is not retail.
The problem isn't with adding more settings, it's with requiring additional assets. In addition to working with the original campaign, FSO also has to work with the original assets... and nothing else. We can't require use of the MediaVPs just to do something basic like toggle a setting (hence why options keep getting shunted to the commandline).
-
Most of the options are of limited use with the original assets anyways.
While I can appreciate not wanting to break things, FSO itself strays far from retail and most of what it has to offer is related to facilitating new assets. I don't think moving most of the settings into a the in game options screen would break the basic functionality.
Edit: I should also point out that retail compatibility shouldn't preclude improvements made to the MVP which is what an interface overhaul would be.
You'd just have to leave in the original method of handling the interface.
Is there a way to have a not pretty version of advanced settings for non MVP use?
-
Is there a way to have a not pretty version of advanced settings for non MVP use?
That, in a nutshell, is what AdmiralRalwood is saying. It must be possible for a user to operate this hypothetical new settings screen if all he has downloaded is the FSO executable.
-
It must be possible for a user to operate this hypothetical new settings screen if all he has downloaded is the FSO executable.
I don't think that's the case. If a user has just downloaded the FSO executable and wants to use it with retail assets then all the user can expect is that he will see the old interface. If the required assets aren't available then FSO shouldn't try to show a bad settings UI, it should instead use a set of default options that emulate how retail FS worked.
-
It must be possible for a user to operate this hypothetical new settings screen if all he has downloaded is the FSO executable.
I don't think that's the case. If a user has just downloaded the FSO executable and wants to use it with retail assets then all the user can expect is that he will see the old interface. If the required assets aren't available then FSO shouldn't try to show a bad settings UI, it should instead use a set of default options that emulate how retail FS worked.
So you think that people using retail assets shouldn't be allowed to, say, enable 3D radar? Or framebuffer shockwaves? That people with retail assets shouldn't be allowed to enable the rearm/repair completion timer?
-
That should be handled using a generic commandline option to set a configuration value (e.g. -config "3DRadar = true" or something like that). The point is that we shouldn't try to implement something using only retail assets. That would severely limit what we could do and the solution the MVPs could implement would suffer. If someone absolutely wants to use retail assets the MVPs could create a VP only containing the resources necessary for the new UI so retail users could use that without having to install the MVPs.
-
Aside from the usual grand idea of completely rewriting the interface everywhere, my suggestion would be to hack in an "advanced settings" button using the retail assets, which would pop up a not-so-pretty but functional list of extra settings. Better than nothing, even if it would be apparent it's just tacked onto the retail interface. If people don't mind looking at an ancient 1024x768 interface in the first place, they won't mind an extra tacked-on button/menu either, as long as it provides useful functionality.
You can even have a launcher flag to toggle it off, for purists... :D
-
We already have some (albeit very custom) code for interface widgets in the engine that's used to draw the F3 lab, these could be used to build an FSO options screen. Maybe we can expand that stuff to make it skinnable.
Hell, come to think of it, the F3 lab could just as easily serve as an FSO options menu instead of just an asset viewer.
-
I think you're needlessly shackling yourself to retail.
What is the point of even using retail assets in FSO? There's the FS2 executable already. As I said, most of the FSO changes are there to support new and upgraded assets anyways. What exactly does FSO bring to retail?
Some things have been mentioned such as 3d radar and rearm timer. That's not retail assets. If that can be put in while running"retail" what is wrong with slipping a new options screen in?
-
We already have some (albeit very custom) code for interface widgets in the engine that's used to draw the F3 lab, these could be used to build an FSO options screen. Maybe we can expand that stuff to make it skinnable.
Hell, come to think of it, the F3 lab could just as easily serve as an FSO options menu instead of just an asset viewer.
:shaking: Please don't. That code is horrible to work with and extending it will only make it worse. We already have experimental support for either SVG images or HTML which are much better solutions for this problem.
-
I completely agree. Just saying that there's no need for any dependency on any specific art assets at all unless we want there to be one. Which I think we don't.
-
I think you're needlessly shackling yourself to retail.
What is the point of even using retail assets in FSO? There's the FS2 executable already. As I said, most of the FSO changes are there to support new and upgraded assets anyways. What exactly does FSO bring to retail?
Some things have been mentioned such as 3d radar and rearm timer. That's not retail assets. If that can be put in while running"retail" what is wrong with slipping a new options screen in?
Well, for one thing, they aren't assets; the 3D radar is a piece of code. The rearm timer is text that gets displayed in an existing, retail HUD element.
Another thing is that not everyone can run the retail executable. You think that people on Linux or OS X shouldn't be allowed to play with retail assets?
Finally, the number one rule of FSO is "don't break retail" for a reason. That reason is backwards-compatibility. Backwards-compatibility is something we're not going to throw out the window just because you, personally, don't see the point of using some options with retail data. This has come up before, so I'll just link to (http://www.hard-light.net/forums/index.php?topic=36801.msg752842#msg752842) some old posts (http://www.hard-light.net/forums/index.php?topic=40961.msg835416#msg835416) that sum it up.
-
I completely agree. Just saying that there's no need for any dependency on any specific art assets at all unless we want there to be one. Which I think we don't.
I agree as long as the implementation is kept as simple as possible given that not too many users will use it.
Could we split this discussion into another topic? Speeding up Index buffer generation doesn't have much in common with creating a new settings UI :p
Finally, the number one rule of FSO is "don't break retail" for a reason. That reason is backwards-compatibility. Backwards-compatibility is something we're not going to throw out the window just because you, personally, don't see the point of using some options with retail data. This has come up before, so I'll just link to (http://www.hard-light.net/forums/index.php?topic=36801.msg752842#msg752842) some old posts (http://www.hard-light.net/forums/index.php?topic=40961.msg835416#msg835416) that sum it up.
I don't think anyone mentioned breaking compatibility with retail. We are just considering not adding a feature to a purely retail installation.
-
I don't think anyone mentioned breaking compatibility with retail.
I think you're needlessly shackling yourself to retail.
What is the point of even using retail assets in FSO? There's the FS2 executable already. As I said, most of the FSO changes are there to support new and upgraded assets anyways. What exactly does FSO bring to retail?
Some things have been mentioned such as 3d radar and rearm timer. That's not retail assets. If that can be put in while running"retail" what is wrong with slipping a new options screen in?
-
You could always put stuff like assets for UI upgrades into MV_Root and have a clearer separation between the graphically-intensive parts of the MVPs and the minor upgrades.
-
So you think that people using retail assets shouldn't be allowed to, say, enable 3D radar? Or framebuffer shockwaves? That people with retail assets shouldn't be allowed to enable the rearm/repair completion timer?
Yes, so long as the assets required to enable these things are kept lightweight and able to run on any computer that can run FSO.
-
Well it was mentioned why not fix or add to the settings screen to get rid of the need for a bunch of flags and someone said, "because retail"
Maybe my choice of wording and examples was flawed. I am not saying don't give us the option to run retail assets, I am asking what these FSO options even have to do with retail. If we go down the list of flags in order presented to the launcher, the first few options are to remove maps and effects not even present in the retail assets. You haven't demonstrated why moving these into a menu would break retail compatibility. Maybe some stuff that can be applied to retail would be unavailable, but that doesn't actually break anything.
Aside from that, moving stuff into an in-game menu doesn't preclude the option of still allowing another method for changing those settings.
You're far too worried about breaking retail assets that you haven't noticed the times where it doesn't apply.
I say you are needlessly shackling yourself to retail, because it's causing you to invent problems.
I also am not seeing why having new stock assets for the UI harms anything either. It SHOULDNT alter the gameplay at all, shouldn't affect the missions , the gameplay, models, sound, etc. I would also suggest even if the UI back end were to get changed, it should still appear to the end user to be the same menus aside from the necessary changes to make it work better with FSO (ie. it should appear to be retail, much the same way as having moved to OpenGL as the renderer moves away from retail in the backend, but is mostly transparent to the user). Again, I fail to see how this breaks retail assets and compatibility. If the reason for running retail assets is limits to computing power, then the basic UI assets need to be based around those constraints (and MVPs can go for something better if needed). If it's because you want the genuine FS2 retail experience, command line options need not apply anyways, and it makes no difference WHERE the options are.
Could we split this discussion into another topic? Speeding up Index buffer generation doesn't have much in common with creating a new settings UI :p
Agreed.
You could always put stuff like assets for UI upgrades into MV_Root and have a clearer separation between the graphically-intensive parts of the MVPs and the minor upgrades.
That's what I personally think should happen.
If a UI update is done to support the new FSO options, add it to a root VP file that is lightweight enough to run anything that can run retail assets and make it part of the core FSO install, and have it loaded by default (with the option to disable it and use the stock UI)
-
A post missed the split
Maybe some stuff that can be applied to retail would be unavailable, but that doesn't actually break anything.
So you think that people using retail assets shouldn't be allowed to, say, enable 3D radar? Or framebuffer shockwaves? That people with retail assets shouldn't be allowed to enable the rearm/repair completion timer?
I would actually like to echo mjn's earlier comments
There is no way I'll believe anyone who insists that dual scan lines or flash upon warp are game breaking to the user experience. I just don't buy it. The biggest argument for users is 3D radar and maybe rearm timer... possibly 3D warp, but I'm not sold on that. Models for ship/weapon selection? That one I absolutely believe should be modder choice (and to an extent already is if the modder doesn't make icons).
Also, I already mentioned a fallback CAN be kept, but since there are some commandline options that don't apply (disable x) or are probably better elsewhere anyways (most of the HUD options and models for ship/weapon selection are probably better reserved for tables), the commandline flags can at least get some weeding.
I also still don't think missing the options breaks compatibility.
I also can't help but thing you;re continuously suggesting, play retail, but not really.
-
I think there is a solution on both sides here. If an html/svg solution could be devised that alows any mod to seamlessly pick and choose to replace any existing legacy menu interface with a new one, and the behaviors are compatible, then a new options menu could theoretically be written with a very simple embedded-into-the-exe setup for retail, but could be overridden by either the legacy menu style or a newer prettier html/svg replacement. Is that feasible? I think the tiny embedded new style would be, not sure about supporting a legacy version that requires image assets.
-
For retail we could use wmcgui as The E mentioned. It would be quite ugly but functional and wouldn't require any image assets. If a mod wants to replace the interface it could use scripting and HTML. In any other case the old UI would be used.
-
For retail we could use wmcgui as The E mentioned. It would be quite ugly but functional and wouldn't require any image assets. If a mod wants to replace the interface it could use scripting and HTML. In any other case the old UI would be used.
Could it be possible to also implement a system to allow themes for the F3 lab and this new settings menu? Not to create the themes, but just to put in the framework so the FSU team can crack at making it pretty later? And if the theme assets aren't available, it will fall back on the generic menus instead.
-
Possible? Yes. Advisable? No. The wmcgui system is already quite a mess and adding themes to it will only make it worse. If the FSU team wants to make it pretty they should use HTML as that is actually designed to create user interfaces and has all the necessary features.
-
Hmm, then would it be better to come out with a generic HTML menu / lab without graphical content, but supporting later prettification?
In other words, if it's a mess, should it be switched to HTML now and be done with it (as you can always add the graphics later)?
said the guy who doesn't code
No I don't expect anyone to jump up and do this, I'm just talking.. for now (hopefully)
-
A generic HTML template for modders would be nice but given that some of these options also affect retail the settings menu should also be available without adding further assets. This can be done using the existing rendering mechanics of FSO but extending those to support different themes would be quite a lot of work without any real advantage as HTML will be used by most other mods as it can be freely extended without being restricted by FSO.
-
A generic HTML template for modders would be nice but given that some of these options also affect retail the settings menu should also be available without adding further assets.
Hmm. How about having the HTML menu use the retail menu screen assets for its own retail-only mode's settings UI (thus making an HTML driven retail clone, preserving retail compatibility), + (as mentioned in a post previously) an extra button tacked on to the retail-only mode's settings UI for all of the extra options (that would probably never be used because the user is running retail assets only, but, hey, just in case).
-
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.
-
I really think that if creating a UI that can gracefully degrade if it isn't supplied with interface art is going to be any significant stumbling block, you should just drop it and make the art a requirement to be able to use the extended menus. If you're using retail assets then you have the same functionality as retail, and if you want the fancy options you can install the assets for them.
-
Good gravy.. there are clearly individuals involved in this conversation that do not have a clear understanding of retail FS interface assets and how FS puts them on the screen...
-
1. Not all the 'options' that FSO supports require extended art assets. Please stop assuming that all command line options only affect MediaVP users. It's not true.
2. As klunky as the F3 lab or wmcgui code has been stated to be, extended it to be any prettier is not likely to happen. I wouldn't keep suggesting it unless you plan on implementing it yourself.
3. The already-prototyped HTML interface shows promise to actually work and be completely customizable by any mod. That is likely going to be the recommended path for making changes to any existing or future menus for all future mods, although nothing should stop them from replacing any existing menus with their own assets. But since that's such a PITA, I don't expect future mods to do that when HTML is so much easier.
4. That leaves only one question left: how to add an options menu that retail users could use, because believe it or not, there are perfectly valid reasons for using FSO with retail assets. It would not be a pretty menu, but it would be better than command line options via the launcher, assuming we can even figure out how to make command line options changeable on the fly, since many might currently rely on being set during engine startup and have unpredictable results when toggled later. The options we can safely toggle in-game will hopefully be configurable via a bare-bones menu in retail, either via wmcgui, or a minimal text-only HTML interface that can easily be embedded in the engine. Either one would ideally be able to be overridden just like any retail menu using a full HTML setup with image assets.
So, really, the only question left is whether to use embedded HTML or the wmcgui or whatever existing framework for the barebones menu. It's been putted around for some time, and since no one has done the wmcgui implementation, my money is on us adding it via embedded HTML after that framework is in the engine for replacing existing menus.
I am all for cleaning up command line flags though. <troll>I don't see why we still have ship choice and weapon choice 3d. They automatically enable for a mod that doesn't provide icons for a given ship or weapon regardless of the setting, and if a mod does provide art assets, why are you using the ugly 3d renders instead of the pretty artwork?</troll>
-
So, really, the only question left is whether to use embedded HTML or the wmcgui or whatever existing framework for the barebones menu. It's been putted around for some time, and since no one has done the wmcgui implementation, my money is on us adding it via embedded HTML after that framework is in the engine for replacing existing menus.
For the barebones menu I would suggest using wmcgui. The people who can't run MVP assets will probably also be affected by the increased memory usage of chromium running in FSO and if no HTML rendering is required the chromium subsystem will not be initialized.
-
Hmm, I wasn't even considering that people might be running it because of memory limitations, and I didn't think that the Chromium engine really took up all that much memory for rendering. But a valid point.
-
4. That leaves only one question left: how to add an options menu that retail users could use, because believe it or not, there are perfectly valid reasons for using FSO with retail assets.
I broadly disagree. There are obviously people who can't run the MediaVPs because of system limitations — I was one of them myself for years — but that doesn't mean they can't install a small pack of assets to enable some new features that they already need to install the FSO executable and launcher to use.
-
I broadly disagree. There are obviously people who can't run the MediaVPs because of system limitations — I was one of them myself for years — but that doesn't mean they can't install a small pack of assets to enable some new features that they already need to install the FSO executable and launcher to use.
Why would we need new assets? We already sort of agree on using the existing GUI system that doesn't require new assets.
-
That UI system is very clunky, very ugly and currently used only for debugging and development purposes, and by all accounts it's a nightmare to work with its code. Please, please don't use it just so you can avoid using interface assets.
-
The FSO is a drop-in replacement for the FS2 retail binary. If we're going to add an additional menu, it would be nice of us to allow it to work without additional assets. And it's already stated that it should be feasible, so I don't see the point in requiring additional assets if we don't have to. No one's talking about only people who _can't_ run the MediaVPs, but there are times when you don't want to be running additional assets besides retail.
-
When? I mean really, when? Why is it so important to support this scenario where someone is running FSO and a) can use no additional assets whatsoever, no matter how trivial and b) needs to be able to turn on the 3D radar and rearm timer? If they really need the latter, which are no more part of the retail experience than the MediaVPs, they can just install the interface pack.
-
Why should the SCP create a new GUI system that can use interface assets if there is already an existing system? There is no reason to create a new system or adapt the existing one. However if you want to do that you are free to create a pull request on GitHub.
-
That UI system is very clunky, very ugly and currently used only for debugging and development purposes, and by all accounts it's a nightmare to work with its code.
I mean for god's sake you're talking about using HTML to build UIs right in this thread. If the only reason not to do that is that it'd require interface art I really hope you reconsider.
-
That UI system is very clunky, very ugly and currently used only for debugging and development purposes, and by all accounts it's a nightmare to work with its code.
I mean for god's sake you're talking about using HTML to build UIs right in this thread. If the only reason not to do that is that it'd require interface art I really hope you reconsider.
Dude, FSO doesn't even like to ship with external DLLs if it can be helped.. much less a whole interface pack. Not only that, but what about m!m's post (that I don't think you bothered to read) that says that HTML chromium engine might cause performance issues for people who are running retail assets already for performance reasons. It's a good point.
But no one is saying the HTML stuff won't be developed. They are trying to find a way to create a special menu that works for people running retail data. Which, by the way, is and always will be a staple requirement for the SCP. The HTML stuff will be an added bonus for mods and even the MVPs to take advantage of.
-
Dude, FSO doesn't even like to ship with external DLLs if it can be helped.. much less a whole interface pack.
Yes, this is what I'm trying to challenge. Obviously FSO shouldn't need to ship with any additional files to be able to run, but I think requiring extra assets to enable functionality that was never in retail to start with is pretty reasonable and the SCP shouldn't be going to these lengths to avoid doing so. As for Chromium overtaxing low-end systems... well, that's a good reason not to use Chromium for this. It still doesn't mean we should be designing interfaces around the limitation that they work with no additional assets.
-
So you basically want to challenge one of SCP's base principles. OK, whatever dude. Knock yourself out.
-
No, this isn't one of the SCP's base principles. The SCP's base principle is 'don't break retail'. This doesn't break retail in any way. It's not any different from the MediaVPs, even.
-
Actually I'm not entirely sure that this violates a base principle, unless we _replace_ the command line interface for setting options, as opposed to simply augmenting it with an easier to use menu. If we augment, retail assets alone could still be customized as long as command line options are always available for any feature the new menu supports configuring (or at least those that make sense with only retail assets).
But here's the thing. Any HTML menu would exist to replace some menu that already exists hardcoded into the engine. Without some sort of existing new menu hardcoded into the engine for options configuration, how is a prettified HTML version supposed to even know what to do? We'd have to create the actual set of hooks and such for this new menu, allowed actions, etc, and if we go that far...we might as well template it out in wmcgui or an embedded HTML (I still think that's a viable option as long as this only augments command line, since those having performance issues can just not enter the HTML menu and load the chromium engine).
-
I broadly disagree. There are obviously people who can't run the MediaVPs because of system limitations — I was one of them myself for years — but that doesn't mean they can't install a small pack of assets to enable some new features that they already need to install the FSO executable and launcher to use.
And our position is simply that if a solution can be found that doesn't require external art assets, then that solution should be pursued.
-
Especially if that solution is actually easier to implement than a solution using external assets.
-
If it's easier to implement and pleasant to use then I'm all for it. I don't think you should compromise implementability or ease of use just to avoid requiring assets, though.
-
It would be barebones so it probably wouldn't be as pleasant to use but that's why HTML should be used by everything but retail.
-
The other thing is, it doesn't stop anyone from releasing a pretty HTML interface pack just for this, separate from anything else. Could be used like the multiplayer mission pack, the ogg movie pack, etc. Things that even a 'core' setup might still prefer to use.
-
When implementing the slider bars in the WMC GUI to get gloss sliders for PBR, I thought about building an interface for SCP specific graphics options. I think the best solution I thought up of was creating a pop-up box using the retail quit game dialog box art asset and populating it with procedurally drawn options. That way you could just draw it on top of anything without changing the current state in the UI state machine since it's a pop up window. I tried looking for retail assets that I could drop in but a lot of interface art blocks are "anchored" to the bevels of the interface backgrounds which is really annoying.
I think the best solution is to have best of both worlds. Have an interface that can use modder-definable art assets but is capable of drawing it procedurally if none are available.
-
I think the best solution is to have best of both worlds. Have an interface that can use modder-definable art assets but is capable of drawing it procedurally if none are available.
But that would require additional work for implementing a system that would only be used very rarely. The standard case would be that the modder uses HTML for their interface.
-
Well okay, if that's too much work, I'd rather just write a jank WMC GUI interface and not even bother with modder definable assets. Unless you want me to wait for an HTML/CSS-based interface system to be ready.
-
That's exactly what we want to do :p
-
Yes, this is what I'm trying to challenge. Obviously FSO shouldn't need to ship with any additional files to be able to run, but I think requiring extra assets to enable functionality that was never in retail to start with is pretty reasonable and the SCP shouldn't be going to these lengths to avoid doing so.
I'm not sure that you fully grasp the nuance of the discussion. Perhaps it would be helpful to compare it to two features that do require the MediaVPs to be enabled -- scrollable command briefings and the apply-loadout-to-the-entire-wing button. These both require new interface art, which is supplied in mv_core.vp. If the new graphics are not present, they will not be shown on-screen and you will not be able to use the new features.
This is acceptable because these two things are minor tweaks to an existing interface. It's no great loss if the features are disabled, because they didn't exist in retail. (Well, the lack of scrollable command briefings would be inconvenient for briefings that run off the screen, but that is usually handled by opening the mission files to read the text.)
This new settings screen is a different sort of animal. It is not the interface that is being upgraded for its own sake. It is the ability to set options without exiting the game and restarting. The interface is not intrinsic to the feature itself. Heck, the problem could be solved by adding a console-based settings system with text prompts, but that isn't very user friendly.
In a nutshell, this discussion is about providing a user-friendly way to modify options that does not depend on external assets.
-
People seem to be assuming that this only applies to retail. It doesn't.
We're talking about removing the commandline settings and setting up an in-game screen for them. And although we've not mentioned them, I can't think of any good reason why most of the lighting options (-spec_tube etc) shouldn't also be moved to this screen so that they can be altered in-game (unless they are like tables and can only be set on load).
Why doesn't this only affect retail? Cause of the TC's. TBP is no longer in development (nor are Wing Commander Saga or Beyond the Red Line if they ever works on modern FSO). Diaspora and WoD would be forced to rush out new art to allow those settings to work.
So this is not a matter of simply saying "You need media VP's in order to use new FSO features", this is a case of saying "I want a minor upgrade to something which isn't really very important (cause we already have this feature via the command line) to use pretty interface art, so **** the TC's who support this via the command line"
-
I have to agree with Phantom, if we can get something good without distributing any extras do so, but don't bend over backwards to avoid shipping ancillary files just on principle. Do what works best regardless of whether or not you may have to ship some assets.
As for HTML and chromium, if memory is an issue, is there another render engine that works better? I'm confused why you want to use HTML in the first place. It's designed to render rich content and link to a multitude of other pages, why use that instead of a markup language specifically for UIs that are actually designed to pass commands to a program (eg. XAML)
There's a lot of stuff in HTML that I just don't see a use case for, so having all of them could be detrimental to the resource footprint of the program. I also have concerns over how exactly it's going to work since HTML is designed to retrieve and render resources, not control program flow. Is it about familiarity with HTML and coding for it or is there another reason to use HTML?
. I tried looking for retail assets that I could drop in but a lot of interface art blocks are "anchored" to the bevels of the interface backgrounds which is really annoying.
ALL of the buttons are technically part of the background. Another image then defines hotspots in the image each with its own color (shades of off-white) and the program links each color to a function and mouse over and clicked button images which are overlayed as-needed into the defined space.
That's why any changes to the current way Freespace handles the UI are going to be problematic.
"I want a minor upgrade to something which isn't really very important (cause we already have this feature via the command line)
That sentiment is how bad code and paradigms pile up in programs.
Fixing up the UI and allowing for settings to be changed in game doesn't mean we have to take away the original options (at least, not right away).
Aside from that, can the campaign restoration project's scope be expanded to provide some support to keeping TCs up to date if/when features get depreciated?
-
As for HTML and chromium, if memory is an issue, is there another render engine that works better? I'm confused why you want to use HTML in the first place. It's designed to render rich content and link to a multitude of other pages, why use that instead of a markup language specifically for UIs that are actually designed to pass commands to a program (eg. XAML)
There's a lot of stuff in HTML that I just don't see a use case for, so having all of them could be detrimental to the resource footprint of the program. I also have concerns over how exactly it's going to work since HTML is designed to retrieve and render resources, not control program flow. Is it about familiarity with HTML and coding for it or is there another reason to use HTML?
Chromium is a full browser stack and not just a HTML renderer. That means we will have support for CSS and JavaScript which is how the control flow would be handled.
-
and why do we want/need a full browser?
(note HTML rendered tends to imply CSS and javascript due to the way HTML relies on them)
-
and why do we want/need a full browser?
(note HTML rendered tends to imply CSS and javascript due to the way HTML relies on them)
Why wouldn't we want this? You mentioned yourself how FS2's UI works, and you're probably aware that it's a complete mess of hardcoded stuff. Getting support for an HTML renderer would mean that TCs or mods could fully customize their UI withoiut being shackled to 1024*768, or :V:'s idea of control flow.
-
Well I already mentioned the fact that stuff exists specifically for make UIs.
HTML is not one of them. It's goals are different, it's feature set is different.
It's not that I don't think a more flexible system is necessary (I am fully aware the FS interface is a byzantine mess from an earlier time), I am just confused as to why HTML would be the way to go for it, and more pertinently, why a full browser is the way to go. Seems heavier than what's needed.
(on a side note what language is FSO programmed in/ what is the runtime environment?)
-
Well I already mentioned the fact that stuff exists specifically for make UIs.
HTML is not one of them. It's goals are different, it's feature set is different.
:wtf: HTML is designed to create UIs, that's pretty much all it does. This may not be what the language was designed to do but nowadays that's all it does. If you have a good alternative then please let us know.
-
A web page is not a user interface. It's a document that contains rich content and links to other web pages.
There may be parallels, but they aren't the same.
I am researching alternatives, which is why I asked about how FSO runs internally.
My initial thought was to at least take a look at QML (QT Quick) which uses javascript and is extensible through C++, and if I am not mistaken uses OpenGL
If FSO uses .net (can't remember if it does, but I think it's a no) there's XAML.
I believe we also have a couple people here familiar with wxWidgets.
Anyways, HTML can certainly be used, I am just wondering if there was a specific reasoning for using it in particular (eg. already did it, might as well use it, or most people already understand HTML), and whether or not other options have been considered or explored.
On a side note, do we even need something like HTML?
there's ALREADY the need for javascript for HTML and my initial suggestion, and work is already being done to implement SVG support. That alone could be workable, javascript interprets commands to the engine and SVG is responsible for graphics rendering.
At the very least, due to having to control program flow, most of the heavy lifting will be done in javascript, so making that work is of more importance than making the HTML part work.
-
So this is not a matter of simply saying "You need media VP's in order to use new FSO features", this is a case of saying "I want a minor upgrade to something which isn't really very important (cause we already have this feature via the command line) to use pretty interface art, so **** the TC's who support this via the command line"
This is a pretty good argument for keeping the command-line flags, not for crippling the options interface.
-
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.
-
A web page is not a user interface. It's a document that contains rich content and links to other web pages.
There may be parallels, but they aren't the same.
And yet, most modern applications' UI are actually web apps using a mixture of html, css, javascript and some other language server-side to make things a bit more dynamic.
I am researching alternatives, which is why I asked about how FSO runs internally.
*lists alternatives*
Aside from wxWidget, you are suggesting what I'm guessing are markup languages. I assume you are familiar with these, so could you explain what advantages these have over html?
My understanding is that chromium brings a whole host of capabilities while being easy to integrate into the engine. Besides, as you mentionned, there's a a fair amount of people that are familiar with html, js & css, and plenty of tutorials available out there for those that aren't.
-
My understanding is that chromium brings a whole host of capabilities while being easy to integrate into the engine. Besides, as you mentionned, there's a a fair amount of people that are familiar with html, js & css, and plenty of tutorials available out there for those that aren't.
This, to me, is chromium's main selling point that any other solution has to be measured against.
-
I would also like to mention that a chromium integration into FSO already exists (http://www.hard-light.net/forums/index.php?topic=87130.msg1741085#msg1741085).
-
Bear with me a bit, I'm just brainstorming here.
Crazy man, throwing ideas at the wall to see what sticks.
A web page is not a user interface. It's a document that contains rich content and links to other web pages.
There may be parallels, but they aren't the same.
And yet, most modern applications' UI are actually web apps using a mixture of html, css, javascript and some other language server-side to make things a bit more dynamic.
You'll have to provide some examples. Most programs I am familiar with use whatever UI format is provided by the SDK for a platform (I see a lot of .NET, UIs codded into java programs and GTK, and Qt is also popular).
I am researching alternatives, which is why I asked about how FSO runs internally.
*lists alternatives*
Aside from wxWidget, you are suggesting what I'm guessing are markup languages. I assume you are familiar with these, so could you explain what advantages these have over html?
I'm somewhat familiar with .NET (which XAML is a part of), don't know as much about QML. XAML uses XML syntax, but both are declarative languages rather than markup languages like HTML is. The advantage is they are designed for this work and are extensible by the programming language they run on top of, and they are actually designed for drawing interfaces whereas HTML is for displaying content and only contains javascript as an option to allow for some interactivity. The layout engine for rendering web pages also contains a lot of fluff not needed for this purpose.
I'm not saying don't use it, I'm just saying explore your options. Just because something can be used, doesn't necessarily mean it should be used.
My understanding is that chromium brings a whole host of capabilities while being easy to integrate into the engine. Besides, as you mentionned, there's a a fair amount of people that are familiar with html, js & css, and plenty of tutorials available out there for those that aren't.
Fair point, and I figured it would come up, although I could have swore someone mentioned Chromium was running a bit slow and bloated under FSO. With the talk of not breaking retail compatibility how likely is this to increase the memory footprint by an unacceptable margin?
or am I just misinformed and need to remember what I read better?
My understanding is that chromium brings a whole host of capabilities while being easy to integrate into the engine. Besides, as you mentionned, there's a a fair amount of people that are familiar with html, js & css, and plenty of tutorials available out there for those that aren't.
This, to me, is chromium's main selling point that any other solution has to be measured against.
I should point out that's a selling point for HTML, CSS and javascript rather than chromium itself
(I should note, Gecko has it's own interface language, though I would be equally wary of that bloating the executable as chromium)
I would also like to mention that a chromium integration into FSO already exists (http://www.hard-light.net/forums/index.php?topic=87130.msg1741085#msg1741085).
Fair enough. How does/will it interact with being used for UI purposes? Isn't programming the hooks to let the javascript actually control FSO yet to be done?
-
You'll have to provide some examples. Most programs I am familiar with use whatever UI format is provided by the SDK for a platform (I see a lot of .NET, UIs codded into java programs and GTK, and Qt is also popular).
Gmail.
I'm somewhat familiar with .NET (which XAML is a part of), don't know as much about QML. XAML uses XML syntax, but both are declarative languages rather than markup languages like HTML is. The advantage is they are designed for this work and are extensible by the programming language they run on top of, and they are actually designed for drawing interfaces whereas HTML is for displaying content and only contains javascript as an option to allow for some interactivity. The layout engine for rendering web pages also contains a lot of fluff not needed for this purpose.
I'm not saying don't use it, I'm just saying explore your options. Just because something can be used, doesn't necessarily mean it should be used.
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.
Fair point, and I figured it would come up, although I could have swore someone mentioned Chromium was running a bit slow and bloated under FSO. With the talk of not breaking retail compatibility how likely is this to increase the memory footprint by an unacceptable margin?
or am I just misinformed and need to remember what I read better?
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. How does/will it interact with being used for UI purposes? Isn't programming the hooks to let the javascript actually control FSO yet to be done?
There's a ****ton of work left to do before this becomes anything close to useable.
-
How many modders know or would like to know XAML? Ok, how many know or would like to know the ubiquitous langauge of the web, on both desktop and mobile devices? HTML has far more appeal than most other options.
-
You'll have to provide some examples. Most programs I am familiar with use whatever UI format is provided by the SDK for a platform (I see a lot of .NET, UIs codded into java programs and GTK, and Qt is also popular).
Well, a lot of the programs I've worked with or on are in-house, or destined to a specific client and as such can't be found online, so, on top of my head, I can only point to a few 3rd party tools, such as TestLink (https://en.wikipedia.org/wiki/TestLink), Quality Center (https://en.wikipedia.org/wiki/HP_Quality_Center) or Mantis (https://en.wikipedia.org/wiki/Mantis_Bug_Tracker).
-
The notion that HTML is used for displaying content rather than creating UIs is a very wierd one... Those two things overlap and are amongst the same thing. Mobile webpages, specifically, are almost closer to full UIs than ever before. It just so happens that the same code grabs the content and fills the page too.
And yes, what Chief said. I don't want to have to learn yet another language thing just for FS interfaces when HTML is more than capable and I already have a working knowledge of.
Oh and HTML's native linking abilities sound great for linking to different parts of FS's interface.
-
jQueryUI. Use it all the time at work.
-
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. :D
-
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.
-
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.
-
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.
-
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/.
-
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" :P
I do like what I am seeing there, though. Especially the whole MIT License thing.
-
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.
-
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.
-
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?
-
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. :yes:
-
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. :yes:
-
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.
-
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. :yes:
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 (https://atom.io/)
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?
-
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.
-
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. :yes:
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.
-
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.
-
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.
-
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.
-
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 :p
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.
-
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.
-
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.
:wtf: The whole point of the W3C is to standardize the appearance of web pages.
-
It's true that HTML is a markup language, but CSS is a language for defining precisely how HTML should look, and standards-compliant CSS should look the same across any standards-compliant browser. Combine that with Javascript and you have a language for applying interactions in a standard way, and you have everything you need for a UI.
-
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.
:wtf: The whole point of the W3C is to standardize the appearance of web pages.
The web page may look the same, but the UI can be very different. See = implementation of a drop-down list UI control on iOS Safari vs IE11, etc...is what he was driving at.
-
Yes, default stylings may vary, but again, CSS allows you to standardize that appearance across browsers. So when we say, HTML, we're not really talking about only the markup language, we're talking about the entire client-side language stack natively supported by any modern browser.
-
Isn't the point about the differences across browsers pretty much moot given that the entire community will effectlvely only be using one browser anyway, i.e whichever one we build into FSO?
Or am I missing something about why this is important?
-
The native controls on the different platforms will look different but given that most of that will be styled using CSS it shouldn't be a problem.
-
The point is people are arguing the semantics that HTML isn't for UIs, it's a markup language, but this isn't important because we're talking about the entire web language stack and not just pure HTML.
-
It's more important to be right than useful on the internet. :)
-
Isn't the point about the differences across browsers pretty much moot given that the entire community will effectlvely only be using one browser anyway, i.e whichever one we build into FSO?
Or am I missing something about why this is important?
I think the point was to differentiate between the content and the UI. The UI for a browser is stuff like the forward and back buttons, address bar, tab bar, etc. The webpage, no matter how interactive it is, is separate from the UI.
You're right, though, browser UIs are a moot point. All that's really needed is the layout engine, and Chromium seems to have been decided upon already.
I would HOPE a full browser with it's own UI isn't used to draw the FSO UI (Yo dawg, I herd you like UIs, so we put a UI inside you UI)
The native controls on the different platforms will look different but given that most of that will be styled using CSS it shouldn't be a problem.
Im confused as to what you are saying, it makes it sound like you are planning on having things like forward and back buttons and reskinning them to the FSO theme. Aside from that native controls tend to vary by browser, but the browser look across platforms tends to vary little.
The point is people are arguing the semantics that HTML isn't for UIs, it's a markup language, but this isn't important because we're talking about the entire web language stack and not just pure HTML.
I am pretty sure I mentioned I was talking about the entire web language stack, or more importantly, a full web layout engine.
Yes, i'm aware, mine isnt much better but you have made more than 4 posts worth of useless, unsubstantiated claims so far.
Tell you what, when someone actually says, "we have researched other options and determined chromium works the best", I'll shut up.
My main concern is that whatever gets used will get used simply because people have heard of it, not because it's the easiest to implement and easiest for modders and end users to use.
[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]
No? SVG can be fully scripted, and even supports styling. I didn't say it wasn't terrible, I just said you could.
PS, first one to pull jQuery into FSO gets an international slap from me :p
Does someone mentioning jQueryUI earlier count?
It's more important to be right than useful on the internet. :)
Always.
Pretty sure in a modding community it's also important to be stubborn.
-
My main concern is that whatever gets used will get used simply because people have heard of it, not because it's the easiest to implement and easiest for modders and end users to use.
Oh, come on then. Easiest to implement? It already is. Done. Easiest for modders? HTML is so simple, I think my grandma could put together a rudimentary webpage, not to mention what modders who have learned SEXPs can do with such a simple language.
-
Tell you what, when someone actually says, "we have researched other options and determined chromium works the best", I'll shut up.
My main concern is that whatever gets used will get used simply because people have heard of it, not because it's the easiest to implement and easiest for modders and end users to use.
Please trust us on this. Whatever solution ends up getting used, you can be certain that it will be a) easy to implement and b) easy to learn. Point b more or less requires that we use something that is somewhat standardized.
[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]
No? SVG can be fully scripted, and even supports styling. I didn't say it wasn't terrible, I just said you could.
And have you done any research on the available libraries that we can integrate into FSO, and the amount of work required to do so? Because you're talking to people who have, and who have concluded that they aren't workable.
Look, we do appreciate your enthusiasm, we really do. But please trust that we who are working on the engine and have been working on it for years have a better appreciation for what is doable than you do.
-
Just my 5c having developed webapps in the past:
1) HTML + CSS were created to display *stuff*, not be a program interfaces. This means that you don't have proper interface entities. (Entities = "Thingy", not the HTML shenaningans with reserved charaters). What you have is instances of entities used for structuring and displaying content. BirdofPrey's input is very valid. On the surface the distinction seems moot, as the HTML form elements are very similar to what wants from interface elements... however compared to the interface components I describe below they're excessively *crude*.
2) XAML or other UI languages are typically provided by high level languages/programming environments like Java or .NET (that focus on business application). Here you typically have components that are specific *interface* elements. A .NET or Java Swing component is a lot *more* than a mere Form button or field. It has built in tools to handle masking user input, they come with vastly better & simpler to use layouts, they have built in support for directly binding to your business/app-logic and your (data)-model.
3) How webapps are usually actually made: Unless you're cobbling together something from basic PHP, you typically *don't* deal with HTML elements. You use whatever UI components your programming environment provides and you let the *framework* translate this all into HTML / CSS. Your graphic designer might tweak the CSS output to make the UI "prettier" or tweak the layout (either at the XAML or the CSS level) but this is all about layout & look.
So while a lot of people rightly made the remark that "HTML+CSS+JS" is just "known", I feel it prudent to point out that very few apps / UIs are actually developed in it, even if the end result will be *translated* to those to be displayed in a browser. That said, the remark that the above trio are know is *valid* and for simple stuff it's indeed easy to use. (Although I wouldn't really agree about that when it comes to CSS. Modern layouts are so darn complex that I wonder how many people still tweak the code by hand instead relying on other tools). Still... learning XAML for instance is not *hard*, actually anyone who worked on HTML will be able to grasp it really fast. (It *simplifies* UI layout).
From a developer point of view thus the question should be this:
1) Should the project focus on HTML *rendering* (with whatever subset of the HTML stack will be supported) vs another framework? The former is better known, but (IMHO) clunkier, the later more powerful but less well known.
2) If HTML rendering is supported should that be the "end" of the development, or could a two-tier approach be used? JSP/JSF/PHP and other server side scripting/programming solutions allow one to use both tools: One can write code that operates on UI components that get translated to HTML elements and one can directly embed HTML code too. The downside is increased complexity.
TL;DR:
The choice between declarative / markup languages (e.g. XAML vs HTML) is not a clear either/or choice.
-
That post is less helpful than you might think.
Telling us that "HTML is not meant for applications" doesn't help. You know. We know. Everyone knows. Unless you have a better alternative, do not waste your time and ours on telling us things we already know.
I am sorry if this comes across as dismissive and abrasive. However, please understand that noone gains anything by having the thread devolve into philosophical discussions on what a given tool is meant for.
That said, let me recap the issue. Hopefully this'll allow us to get back to a more productive track.
1. FS2's menu system is pretty much non-extendable.
2. A modder wanting to include new UI elements will have to resort to built-from-scratch lua scripts.
3. Given that we do not have a lot of lua scripters, and not a lot of people comfortable with using lua, this drastically reduces the options available to the average modder.
So, we're looking into ways to create a new interface layer that can be used to replace the entire interface. One solution that has been proposed and prototyped is to use chromium; this seems like overkill for the purposes of doing an interface, and is perhaps unsuitable for use in-game. Another HTML/CSS-based solution, libRocket, seems like a really good alternative, but needs experimentation. Building an interface using these tools may not be what the designers of HTML had in mind, but we don't particularly care; after all, at least in libRocket's case, it has been shown to be feasible.
What we're looking for here are alternatives to this. Our parameters here are:
-Compatibility with the FSO license (Short version: Anything under GPL is out)
-Easy to learn using industry-standard tutorials.
-Straightforward to implement.
-
Could you please clarify what licenses are permitted? (I know this is an ass question as legal matters can be a real quagmire. I only ask in hope someone has tried to untangle it before).
IIRC while (pure) GPL software can't be used, LGPL (with some limitations) can. (The new cutscene player by m!m for instance uses ffmpeg, which - AFAIK - is LGPL/GPL).
What other licenses are compatible with FSO? Chromium was mentioned as a strong possibility, which is available under the LGPL, MIT, BSD and MPL licenses. If the Chromium Embedded Framework is used than I'd assume the "New BSD License" is also compatible with FSO.
-
GPL is completely out. LGPL can be used (conditionally, if linked correctly). MIT, BSD, Apache, zlib, these are all fine and pose no problems.
-
When I mentioned jQueryUI, I was not saying it was what we should use, I was pointing out that there is at least one blatantly obvious UI-oriented framework for the browser stack. There are probably dozens more good ones for browser UIs, and hundreds of ****ty ones, just like there are UI frameworks for Java, C++, etc.
We're not talking about back and forward buttons either. The platform-specific elements that would see on a web page are typically form elements and scroll bars. But CSS makes that a moot point, as we could have a reference implementation that styles them the same way across every platform FSO runs on. A good UI framework for JS probably already has the accompanying CSS to do just that.
So, Flaser, you're still saying HTML+CSS, and you're right, without a language designed to implement behaviors, there's no possibility of a UI. But since there's also JS, viola, we have the potential for a UI in the browser stack.
Seriously, so many mobile apps have UIs that run in the phone's browser engine these days, and just make RESTful calls to populate data in the DOM, I don't know how it's so difficult to accept that the browser stack is perfectly competent at rendering a UI these days. I'm not saying it's definitely the right solution for us, but can we please stick to arguing actual negatives of using the chromium browser stack vs trying to say it can't be done at all?
As far as LGPL code goes, it's not just linking, and as implemented the cutscene player is far leaving us LGPL compliant. I don't think we should be merging it in until the proposal meets everything in this checklist (https://www.ffmpeg.org/legal.html), or we can prove that we are compliant via other means. Same goes with proposing any other LGPL library integration, although if we were compliant with one, it would likely make it easier to be compliant with others.
-
Having done a little research the following widget toolkits/libraries could be alternatives to using Chromium. This is not meant to be a comparison from on-hands coding experience, just an overview of what can be glimpsed from the documentation / Wikipedia.
Common features: C/C++ compatibility, being multi-platform, having tools available for modders to create UIs without having to code it all.
The Big Two™: GTK+ (with Gtkmm) and Qt.
Pros: These are extensive frameworks with good documentation and (coding) tutorials available. Very wide variety of widgets available. Of the two, Qt seems to be preferred by a lot of developers.
Cons: These are extensive frameworks and would likely need extensive learning by coders. Licensing: Both are only available as LGPL.
CEGUI:
Pros: It's specifically aimed at game UI development and unlike the Big Two™ it uses the MIT license. It's also more lightweight as it's supposed to interface other modules to handle rendering, parsing, etc. not directly related to the UI widgets.
Cons: Less variety in available widgets. While (probably) requiring less documentation studying than the Big Two™, it'll likely need more custom code developed to interface with the FSO code.
All three have tools for creating UIs in WYSWYG environments. Downside? Unlike libRocket these UIs are not defined in HTML. Qt and CEGUI use their own XML based markup while GTK+ doesn't have a default UI markup language. For libRocket any XHTML editor would do.
Big question: Could anyone provide feedback on either of these having used them?
EDIT: @chief1983 I have nothing against a browser stack, I just to give feedback on things I've used in the past. (Unfortunately those being .NET - Windows Forms & WPF and Java Swing they're not relevant to FSO). This post is just trying to outline some more alternatives to what has been proposed so far (Chromium or libRocket). In the end using Chromium could be the simplest and most straightforward (even if not lightest resource use wise) solution.
-
Can someone just make proof of concept duplicating the Freespace2 briefing screen in HTML+CSS+Javascript so we can have a proof of concept that this stuff could actually work for us? I mean, it'll run in a browser so you can just put it somewhere online and slap the URL here. :P
-
also, the simplest, dumbest interface with js could be onclick="main.goToBriefing();" or what have you :p
Those of you who are arguing for non html stuff. Sure, they are the right, proper, full double plus good solutions.
EXCEPT for the end users (modders). Who just want the thrice damned thing over and done with.
Anything involing a custom DSL (Domain Specific Language to the code-challenged of you) is a very very very bad idea, because of the aforementioned "look how badly lua has fared".
Its a simple problem, people will not bother to learn something thats specific to this one sole thing unless they have a very personal investment in it.
Btw, swifty, this just crossed my mind, how in the twelve hells would we integrate the rendered background and stuff? One thought that comes to mind is a canvas element with pass-through, but other than that...
-
Recreating the existing FS2 interfaces would be as difficult as creating a new interface by replacing the existing artwork in the current system. But creating a new interface that looks sleek, and has all the functionality of the FS2 interface, that would be pretty easy to cover most of the current menus. Although, we'd really just be excited to add a new options menu off the bat, which wouldn't have to look like anything in particular, but be very easy to implement. Prototypes of replacements of the existing menus could follow, and be styled as we see fit, but the functionality for existing menus would only have to be written once, and then a mod could just pretty them up as desired, with much more flexibility than with the current system.
-
also, the simplest, dumbest interface with js could be onclick="main.goToBriefing();" or what have you :p
Those of you who are arguing for non html stuff. Sure, they are the right, proper, full double plus good solutions.
EXCEPT for the end users (modders). Who just want the thrice damned thing over and done with.
Anything involing a custom DSL (Domain Specific Language to the code-challenged of you) is a very very very bad idea, because of the aforementioned "look how badly lua has fared".
Its a simple problem, people will not bother to learn something thats specific to this one sole thing unless they have a very personal investment in it.
Btw, swifty, this just crossed my mind, how in the twelve hells would we integrate the rendered background and stuff? One thought that comes to mind is a canvas element with pass-through, but other than that...
Indeed. I'm rusty at HTML, CSS and have rarely used Java.. but I can figure that out. Going with some other DSL... it's unlikely I would bother. I'm already only ankle deep in trying to figure out LUA and I'm one of those people with a personal investment.
And yes, I would wonder how something like a mainhall would be recreated. I've never done anything quite like that in a browser capable environment. However, given that mainhalls can now be any res with all kinds of fun features (cheats and the like)... I'd probably stick to using that. But that's my personal preference based on my current HTML, CSS, Java abilities.
So for whatever that's worth, that's my opinion as one of the modders in the community with a clear investment in the interface side of things.
-
If it makes any difference, before I found out the engine didn't support it, I started some initial work on recreating the FS1 interface, and most of the work was spent figuring out what parameters I need to get the texture and bevels to actually look right, so I have SOME graphical assets ready (in the sense they are formatted how FS uses elements, would have to spend a bit cutting everything apart to work with a new system) and it shouldn't be too hard for me to make more.
Granted that does nothing for recreating the FS2 interface, but maybe some of the workflow can be reused.
-
also, the simplest, dumbest interface with js could be onclick="main.goToBriefing();" or what have you :p
Those of you who are arguing for non html stuff. Sure, they are the right, proper, full double plus good solutions.
EXCEPT for the end users (modders). Who just want the thrice damned thing over and done with.
Anything involing a custom DSL (Domain Specific Language to the code-challenged of you) is a very very very bad idea, because of the aforementioned "look how badly lua has fared".
Its a simple problem, people will not bother to learn something thats specific to this one sole thing unless they have a very personal investment in it.
Btw, swifty, this just crossed my mind, how in the twelve hells would we integrate the rendered background and stuff? One thought that comes to mind is a canvas element with pass-through, but other than that...
Indeed. I'm rusty at HTML, CSS and have rarely used Java.. but I can figure that out. Going with some other DSL... it's unlikely I would bother. I'm already only ankle deep in trying to figure out LUA and I'm one of those people with a personal investment.
And yes, I would wonder how something like a mainhall would be recreated. I've never done anything quite like that in a browser capable environment. However, given that mainhalls can now be any res with all kinds of fun features (cheats and the like)... I'd probably stick to using that. But that's my personal preference based on my current HTML, CSS, Java abilities.
So for whatever that's worth, that's my opinion as one of the modders in the community with a clear investment in the interface side of things.
i'll see if i can get a quick and dirty json-powered briefing screen done in the next few days. btw, Java !== JavaScript :P
-
Java !== JavaScript :P
off topic: never understood the name. Javascript isn't even remotely related to Java
-
Java !== JavaScript :P
off topic: never understood the name. Javascript isn't even remotely related to Java
http://en.wikipedia.org/wiki/JavaScript#JavaScript_and_Java
Now shoo.
-
As far as the 'HTML isn't for UIs per se' thing goes, I brought it up in case there's a chance chromium could update in a way that throws things out a bit and leave FSO in an awkward position. If there isn't then I guess it's OK.
-
As far as the 'HTML isn't for UIs per se' thing goes, I brought it up in case there's a chance chromium could update in a way that throws things out a bit and leave FSO in an awkward position. If there isn't then I guess it's OK.
if it did, it would break a ****ton of the web along with us.
-
for what its worth, nothing worthwhile will come out of me WRT the web-based UI. I tried with angularJS and while the basic concept of "break everything down to basic interchangeable blocks" works well, i simply dont have the time to convert the thrice damned interface art to something that might lend itself to any form of resizing easily.
Also, JS is not my particular cup of tea and AngularJS is full of so many potholes and "oh god why?" fun i cant stand it. Still, the bigger issue is getting the interface art out into a web-compatible form.
-
Getting a drop-in replacement for the existing GUI isn't really what we need, since as you've realized, the art is unbearably difficult to work with for something like that. Creating a fresh new interface with the same feel would be the idea in the long run, but something with minimal styling, and all the functionality of a menu represented would be a solid proof of concept. It could just be pages of the options forms represented, and areas that when clicked indicate to the user that it would produce a state change or something. That's roughly how I'm guessing it would integrate into the engine anyway.
-
For my chromium integration I created a very minimalistic and ugly "mainhall" menu: http://www.mediafire.com/download/xh2tm35aijm136c/mainhallTest.7z
It also shows how the JavaScript programmer would interact with the engine.
-
I wish there are registry entries used by FSO. I think they are neglected since the source release.
And there are a lot of configuration settings for all corresponding FRED and FSO builds in the Windows OS folder.
I think moving them to a unified, but separate config file in the FS2 directory will solve all of this. This file is to be used by the in-game UI.
-
Okay. Are you ever going to start helping with this, or are you only going to be an idea guy all the time? Because frankly, we need coders more than we need ideas.
-
Okay. Are you ever going to start helping with this, or are you only going to be an idea guy all the time? Because frankly, we need coders more than we need ideas.
Agreed. :) We're willing to help you along the way, Bryan. But you are, as the idea guy, the best one to implement the ideas because you know exactly what they are.
-
Wait a sec, aren't registry entries a terrible idea? They kill install portability.
-
And you need to use something entirely different on other platforms. The SCP is moving away from that kind of thing with Antipodes.
-
Yes. I'm going to help. I have made a FS2 Open fork on GitHub weeks ago. If I indeed have, where do I start for making an ingame UI for commandline settings?
To General Battuta and Phantom Hoover, I agree this is a problem, and we need to use something entirely different on other platforms. Perhaps, a unified model of supporting different platforms, as well as future platforms (iOS, Android, Windows Phone, PS4, or Xbox One).
What about Lua as "super-script"?
-
What about it? Whatever it is, the SCP aren't going to code it for you, they have their own ideas that they're busy with.
-
There already is a model that works on all platforms we support. What I want to see is that we move everything to the same model we use on Linux, Unix and MacOS (that being a config file in the user directories these OSes provide for that purpose). There is no need to reinvent the wheel, just a need to bring the Windows exe in line with the other ones, and implementing that model in wxLauncher.
-
I have been doing some initial work on converting all config file related path handling to use SDL_GetPrefPath instead of using some platform specific method of determining that: https://github.com/scp-fs2open/fs2open.github.com/pull/282
That will make sure that every platform can use the same code for locating the config files. That should make adding config file support for Windows a bit easier.
-
How about the Settings (https://msdn.microsoft.com/en-us/library/windows/apps/jj712233#settingsflyout) flyout in Windows 10? m!m, I guess that this makes extensive use of SDL_GetPrefPath.
-
We will very definitely not implement anything that is so strongly married to a single platform.
-
How about the Settings (https://msdn.microsoft.com/en-us/library/windows/apps/jj712233#settingsflyout) flyout in Windows 10? m!m, I guess that this makes extensive use of SDL_GetPrefPath.
That has a lot of reasons why we can't use it:
- It's not in the native UI of the game thus it is not suited for an ingame UI
- It's a Windows only option, there is nothing comparable on Linux (I'm not sure about Mac)
- Please take a look at what SDL_GetPrefPath (https://wiki.libsdl.org/SDL_GetPrefPath) actually does. It has nothing to do with the user interface
-
That said, I wouldn't be so hasty. If someone wanted to add something that improved UX on a particular platform without interfering with anything on other platforms, I don't see a reason we wouldn't want to implement that.
-
Sure. But something like an improved Ingame settings menu is not the right place for this. That's something that should be the same for all platforms, I believe.
Basically, if it's something that can be hidden from the user, some backend code or something, I don't have many problems with it. But the UX should be as close as possible wherever the game is run.
-
I think a backend code should do it, but where do I begin?
-
I think a backend code should do it, but where do I begin?
If you haven't done so already, check out a copy of FSO. (http://www.hard-light.net/wiki/index.php/Guide_to_FS_Open_and_git)
From there, it's up to you as to where you want to go. I'd recommend outlining the basic goals of what you want to do and then just dive into the codebase.
-
I've done a copy of FSO: https://github.com/bryansee/fs2open.github.com (https://github.com/bryansee/fs2open.github.com).
-
Well its a start, but you've still got a ways to go. :)