UI-fer Madness

I have a new UI for TR2 now. Graphically, it’s based on Popgirl’s design for the TR web site (the current TR web site, not the new Joomla one the team is working on). Internally, it’s based on a UI sketch Joemac (from TW) let me crib from. And let me just say that I love steal… err, recycling, other people’s code. Especially when it’s in a language I don’t have a lot of experience with. Nothing like debugging code you didn’t write to teach you new things! Anyway, I got a handle on the code, made the modifications I needed to make, and figured out the texture mapping functions Sick programmed for the GUI, and it’s all good. The only thing I didn’t bother to do was make a TR-specific UI Theme, I just used one of Raff’s old themes. Looks pretty good to me, but I think the TR Dev Team may want to go a different direction visually. And that’s fine: all we need is a new texture drawn, and a theme to control how the widgets are drawn. Here are a couple screenshots, one English, one Japanese (slightly different buttons, Japanese version is 1 day newer):

In case it’s not obvious, I should point out that there are no elements of this UI that involve text “frozen” in images. Those buttons are all dynamically generated, with the graphical appearance controlled by Raff’s UI theme, and the text being inserted on top of that by the lua UI. The advantage of that is that you can change text whenever you want, you don’t need to go to a graphics program, save a new image, etc. Localization also becomes dead simple, as you can see from the snapshots. 

Lua Tidbit of the Day: GUI Event Handlers

I’d like to start a new segment that introduces a little bit of lua. The concept I introduce will probably always been related, if not specific to, Targetware 2. Please feel free to post suggestions for topics you’d like to see covered. I don’t have time to cover anything in depth, as every minute I spent on the blog is another I don’t spend on TR2 development!

Probably because I’ve been working on UI stuff for the last few days, I’m going to talk about event handlers. In the TW2 UI system, every control (“widget” in TW parlance) on the screen needs to have an event handler if you want it to do anything. An event handler is nothing more than a function that is called when something happens to the widget. Every UI is going to have a “logoff” or “quit” button of some kind, so let’s use that as an example. Let’s say you have created a widget, and it’s a button, and it’s named “myquitbutton”:

-- event handler for quit/logoff button
function logoff( w, e )
  if e == gui.action then
    client.quit()
  end
end

There is only one line in this code that actually does something: the 4th line, client.quit(). “client” in this case is the TW2 “client application”, running against a server. Executing this command would return you to the TW startup screen. 

So what are “w” and “e”, you ask? In TW2, gui event handlers must be able to handle w and e. The game passes these automatically to the handler. w is the widget that was acted on, and e is the event that occurred. So in line 3, we’re testing to see if the event was a gui action. Most of the time, that’s what you’re going to be wanting to handle. In other words, if this function is set as the event handler for a button, in plain English, it means: “If somebody clicks my button, then log off the server ASAP. If some other event happens, don’t do anything.”

So you’ve written the event handler for your button. The only thing left to do is to teach TW you want the event handler associated with your widget. All you need is a line like this:

myquitbutton:eventhandler():add( logoff )

That’s it for today.