Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: m!m on February 13, 2017, 05:18:19 am

Title: Possible new UI systems for FSO
Post by: m!m on February 13, 2017, 05:18:19 am
The current systems for presenting a user interface in FSO are severely lacking. The first system is to one used to render the main UI (e.g. options menu, briefing screen, ...). It is limited to the two main resolutions and is unable to scale correctly to the screen size which means that this system is not usable for adding additional user interfaces and upgrading it would be a monumental task. The second system ist the WMCGUI which is used in the lab but that is a pain to work with. There is a third option which involves rendering the UI with Lua (and that has been done already by some recent mods thanks to the system developed by Axem) but I will take a look at that option later.

My primary goal would be to build a new system that could be used and extended by mods to provide custom UI screens. I have looked at a few third- and first-party solutions and I will list the advantages and disadvantages I see if we would use these systems. Here is my list (in no particular order):

I have no strong preference for any of the solutions but IMO libRocket and CEGUI are probably the best solutions but I would like to hear alternative thoughts about that.

Those are all the solutions that I can think of at the moment. If you have an alternate solution then please add it below and I'll update this list. I would like to hear some thoughts from both coders and modders so we can find the best solution for everyone involved.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 14, 2017, 08:12:18 am
I have done some research and it appears that neither CEGUI nor libRocket support animated images directly. I found some resources which describe how such a feature could be added but it is not supported natively (the custom HTML engine obviously also doesn't support it).
Title: Re: Possible new UI systems for FSO
Post by: niffiwan on February 14, 2017, 05:07:24 pm
Well that's a pain, like you I'd considered those two to be the best to integrate. Do all the other options support animated images?
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 15, 2017, 03:08:26 am
APNG support can be added to CEF but AFAIK it's not supported natively. There is a Chrome extension for APNG display so it is definitely possible with some JavaScript. EFFs will not work since they are a custom FSO format.

I haven't looked at MyGUI in detail but it's pretty simplistic so I wouldn't expect it to have support for that.

The Lua solution obviously supports it since that uses our rendering code.
Title: Re: Possible new UI systems for FSO
Post by: Dragon on February 15, 2017, 05:51:22 pm
TBH, I don't think that something as bloated as Chromium is a good idea for FSO. I don't know what exactly do you mean by "UI", but if it messes with either the HUD or the pause dialog, it needs to run in-mission and not degrade performance. And even if it doesn't, I certainly wouldn't want loading times to go through the roof just because of UI (models and textures make it long enough). One thing I noticed about Chromium-based browsers is that they tend to gobble memory (Opera 12 FTW).
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 16, 2017, 02:55:07 am
Performance wise, Chromium isn't too bad since the rendering doesn't actually happen in the FSO process but you are right that it is quite bloated which is why I currently prefer libRocket or CEGUI.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 17, 2017, 06:22:32 am
Since there haven't been any responses which favor a particular solution, I'll go ahead and try to integrate libRocket into FSO (I still have other stuff to do so it may take some time). I'm confident that I can integrate the existing lua bindings into FSO so modders will have full support for how the user interface behaves and looks. There are quite a few existing samples for libRocket so feel free to take a look at them. Here is a sample from the libRocket repository: https://github.com/libRocket/libRocket/blob/master/Samples/luainvaders/data/game.rml
Title: Re: Possible new UI systems for FSO
Post by: chief1983 on February 17, 2017, 07:21:33 am
Hopefully though, we create native menus for native engine features, so modders would only need to be adding menus for things the mod itself has added, probably via scripting.  Would feel weird to have to write Lua menus to access things in the engine itself, right?
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 17, 2017, 07:28:29 am
What would be the advantage of locking down "native" menus this way? If possible, those screen could also be replaced with RML/Lua so that it can be made as flexible as possible.
Title: Re: Possible new UI systems for FSO
Post by: The E on February 17, 2017, 07:36:28 am
Yeah, at this point, I am convinced that the best way to do this is by eating our own dog food. If the end goal is to create a system that can be easily used from within lua, it makes little sense to then hardcode a bunch of stuff when we can just as well use embedded scripts that can be overridden by modders.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 17, 2017, 08:40:15 am
I want to add that an initial implementation would only allow modders to use whatever system we use to define additional screens. Porting the old UIs to the new system will likely require some additional lua API functions so it doesn't make sense to include that in the initial version.
Title: Re: Possible new UI systems for FSO
Post by: chief1983 on February 17, 2017, 11:39:56 am
Not every FSO dev also knows Lua, but it would be nice for them to be able to help expand and maintain the menus for primary engine features that have been added.  But embedding some Lua that does that works too I suppose.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 17, 2017, 12:09:38 pm
Lua isn't that hard to learn but I understand your point. I would like to create a system where a mod could say "Hey, I want the briefing text to flicker randomly because the ship is damaged" or something like that. A native C++ solution would require code changes that would need to be maintained by the devs for something that might only be used once. If we have a Lua driven UI then that feature can be implemented in a custom mod and the SCP never has to worry about that. I would like to keep the UI easy to develop for SCP devs as well but I don't see a way of keeping the customizability of a fully scripted UI while still using C++.
Title: Re: Possible new UI systems for FSO
Post by: chief1983 on February 17, 2017, 12:19:43 pm
I'm mostly just talking about any out of game menu, to control the actual things that the engine supports, that are currently controlled by command line options, etc.  People have clamored for an expanded options menu to adjust those kinds of things for years.  Especially all the graphical options, at some point enhanced input device control, etc.  I don't really see the need for Lua extensibility there as much as for them to be maintainable by the widest number of developers.  Adding Lua hooks to allow menus like that to be expanded even farther would be great, just not sure I want a situation where only devs that know Lua can maintain menus that were added to control those kinds of features.  We're not suggesting we actually replace existing menus with this kind of system though are we?  Although I guess something would have to be done make any new menus actually accessible.
Title: Re: Possible new UI systems for FSO
Post by: mjn.mixael on February 17, 2017, 01:30:33 pm
As much as you might say LUA is easy to learn, that's relative to other code languages. You may find it simple, but I've tried many times to learn it and just can't get a grasp on it.

I'm not saying don't use it for this at all. Just keep in mind that not everyone speaks computer as well as you SCP guys.

EDIT: I think what I am saying is that with continuing to add more LUA, more coders might find themselves faced with more script/LUA requests and to be OK with that. :)
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 17, 2017, 02:45:43 pm
I'm mostly just talking about any out of game menu, to control the actual things that the engine supports, that are currently controlled by command line options, etc.  People have clamored for an expanded options menu to adjust those kinds of things for years.  Especially all the graphical options, at some point enhanced input device control, etc.  I don't really see the need for Lua extensibility there as much as for them to be maintainable by the widest number of developers.  Adding Lua hooks to allow menus like that to be expanded even farther would be great, just not sure I want a situation where only devs that know Lua can maintain menus that were added to control those kinds of features.  We're not suggesting we actually replace existing menus with this kind of system though are we?  Although I guess something would have to be done make any new menus actually accessible.
Replacing existing menus with the new system is definitely something that I would like to do at some point once we have a functioning UI system in place. The current UI is old and suffers from a lot of issues such as being unable to scale correctly to widescreen resolutions which could be fixed with the new UI system. Running the UI from within the engine would require duplicating a lot of systems such as event handling that would be handled pretty much automatically in Lua. I'm not a huge fan of introducing another language but at least for an options menu we could make the lua API function in such a way that it would be easy to add new options without having to edit the Lua code.

As much as you might say LUA is easy to learn, that's relative to other code languages. You may find it simple, but I've tried many times to learn it and just can't get a grasp on it.

I'm not saying don't use it for this at all. Just keep in mind that not everyone speaks computer as well as you SCP guys.

EDIT: I think what I am saying is that with continuing to add more LUA, more coders might find themselves faced with more script/LUA requests and to be OK with that. :)
That's not really news since every UI change requires a code change at the moment but with a new UI system it would actually be feasible to change the code :p

The huge advantage of a markup language based system is that a modder can change how the UI looks without having to worry about how it behaves and, if required, the behaviors can be changed without having to dive into engine development which can get a lot more complicated than editing a few lines in a more or less simple Lua script.
Title: Re: Possible new UI systems for FSO
Post by: mjn.mixael on February 17, 2017, 02:54:06 pm
:yes:
Title: Re: Possible new UI systems for FSO
Post by: AdmiralRalwood on February 17, 2017, 05:01:54 pm
I'm all for replacing the existing UI entirely; after going all over the UI code as part of making the FS2 demo data not crash, I discovered that our UI code is even more of a complete mess than I only vaguely thought it was (as part of the PR that fixed demo compatibility, I fixed at least one instance of a bitmap that never unloaded until FSO closed... not by design, but because it was unlocked/released in the wrong order).
Title: Re: Possible new UI systems for FSO
Post by: Axem on February 17, 2017, 05:25:14 pm
So how does one make a UI with librocket, exactly? You say its something that looks like html (and boy does it) but can we use like html... things to preview UI screens?
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 18, 2017, 02:51:51 am
No, unfortunately libRocket uses its own dialect of HTML so you won't be able to preview it in a browser. It has a visual debugger tool which allows you to inspect the properties of individual elements and I'm sure that I could add "Reload" option so you can edit the markup without having to restart the game.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 19, 2017, 02:53:37 pm
I have an initial working implementation of the libRocket integration into FSO:

(http://i.imgur.com/zQBumn9.png)
(the text and the image in the top left is the stuff that was drawn by libRocket).

Implementing the required interfaces was actually pretty straight forward and upon closer inspection, the framework seems flexible enough for our purposes. I still need to implement the animation display but hopefully that won't require too much effort.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 21, 2017, 12:28:49 pm
Development update:
(http://i.imgur.com/VgwgpeF.png)

I have added support for handling input and I also already a few debug features. All current documents can be reloaded with Ctrl+Shift+R so modders don't have to exit the game to test their changes. Also, I added support for activating the integrated debugger which is also shown in action above.

However, while adding these new features I have also found a few bugs in libRocket and since development has pretty much stopped at this point we would have to fix all the bugs we find ourself. The development time so far has been pretty minimal so this would be a good time to reconsider alternative solutions if they exist.
Does anyone have a solution that could work better than libRocket?
Title: Re: Possible new UI systems for FSO
Post by: chief1983 on February 21, 2017, 12:31:36 pm
Is it that dead?  They had commits as recently as November.  Someone might still be merging PRs.
Title: Re: Possible new UI systems for FSO
Post by: The E on February 21, 2017, 01:21:56 pm
They've had commits, but they also have an untreated bot infection on their main forums and no releases in two years.
Title: Re: Possible new UI systems for FSO
Post by: jg18 on February 21, 2017, 01:57:25 pm
Yeah IMHO we can't use a library  that isn't actively developed/supported/maintained, as cool as this library sounds. Besides bugs that may never be fixed, if compatibility with for example future OS changes breaks, we'll be up the creek.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 21, 2017, 02:11:56 pm
Do you know another solution? Even in its current state it's pretty good so "no longer in development" would just go into the "Reasons against" list which would not automatically disqualify the library.
Title: Re: Possible new UI systems for FSO
Post by: The E on February 21, 2017, 02:39:44 pm
I would agree. Given that this library isn't built on top of OS functionality (Like wx), I think the risk of running into incompatibilities is reasonably low, and if the necessary bugfixes are trivial, I see no real reason not to use it.
Title: Re: Possible new UI systems for FSO
Post by: jg18 on February 21, 2017, 03:11:20 pm
Okay, then.
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 23, 2017, 04:40:55 am
I think I'm more or less done with the initial integration. GitHub branch is here: https://github.com/asarium/fs2open.github.com/tree/feature/libRocket

This should support everything that is needed for most UI screens. It doesn't have support for animations yet but it should be possible to add support for that at some point by adding a new element type. The current version even has support for localization since that is pretty easy to support thanks to how libRocket works.

I'll try to go ahead and build an options menu using this library which will probably expose a few more bugs.

Also, I currently named the new system simply "NewUI". Does anybody have a better name for it?
Title: Re: Possible new UI systems for FSO
Post by: X3N0-Life-Form on February 23, 2017, 06:34:08 am
SCPUI ? RocketUI ?
Title: Re: Possible new UI systems for FSO
Post by: m!m on February 23, 2017, 11:01:34 am
I like SCPUI, I'll use that.
Title: Re: Possible new UI systems for FSO
Post by: karajorma on February 24, 2017, 12:14:55 am
You should have gone with Even Snazzier UI. :p
Title: Re: Possible new UI systems for FSO
Post by: Darklord42 on March 18, 2017, 09:01:58 am
Sounds really neat!  I suppose since it is dead,  future maintainability is important to you, and you intend on making it mission critical,  why not fork it and make it a sub project of FS2O on git?   Especially since you say currently no work needs to be done on it, and it has an MIT license.
Title: Re: Possible new UI systems for FSO
Post by: m!m on March 18, 2017, 09:04:51 am
I already use a fork of the project in my development branch. If it gets merged into the master then that fork would be transferred to the SCP organization.
Title: Re: Possible new UI systems for FSO
Post by: Darklord42 on March 18, 2017, 09:11:39 am
Oh great!  Then problem solved, right?
Title: Re: Possible new UI systems for FSO
Post by: m!m on March 18, 2017, 09:12:57 am
No, the fundamental problem that the project isn't in development anymore still exists.
Title: Re: Possible new UI systems for FSO
Post by: Darklord42 on March 18, 2017, 09:18:22 am
But you intend to fill that role for your own purposes.  If you can manage it, sometimes it's better not to have to rely on an upstream team as you know your needs better then anyone else. And this is already mature software, right?
Title: Re: Possible new UI systems for FSO
Post by: m!m on March 18, 2017, 09:20:12 am
I would like to avoid maintaining a code base I have no experience with. It would be better if I could just report a bug to upstream and get some help with fixing it.
Title: Re: Possible new UI systems for FSO
Post by: Darklord42 on March 18, 2017, 09:25:19 am
I'm not saying being a pain isn't a con, but there are other advantages to it.  Eventually making it your own is one.

But, if the code is a mess and not maintainable or isn't commented very well, then that should be a good strike against it.
Title: Re: Possible new UI systems for FSO
Post by: karajorma on March 20, 2017, 03:33:06 am
Maybe the fact that it's being used might get some of the original team interested again. Might be worth a try to use the old "I'm interested in using your library in my software, I've got it working but I was wondering if it's still in development" trick. :)
Title: Re: Possible new UI systems for FSO
Post by: Eli2 on March 25, 2017, 05:08:02 am
I am watching the game gui space for a few years now, and to be honest, i am not sure what the right course of action is.

Freeablo recently removed libRocket (https://freeablo.org/?p=105 (https://freeablo.org/?p=105)) not sure if mygui is the best choice thou.
Overgrowth switched their editor gui (in Beta 2), from embedded browser (awesomium i think) to imgui.
CEGUI seems to be the largest/active library in this space.

I don't have any solutions to offer but i am eagerly watching this space to see how it plays out.
Title: Re: Possible new UI systems for FSO
Post by: m!m on March 25, 2017, 11:10:58 am
CEGUI seems like a good idea for a UI controlled by the engine C++ code but scripting access is an absolute must-have for the new UI system and I can't find much information about lua support for CEGUI.
Title: Re: Possible new UI systems for FSO
Post by: Bryan See on March 27, 2017, 12:52:05 pm
CEGUI seems like a good idea for a UI controlled by the engine C++ code but scripting access is an absolute must-have for the new UI system and I can't find much information about lua support for CEGUI.

There's lua support for CEGUI. Check this out: http://cegui.org.uk/wiki/Getting_Started_with_Lua_and_CEGUI (http://cegui.org.uk/wiki/Getting_Started_with_Lua_and_CEGUI)

And what about the interface.tbl support? Can CEGUI support this?
Title: Re: Possible new UI systems for FSO
Post by: The E on March 27, 2017, 12:55:23 pm
interface.tbl currently does nothing and we have made no firm decisions about how we are going to define interfaces in the future.
Title: Re: Possible new UI systems for FSO
Post by: m!m on March 27, 2017, 12:56:46 pm
There's lua support for CEGUI. Check this out: http://cegui.org.uk/wiki/Getting_Started_with_Lua_and_CEGUI (http://cegui.org.uk/wiki/Getting_Started_with_Lua_and_CEGUI)
I am aware of that page but I first need to check if integrating CEGUI into FSO is possible at all.

And what about the interface.tbl support? Can CEGUI support this?
No, CEGUI would use its own markup language for defining interfaces so there is no need to use our own markup language.
Title: Re: Possible new UI systems for FSO
Post by: Bryan See on March 27, 2017, 01:04:03 pm
interface.tbl currently does nothing and we have made no firm decisions about how we are going to define interfaces in the future.
I'm keeping this in mind when it comes to this, as with other features I've planned since 2009.

And what about the interface.tbl support? Can CEGUI support this?
No, CEGUI would use its own markup language for defining interfaces so there is no need to use our own markup language.
What about mission loading screens? Animated? Pre-rendered? Real-time? 3D? Independent-resolution ones? Can they be in 3D theoretically (as cockpit displays or space signages)?
Title: Re: Possible new UI systems for FSO
Post by: m!m on March 27, 2017, 01:08:12 pm
What about mission loading screens? Animated? Pre-rendered? Real-time? 3D? Independent-resolution ones? Can they be in 3D theoretically (as cockpit displays or space signages)?
I have no plans of adding support any of those applications at the moment.
Title: Re: Possible new UI systems for FSO
Post by: jr2 on March 27, 2017, 03:33:41 pm
(https://media.giphy.com/media/1pw5Hn77ylYxW/giphy.gif)
Title: Re: Possible new UI systems for FSO
Post by: Bryan See on July 04, 2017, 01:22:28 pm
Anyone has updates on any UI system selected for FSO? It's been almost three months since the last post made on this thread...
Title: Re: Possible new UI systems for FSO
Post by: m!m on July 04, 2017, 02:46:52 pm
There are no updates here.
Title: Re: Possible new UI systems for FSO
Post by: m!m on August 29, 2017, 09:13:26 am
I have evaluated the integration of CEGUI and have come to the conclusion that integrating that system would take a lot more work than libRocket for no apparent benefit. Unless someone finds a very good reason for not using libRocket, I will submit the changes for code review within the next few days so that the system can be tested in the nightly builds.
Title: Re: Possible new UI systems for FSO
Post by: BirdofPrey on August 29, 2017, 08:17:23 pm
Hey, just noticed this.  Is there a good place to learn how to use this to make a custom UI?
I was bored a year or two ago, and started working on what was supposed to be a higher resolution, widescreen version of the old FS1 UI before everyone stopped me and told me the engine wouldn't support it, then everyone spent a few weeks arguing what would be the best solution.
I should still have my files and workflow somewhere.
Title: Re: Possible new UI systems for FSO
Post by: m!m on August 30, 2017, 03:43:41 am
The proposed system (libRocket) uses a markup language similar to HTML and CSS. User interaction will be controlled by Lua if custom actions are required.
There are a few tutorials available in the homepage of the project: http://librocket.com/wiki/documentation
There will be a few special things to consider when using libRocket in FSO but for the most part everything will work just like the tutorials explain.
Title: Re: Possible new UI systems for FSO
Post by: BirdofPrey on August 30, 2017, 08:06:37 am
Thanks, that's helpful.
Are there application specific tags for FSO I'd need to worry about, though?  I'm guessing at this stage you don't have proper documentation on what all the bits do.

On a side note, is this just game menus, or are you expanding it to be able to replace the Mainhall and HUD code as well eventually?
Title: Re: Possible new UI systems for FSO
Post by: The E on August 30, 2017, 08:43:47 am
The Mainhall, maybe. The HUD, probably not. The HUD in particular is already very customizable and scalable, so the two major factors driving the effort to introduce a new menu system aren't an issue there.
Title: Re: Possible new UI systems for FSO
Post by: AdmiralRalwood on August 30, 2017, 08:46:51 am
Mainhalls also have support for HD graphics and Lua-scripted doors, so I'm not sure there's much need there, either (but I guess making the whole menu system consistent might be desirable).
Title: Re: Possible new UI systems for FSO
Post by: BirdofPrey on August 30, 2017, 09:10:23 am
The Mainhall, maybe. The HUD, probably not. The HUD in particular is already very customizable and scalable, so the two major factors driving the effort to introduce a new menu system aren't an issue there.
Very true (though the 3D radar is in need of a refresh, both to look better/more modern and consistent with the rest of the HUD and also to work properly with radar icons).  I also had some recommendations for altering how radar icons are tabled to allow for a graceful fallback if a ship isn't specifically tabled for a specific icon (and would also separate the UI aspects out of the game interaction aspects in the ship tables), but I don't think anyone cared at the time.  That's not entirely on topic here, though.
Mainhalls also have support for HD graphics and Lua-scripted doors, so I'm not sure there's much need there, either (but I guess making the whole menu system consistent might be desirable).
Consistency is what I wondered more about.  I know the Mainhall and HUD codes work fairly well right now, but at the same time that's three separate systems to both maintain code for, and multiple syntaxes modders have to learn and remember to change the entire UI/UX for a mod.
There are, of course, arguments on both sides; particularly, the current HUD code is fairly easy to understand because it's a simple system, merging it with this might make it more complicated.
Title: Re: Possible new UI systems for FSO
Post by: m!m on August 30, 2017, 03:58:48 pm
You can already replace the entire mainhall UI with a scripted interface so it would be very easy to use this new system to recreate the mainhall UI but it currently does not have enough features for actually rendering a proper mainhall since animated images are not supported yet.

Also, the 3D radar is (as the name says) a 3D element so that absolutely cannot be replaced by libRocket since that can only handle 2D interfaces.
Title: Re: Possible new UI systems for FSO
Post by: m!m on August 31, 2017, 07:09:14 am
I created the pull request for these changes: https://github.com/scp-fs2open/fs2open.github.com/pull/1466
Title: Re: Possible new UI systems for FSO
Post by: BirdofPrey on August 31, 2017, 11:47:30 pm
You can already replace the entire mainhall UI with a scripted interface so it would be very easy to use this new system to recreate the mainhall UI but it currently does not have enough features for actually rendering a proper mainhall since animated images are not supported yet.

Also, the 3D radar is (as the name says) a 3D element so that absolutely cannot be replaced by libRocket since that can only handle 2D interfaces.
I was more intrigued than anything.  The current stuff works already, so I have no pressing desire to see the HUD and mainhall stuff replaced, I was more interested in how far you were planning to take this.
The lack of animation support is quite a bummer, though.  Does it at least allow for embeded video?  Without those, the command briefings aren't going to work, since they usually include video clips. 
Title: Re: Possible new UI systems for FSO
Post by: m!m on September 01, 2017, 01:38:28 am
Command briefings are the same as generic animations since they both use the same code for loading and displaying them. I'm confident that I can find a solution for adding animation support but it may involve hacking around the libRocket interface a bit but that's not too bad. I wanted to get the initial implementation out of the door to let people test that version instead of delaying the changes for animation support.
Title: Re: Possible new UI systems for FSO
Post by: m!m on September 01, 2017, 08:00:43 am
I added support for drawing animations but I will delay adding that until the main system is merged. There is enough code in that change set already. There is no reason for adding even more code.
Title: Re: Possible new UI systems for FSO
Post by: Arkblade on September 09, 2017, 04:31:04 pm
hi, this new system allow possibility of 2-byte language translation? japanese still needed show 2-byte language system.
FS1/2 already translated, but not having method of that implement to game.
Title: Re: Possible new UI systems for FSO
Post by: m!m on September 10, 2017, 04:10:15 am
This new system would be able to display Unicode characters but FSO is currently not able to read the translations in the tstrings table. That is a separate project which I am also working on but as far as the new UI system is concerned there is nothing stopping it from displaying Unicode strings.
Title: Re: Possible new UI systems for FSO
Post by: m!m on January 06, 2018, 05:48:39 am
So, it finally happened. The libRocket website appears to be down and there are no reactions from the original developers on their GitHub repository so I guess that means that the project is abandoned by its original authors. The documentation has been mirrored (Link (https://barotto.github.io/libRocketDoc/)) so at least that is still available online. I also downloaded everything I could from the original website so at least nothing was lost there.

I still think that libRocket is a good solution for an extensible UI framework even though it is no longer actively maintained. I updated my test branch so that it has the latest changes from the master branch:
Test builds: http://swc.fs2downloads.com/builds/test/libRocket/
Test mod: http://www.mediafire.com/file/eo15507zh0nwdxa/libRocket.zip/file

Since libRocket only support Unicode text I added a check that enforces the usage of Unicode text mode when the new UI system is active. The test mod above already contains all the necessary changes for that to work. Please let me know if anyone wants to experiment with the build and I will write a more extensive post about how to use the new system.
Title: Re: Possible new UI systems for FSO
Post by: CountBuggula on July 14, 2018, 08:33:00 pm
This (https://github.com/Qfusion/libRocket) is the only semi-active fork of librocket on github.  At least it's nice to see that someone is working on it.