[Grug]

How is the interface stuff coming along?

I was just wondering if it was at all possible to make some type of compatability with xml or other web standard so ingame GUI interfaces could be drawn like a web browser type of thing...?

[taylor]

It's in progress, but won't be available for quite a while.  It will use existing parsing stuff and new UI code though, no reason to dump a huge xml parser in there just for the interface.  The interfaces won't be browser style (I hate that crap), but they will be highly customizable.  Each screen will have a series of things that it can/must do, but how you lay that out will be totally up to the designer.

I've got a billion other things to work on before I get back to the new interface stuff though.

[Nuke]

i dont see why we just cant improve the lua script interface. add functions to display and change settings, buttons are already doable. arent there already hooks for pretty much every screen in the game interface? hard stuff like supplying all the functionality of say the controls editor would probibly be a hard thing to script, but it could be done.

[taylor]

It can be used, but I won't ever consider it a real replacement for a decent game UI.  Same for the lab UI (even it was ever actually finished).

The current snazzyui code can actually do some neat things.  It needs a lot of updating, but the possibilities are there.  The limiting factor is just that the UI screens are hard coded.  Updating snazzyui with new features and fixes, plus handling the UI through tbl via snazzyui, is a good solution that makes use of existing features and doesn't slap yet another half finished bundle of code into the binary.  We've got too much crap in there already.  There is no reason to reinvent the wheel, we just need to make it better.

[Grug]

Well it sounds good.
Can't wait to see it when its done.

If it's being integrated into table format, is it possible to develop some type of Visual FS2 interface designer program for it?

[taylor]

If it's being integrated into table format, is it possible to develop some type of Visual FS2 interface designer program for it?

Yep, that's the plan.  There will be a full GUI designer (currently dubbed "FLUID", Freespace Lucid User Interface Designer) that you can use to create all of the interface screens.  You will have full control over layout (text, graphics, lists, etc.), hotspot size/position/shape (ie, no reason to go with squares or rectangles for anything, you can have every button be a circle where you have to be on the circle part for it to be active), interface movement (which screen one button will take you to), better support for animated UI elements (fully animated button mouse-over effects, misc animations on any screen, etc.), and customizable fonts (the UI upgrade will include TTF support).  You will then basically just "compile" the interface, which creates the tbl for that interface screen (mainhall.lui, techroom.lui, etc.), and copies that tbl plus all of the interface graphics and fonts you might have used to the location of your choice so that they are ready for use by the game or to make a VP out of.

[Grug]

Sweet. Sounds better than ever.
Only downside is that its just going to be a long while before it sees light of day eh?

[taylor]

Only downside is that its just going to be a long while before it sees light of day eh?

Yep.

Before I get back to work on it, my todo list has these items:
 - bump mapping
 - shader support
 - new animation format to replace interface and talking head ANIs
 - new sound code
 - better OpenGL setup and init code with better extension support and debug logging
 - new pilot file code (with dynamic ship/weapon limits (no more need for a special Inferno build), new input code, full support for non-linear campaigns, significantly improved redalert mission support)
 - re-introduction of official PXO code back into the game
 - new network code to support mods and FSO-only features while maintaining full compatibility
 - new cross-platform launcher and mod support system (moving to cross-platform ini files for everything)
 - cross-platform installer system for mods and FSO, with over-the-internet updater and installer support.

At some point during all of that I will finish with LUI_core (the game code side of the new UI code), then start working on FLUID (the WYSIWYG designer) as more than a on-paper project.

Of course, none of that really gets much attention until 3.6.9 ships since my focus is just on bugs and the basic things that mods need from 3.6.9 (better multiplayer, movies, etc.).  Oh, and I'm still working on FS2NetD too, which has taken up most of my free time for coding the past couple of weeks.

I stay busy. 

[Kazan]

I stay busy. 

way too busy


with Lucid are you planning on having a UI file with each campaign? or a main UI, then a UI extension for that camapign - so we can do context based changes to the UI based on the current status in the campaign, campaign persistant variables, etc (think wing commander 3) - and be able to trigger cutscenes, etc

[taylor]

with Lucid are you planning on having a UI file with each campaign? or a main UI, then a UI extension for that camapign - so we can do context based changes to the UI based on the current status in the campaign, campaign persistant variables, etc (think wing commander 3) - and be able to trigger cutscenes, etc

It's just the main UI, but I do want to get it plugged into scripting at the least (hopefully WMC can help there) and probably variables too, so it could be used like you suggest too.  I'm doing that mainly for two reasons though, 1) more variation of the mainhall that doesn't require more full mainhalls to accomplish, and 2) mission briefing/debriefing interface based status from campaign.  #2 won't actually require support for variables or scripting since I'll be able to figure that out based on mission status, but variables would actually be nice to give even more control.  I'm going to be upgrading variables anyway, since there isn't really such thing as "campaign variables" right now, so any UI stuff related to that will have to wait until after the pilot code since that's where all of the upgrading is going to happen to variables.

Once I get the UI code in a basically usable state I'm going to open it up to the other devs (you and WMC in particular are wanted for this) so anything that I missed or just didn't think of can get filled in.  It will probably need to be expanded beyond what I initially come up with anyway since all of the code that I'm working on now is so closely tied to something else (either the new pilot code or the new launcher related code) in one way or another that I'm bound to be a bit narrow minded on it. 

[Kazan]

since there isn't really such thing as "campaign variables" right now,

i thought there were campaign-persistent mission variables? or am I confused and they're pilot-persistent?

[taylor]

since there isn't really such thing as "campaign variables" right now,

i thought there were campaign-persistent mission variables? or am I confused and they're pilot-persistent?

There are player persistent, and mission persistent (as stored for the campaign).  There isn't really anything at the true campaign level.  I know that there is a conversation about this between Goober and myself either in the internal forum, or in a Mantis bug.  Mantis isn't working for me right now though so I can't check on that, and I don't want to search through internal right at the moment.

(And the pilot file code terminology has changed a bit, since you probably missed that big discussion a few months ago: "campaign savefile" will refer to just what it is, the savefile for the campaign.  "player" or "player file" will be the player/pilot specific file which doesn't have campaign related info in it, basically the old pilot files.  And "pilot" or "pilot file" is a generic term for the combination of the two different files since they are linked at a certain level both in function and in code.)

We are going to go with 3 types in the new pilot code: player variables won't change at a basic level but will have the ability to store/referrence by campaign name, the current "campaign" variables which are stored and used per-mission be be considered mission variables but get little in the way of changes, and a real campaign variable setup will be added which is actually at the campaign level and totally independent of which mission they were used in.

The current version of campaign variables don't properly allow for things like non-linear campaigns, branching, or better loop setups.  This is because the variables are stored per-mission and it walks down the played mission list to find the last time that variable was used to get it's value.  This makes it crucial to have your mission layout and variable usage in a particular way.  The new campaign variables will be just like player variables, except at the campaign level, so you will just have a big pool of variables to work with which aren't tied to any particular mission.  This makes them better for keeping track of campaign progress (available ships, weapons, pilots, etc. if you want to limit them) as well as campaign setup at the design level (such as with BHX which makes use of dynamically generated starfield bitmap layouts).  The player variables are at the lowest level, independent of any mission or campaign and even usable by other campaigns.


Oh, and I just realized that I forgot compressed VPs off of my todo list.  Considering that I've already done all of the research and testing on that I just have to get the time to actually code it up with a slight CFILE upgrade.  That's very low priority though, so it's just when I get bored enough that I'll work on that.

[karajorma]

Taylor beat me to it but we thrashed out the whole thing a while back

You can read about it on this thread from the SCP Internal if you want to.

[Nuke]

sounds intresting.

[Zacam]

Speaking of missions/campaigns and variables......One thing I've noticed is that the keybindings (while rather nice) are still hard-coded-ish in the mission files. Suppose I have re-bound "Deploy Countermeassure" to something other than the "X" key, missions will still ask me to press said "X" key.
ex:
( when ( key-pressed "X" ) ( do-nothing ) )

Now, I don't know if it's already been done, but is there a way to specify in the mission file to use a variable/StaticId/whateverish "USE_KEY_CM" that will register whatever the player has bound to countermeassures?
ex: ( when ( key-pressed "$USE_CM_KEY$" ) ( do-nothing ) )

If it _has_ already been done, where can I get a listing of what the keybindings are called?

[karajorma]

FS2 automatically remaps things like that. If you play the tutorial missions you should notice that the keys you have mapped differently still get the correct keys mentioned in the directives and messages.

[Zacam]

er.....well, shiv me with a straw, it does.