DevBlog: The quest for UI

As some of you may know, I have recently finished writing exams for this semester, so I now have a chance to write about a few things.

Some of you may also know that for the past few years, sandbox has shipped with an alternative UI system, otherwise referred to as newui. It's actual name is UI, and we will be referring to is as such from now on. This UI was originally written for a commercial game named bloodtoll and according to neal, it has diverged significantly from that point.

Compared to 3dgui, the current default, UI offers far more flexibility when it comes to defining the appearance, layout and actions of the elements as well as general larger variety of interesting and unique elements. With that said it lacks several elements we desire, contains several dozen bugs and coupled with the fact that pretty much no one knew how to use it 2 years ago really stymied its adoption.

Some of you may remember a screenshot I posted on moddb back in 2010 when graphitemaster joined us temporarily and revived interest in UI (he got it working again too, so hi-five for that).
This renewed interest in the system for some time and this was enough for us to learn how it worked, fix a bunch of bugs and document it as well as we could on the wiki.

UI once again fell into limbo at this stage. The most breaking change since that time in 2010 is the introduction of the -fno-rtti optimisation flag. UI relies heavily on dynamic_cast<> which in turn depends on Real Time Type Information being available. This means it failed to compile with the 2.6.0, 2.6.1 and 2.7.0 releases. I've since fixed it after preparing the final Windows and Linux builds for the 2.7.1 release and to my knowledge, calimer has included the changes as well as some miscellaneous work I did on UI when he packaged 2.7.1.

Another factor that might've stymied production is the way UIs are handled. You essentially have named windows or blocks, of which you can have several on display at any one time. In theory you can also use UI to draw the game's HUD. hideui, the command to close them, is based on using a name, as opposed to cleargui from 3dgui which accepts a number equivalent to the amount of GUIs to close. In short it's very inconvenient to have more than one UI in which you do things.
Our first attempt at using newui was admittedly quite poor and didn't really facilitate this very well. We had multiple UIs and placed the UIs definitions inside a large show@menu block. We also received a batch of art from Leo at the time, it was quite "tragic" and combined with some of the other factors, this is more or less when UI when back into limbo.

We've picked it up again and we hope to have UI replace the old 3dgui by 2.8.0, we unfortunately have a LOT of work to do before the switch is even feasible.
For starters, there are the missing elements, there are basically 3 scenarios we need to be able to cover which the current UI facilities don't provide. As follows they are...

1. a guislider equivalent
2. some sort of dynamic text
3. a guifield equivalent
4. a guikeyfield equivalent
5. the ability to wrap text

We can more or less tackle the first case by jury-rigging the scrollbar code to function as the sliders and this is the approach I've taken, so our sliders have scrolling areas as well as a button in the centre to signify its position. While this has been completed, it's still a bit buggy, for example it handles integers (read: ID_VAR) very poorly. In addition it also lacks 2 capabilities I'd very much like some sort of "onchange" scrip and the ability to scroll up/left and down/right usign the mouse wheel or even the appropriate directional keys.

The second item has already been done, scrapped and redone. The first iteration was known as VarText (and is likely the rendition that made it into 2.7.1) and it basically did something similar to the sliders. Upon creation it searched for an ident (read variable) with the appropriate name and stored a pointer to it. From this is received a string and drew that every update.
I eventually scrapped it in favour of its second iteration, known as EvalText. The principle is similar but it instead stores a command that is executed every update to produce the string it should display. VarText equivalency could be achieved easily enough with "result $lookup" using this method and allows us additional flexibility in setting up some more complex templates (list/name sliders anyone?).

3 and 4 are very similar, but will require some effort. I have not attempted this yet but it will basically involve creating an editor, and setting the variable whenever it's committed. It shouldn't be too difficult - hopefully I'll manage.

as for #5. I found it quite annoying that text couldn't (or rather didn't) wrap. I quickly wrote a hack that adds ane xtra parameter to the ui*text commands, used for defining the length using a floating point. This was modulated using the text scale and turned out very accurately. A value of 0 or lower will pass a wrapping value of -1, which means it won't wrap at all.

Since the time in 2010, Leo has made a slightly better theme and the menus have been more or less rewritten. Everything's designed on operating mainly around one window, main. Nearly everything will spawn the main menu at a set location. If you want the F2 texture menu, the menu will spawn in the editmode section with the texture tab focused, If you want to spawn the quickedit menu, it will do likewise but within a secret area.
There will obviously be a few exceptions. For example the scores menu for the FPS, we'd summon and update by means of keyrepeat and close it when the key is released. The cubescript for this will be as follows.

/bind TAB [ showscores; onrelease [hideui scores] ]

For the RPG this would be your dialogue and playerinfo menus.

TL;DR
For those of you who are too scared to give newui a spin, I've uploaded some more screenshots to moddb
You can find the 7 or so starting at here.