[WMCoolmon]

Okay, I've been doing assorted thinking on the new hud stuff...I'm not particularly eager to start on it, but there seems to be quite a bit of demand now.

So as I see it there are a few different things I could do...

Options
- Upgrade/expand the current system. This would basically let you move around more retail Freespace HUDs and (maybe) choose where custom HUD entries would appear. I could also toss in Bobb's equation system to let you have auto-updating text.

- Get back to work on the new system. This would be much more flexible than the old system. As far as coexistence goes, this would be mostly custom-gauge-centric; rather than make old gauges movable, the goal of this system would be to let you build all the retail gauges from scratch.
Something else I've also thought about doing is integrating it with the GUI code I made for the lab. This would potentially give drag-and-drop abilities, although I'd have to tweak the skinning interface again to make it possible to create new items from interface.tbl.

- Throw in some python scripting. This would work with either system, and would (IMHO) provide an easy and common way to design extremely flexible gauges for use in Freespace 2. The big problem I see is speed; I looked around and didn't see any way to 'compile' Python script, so the code would have to be parsed and interpreted every frame.
This could potentially be ported to other aspects of fs2, and doing this seems to be extremely easy, according to Python documentation; it only requires around 3 function calls to get base python scripting going, and adding new functions seems fairly straightforward. (So you could use "gr.drawLine()" to draw a line, "pv.getString()" to get a persistent variable, "cpn.getName()" to get the current campaign name, etc etc)
And of course if this was integrated with the interface...well, it's something to definitely look into regardless of whether the HUD is integrated.

- Throw in the ability to use SEXPs with hud gauges. Again, this would work with the integration fairly well, but my chief complaint is that SEXP code isn't mainstream. It's apparently based on a fairly well-known language that I've never heard of or seen before Goober or someone linked to an article in the WP. It might solve a few of the speed issues with Python, and would give a number of functions available right off the bat - and of course it would mean coding in any general hud-change functions once, and they'd be available in both the mission events editor and the hud gauges file.
With this, assume you'd have to learn the SEXP syntax.


IMHO
Now, what I see as the ideal situation would be to integrate the new HUD stuff with the interface. Make it possible to design all the various gauges in Freespace2 with the new system. Add in Bobb's equation system.

For retail gauges, get rid of the old hud_gauges.tbl system. Then have a table with all the retail gauges in it using the new table format. Retail gauges would automatically turn off if the new system were used.

Then, throw in Python scripting with a base library of functions to draw gauges. This would be used in the event you needed an extremely complex gauge, ie something along the lines of the radar. Ideally you'd be able to do everything without Python (it'd be more efficient).

Cons: It'd be a pain in the ass to get done, and someone would have to code the retail gauges. This would provide a great starting point for any mods using the system, since they could always turn to the retail gauges in new HUD form to see how stuff was done.

Postword
I haven't considered any other languages besides Python; if there's one that can be interpreted and compiled when the program starts, and executed multiple times afterwords, and is multiplatform, it'd be perfect for this. Something that's difficult to learn (ie Perl) is out.

That's a pretty broad overview, despite being so long. Obviously I'll be waiting 'til after 3.6.7 is out to start work on it...and this time I'll actually sit down and try to design everything, instead of making major revisions 5 times. (Try to narrow it down to 3 or so. )

The bulk of the process will probably have to be completed within the next 2.5 weeks. I'd hoped to be doing more this summer IRL, but that hasn't worked out, so I've got a lot of time.

[Bobboau]

if you'r going to totaly start from scratch you could do what I'm going to do with the materials system (a system that completely replaces huge swaths of specal case code with a central text based script, like the HUD would be) namely, ignore the posability that there won't be a table for it and then when your done, make a hard coded table to be used if there is none that mimics the origonal behaviour.

I was also thinking that this could be merged with the materials system and made into more than just a HUD, but a general overlay system wich would give a robust means of controling both the HUD and post processing effects, all you'd need for this is something that has a struct for rectangles based on expressions (or what ever we end up useing) and the ability to nest sub elements within an ellement. also mergeing with the materials system would mean that the materials for drawing cockpits in game would be ready and waiting. you would still need a table for loading texture sets and constants, as well as the coords obviusly.

[Starman01]

I have to admit, that I don't understand everything in here, but this sounds amazing ! This would be an awesome addition to that game and every mod around.

[mrduckman]

would this help?

http://www.python.org/doc/2.4.1/tut/node8.html#SECTION008120000000000000000

[DaBrain]

Originally posted by Starman01
I have to admit, that I don't understand everything in here, but this sounds amazing ! This would be an awesome addition to that game and every mod around.

What he said.

[WMCoolmon]

Originally posted by mrduckman
would this help?

http://www.python.org/doc/2.4.1/tut/node8.html#SECTION008120000000000000000

Originally posted by Bobboau
*stuff*

Well, I don't mind having the materials system in there at all (aside from the extra work), but I'm not exactly sure what you're saying. RTT is also in there somewhere, so what would I have to do to leave it open as a possibility?

[WMCoolmon]

Preliminary thoughts:

Code: [Select]

#HUD gauges
$Gauge: DamageGauge
{
$ShowLoc: ("cockpit" "external cam")
$ScreenAlign: TM
$GaugeAlign: MM
$Pos: (0px 10px)
$Text: self.HullPct()
}

$Gauge: StealthStatus
{
$ShowLoc: ("cockpit" "external cam")
$ScreenAlign: MR
$Pos: (-10 px 0px)
$Text: self.StealthStatus()
}
#End

#HUD screens
;; (Global) means that gauges are shown in all screens
$Screen: (Global)
{
$Gauge: GreenThing
{
$Pos: (0f 0.1f)
$RlcImage: monster
}
}

;; (Debug) means that gauges are shown in all screens, and
;; ShowLoc is overridden so they show at all times in-game
$Screen: (Debug)
{
$Gauge: FPS
{
$Pos: (10pc 0pc)
}
}

;; Normal screen
$Screen: Terran
{
$Gauge: DamageGauge
}

;;This is for the Erinyes fighter
$Screen: Toothpick
{
+Screen: Terran ;;Include the Terran base HUD
$Gauge: Stealth
}
#End

Then in ships.tbl:

Code: [Select]

$Name: GTF Erinyes
...
$HUD: Toothpick

As you can see I'm thinking of having HUD gauges be separate objects, that can be defined at the top of the file and then included by name or instantiated in the only screen they'll be in. Names will still have to be unique, but it may be helpful for organization.

[Taristin]

Call for a font file, too, so we can have alien text in the Vasudan cocpits!

[WMCoolmon]

Probably wouldn't do much right now, seeing as how taylor has reprioritized other stuff.

Best I could probably hope for would be letting you choose the font from one of the .vf files.

The tool:
http://www.geocities.com/cobolt_dink/Fonttool.zip
http://www.hard-light.net/forums/index.php/topic,26960.0.html
http://www.hard-light.net/forums/index.php/topic,28608.0.html
http://www.hard-light.net/forums/index.php/topic,13334.0.html
http://www.hard-light.net/forums/index.php/topic,14244.0.html

Of course it won't work at all under Linux w/ Cedega, so I can't try playing with it. But looking at the code, it should be relatively easy to have it load all font files found in the fonts/ directory, not just font01, font02, and font03. I'm not sure what taylor meant by you not being able to use different fonts, but different sizes, since it should be possible to have totally different fonts in different .vf files, from what I can tell.

[Lynx]

more moveable Hud components =yay!

And there should really be a way to create HUD elements without transparency. I really would like to play with a deep blue or red HUD, for example, but this is effectively prevented by the current HUD layout, since the background shining through makes most HUD gauges unreadable. If you don't know what I'm talking about check out the WCS screenshots release thread, some of Starmans screenshots feature a deep blue HUD, and it's so dark that you actually have to mark the screenshot to be able to recognize it.

Multicolored hud gauges This is actually my biggest gripe, with the monochrome system I cannot get it even remotely too look like I want it, and oh boy how I tried.. They probably won't be player configureable, but who cares since it looks so much better anyway. Is probably really hard to program, I'd imagine.

The sexp contoled hud parts are very interesting, allowing to create completely custom gauges(for example an altimeter for groundmissions).

BTW is it already possible to map HUD parts onto the cockpit mesh?

[taylor]

Originally posted by WMCoolmon
Of course it won't work at all under Linux w/ Cedega, so I can't try playing with it. But looking at the code, it should be relatively easy to have it load all font files found in the fonts/ directory, not just font01, font02, and font03. I'm not sure what taylor meant by you not being able to use different fonts, but different sizes, since it should be possible to have totally different fonts in different .vf files, from what I can tell.

Grab the freespace2 module from icculus.org cvs and "make fonttool".  You didn't actually think I would leave out something like that, did you?

As for the font thing, yes it is possible to have multiple fonts.  I've had code that supported, and could use, 15 different ones.  The problem is how the font code is used to adjust size by changing font rather than actually having different fonts.  In other words, it's too damn basic.  I didn't like how it had to be handled to work in a manner that would please everyone.  The new code will have a fonts.tbl which will specify font file names and "pretty" names to be referrenced as.  It will accept the current .vf format fonts as well as TTF.  And for using TTF it will have variable size, aliasing, hinting, and bold/italic support.

[Nuke]

im all for having the hud system rebuilt from scratch.  i like the idea of mouse interactive huds/panels too. also id like to be able to use the gauge scripts interchangeably between panel and hud. i suggest having 2 materials, one for the transparent hud, and another that renders opaque for the panel gauges. you could construct a panel by simply uv mapping polies to a hud tempate texture (if your using a custom layout you would take a screenshot of the hud to use as a template to aid in uv mapping out the panel polies). this texture would be replaced by the one generated by the render to texture function ingame.

or you could u yould render the hud gauges as overlayed decals sorta like

$material: hercpanel
$overlay gauges:
+gauge name: radar
+position coordinate: (20 38) ;x,y probibly in pixels or percent of texture
+scale: 3 ;probibly in percent of texture area

[WMCoolmon]

I was thinking of having something where you define the gauge, then define the individual attributes of the gauge. The attributes would be placed relative to the gauge in 3D space (unless specified everything would be at distance 1.0), and 2D coordinates for attributes would be from 0 to 1.

This would let you easily place a gauge anywhere, even 2 or 3 places with the same code (eg have the escort list floating in the normal pos, and on a cockpit display.)

It would have to make extensive use of the render-to-texture stuff though, and I'm not sure how fast that is.

On a side note, I've gotten a small test app that executes Python like I'd like it to. (Compiles then evaluates it) I still need more control over it to integrate it into the HUD system, but I should be able to use it for variables then. It'll probably replace Bobb's expression system, so if you have problems with that, air them now.

[Goober5000]

I don't like Python.

[Bobboau]

if it gets the job done I don't have a problem with it.

[Nuke]

i dont really like the idea to use too fancy a scripting language. freespace has always been easy to mod. this seems to hurt that reputation. its not something i couldnt hack, id assume it would be no more difficult than quake c was to learn. but im more concerned about the less programming capable modders. simple stuff like rearranging gauges or changing their graphics should be left to a table like format, and scripting only for really fancy stuff.

[Bobboau]

take a typical table and replace one variable with a script that defines the value rather than a constant.

[WMCoolmon]

Even if I converted the whole table to a python script...

Code: [Select]

import hud
#Create a screen
TerranScreen = hud.screen("Terran HUD")
#Create a gauge
BoxGauge = hud.gauge("Box gauge")

#Assign the gauge a screen
BoxGauge.setscreen(TerranScreen)
#Set the position (X pos, Y pos, width, height)
BoxGauge.SetScreenCoords(10,10,10,10)
#Assign the gauge a draw function
BoxGauge.drawfuction = BoxGaugeDrawFunc

#Define the draw function
def BoxGaugeDrawFunc(self):
#Set the current color as green
hud.setcolor(0,255,0)

#Draw a box using UV coords
hud.line(0,0,1,0)
hud.line(1,0,1,1)
hud.line(1,1,0,1)
hud.line(0,1,0,0)

#Just for fun, write this object's name, too
hud.text(0,0, self.getName())

#Now, when you play as a ship that uses the "Terran HUD" HUD, you will get a box at (10,10), 10 pixels wide and 10 pixels high with your current ship name in it.

..I doubt it would be that hard to grasp. And it'd be much easier programming-wise, I suspect.

[WMCoolmon]

Well, seeing as how 3.6.7 wasn't released when it was supposed to be (2-3 weeks ago), it looks like this isn't going to get completed for a long time.

If somebody wants to take up the torch, be my guest. I have the small testbed appI used for python integration and can put that up somewhere.

[CP5670]

Speaking of HUD gauges, one of you here, WMCoolmon I think, had made a hud_gauges.tbl a while ago to allow more than three ships in the escort list, which used to be helpful in even some of the official missions. This file is outdated though and does not work with any current build. Does anyone know where I can get a later version of this, if one exists?