Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: WMCoolmon on May 28, 2004, 10:19:26 pm
-
Three somewhat large changes:
- HUD.tbl no longer used; images are read directly from ships.tbl
- Music.tbl is now modular
- Added hud_gauges.tbl
hud_gauges.tbl format:
(Default values for 640x480 used)
#Main Gauges
$Resolution: (640 480)
$Player Shield: (396 379)
$Target Shield: (142 379)
$Shield Mini: (0 291)
+Size: (31 21)
+Percentage: (50 0)
+Image: targhit1
$Afterburner Energy: (171 265)
+Image: energy2
$Weapons Energy: (416 265)
+Image: energy2
#End
#Gauges
$Resolution: (640 480)
$Gauge: Shield Mini
$Text Base: (305 298)
$Text 2 Digit: (307 298) ;Where to place damage text when it's at 10 through 99
$Text 1 Digit: (311 298) ;...0 through 9
#End
Someone wiki this...
All coordinates are in the form of (x, y). Units are pixels unless explicitly mentioned in this text
#Main Gauges
This contains/will contain the various HUD elements listed in the HUD configuration screen.
$Resolution denotes a resolution. Enter in coordinate format the resolution x and y, ie (1024 768). If you want to specify a default template, use (0 0)
Next are the individual hud elements. All of these are optional, and the volition defaults will be used if one is not specified. The coordinates to the right of the name are the location that element will be placed. (Obviously these won't matter/be required for something that moves, like the lead indicator.)
Under each element are 3 optional fields:
+Size: Size of the element in coordinate-format. This may be used within the code, so if you specify a custom image, USE this.
+Percentage: Percentage of the screen to place the HUD element. If size is not specified, the the upper-left corner will be placed at the specified location. Otherwise, the center of the object will be placed at the location. Floating point numbers are acceptable.
+Image: If an image or ani is used, this image will be substituted for the volition default. If you experience problems with a HUD element you have specified the image for, set the size parameter with the size of this image.
Gauges
These are sub-elements of the different main gauges. Specify a resolution, like in main gauges, then use $Gauge: Gauge Name to specify the Gauge.
At this point you can set the sub-element coordinates/images in the same way as a Main Gauge.
Teh Build (http://fs2source.warpcore.org/exes/latest/fs2_open_C5282004.zip)
-
Ooh! This'd be awesome for TVWP... :drevil:
Edit: Fix the guage resolution... (7480)
-
Fix0red...not like it really matters. ;) You won't see any change if you use that table :p
What specific gauges are you interested in seeing moved? I can prioritize those. (I'd like a smaller list than "all of them", if possible. :p)
-
Link is broken.
-
Oh and BTW is it possible to adjust EVERYTHING in the hud with the gauge table?
-
Fixed link. Also, I don't think you need to add the file extension for Images.
Re: everything in the table, Not yet.
Edit: Oh yeah, if you run this build w/o a hud_gauges.tbl it won't work. This will be fixed in the next build.
-
The radar, the weapon dropdown boxes, etc. etc.
and make it on a per-ship basis, PLEASE :D
you could set up sooo cool cockpits with this if you could individually set it for all ships.
-
IIRC, in some discussions it was determined that these should use a floating-point number for the start position, that would be scaled according to the resolution, so something in the middle of the screen would be at 0.5, 0.5, and you'd multiply by the xsize/ysize to get the value of the actual position.
Just my $0.02 USD
-
Well, that was the intent behind the percentage value - same idea, just multiplied by 100. It makes more sense IMHO.
I can set the positioning any way people like, but it should be decided *soon*, before people start making tables.
-
New build - this one adds per-ship HUDs.
Sample file:
#Main Gauges
$Resolution: (640 480)
$Player Shield: (396 379)
$Target Shield: (142 379)
$Shield Mini: (0 291)
+Size: (31 21)
+Percentage: (50 0)
+Image: targhit1
$Afterburner Energy: (171 265)
+Image: energy2
$Weapons Energy: (416 265)
+Image: energy2
#End
#Gauges
$Resolution: (640 480)
$Gauge: Shield Mini
$Text Base: (305 298)
$Text 2 Digit: (307 298) ;Where to place damage text when it's at 10 through 99
$Text 1 Digit: (311 298) ;...0 through 9
#End
#Ship Main Gauges
$Resolution: (640 480)
$Ship: GTF Ulysses
$Player Shield: (396 379)
$Target Shield: (142 379)
$Shield Mini: (0 291)
+Size: (31 21)
+Percentage: (50 0)
+Image: targhit1
$Afterburner Energy: (171 265)
+Image: energy2
$Weapons Energy: (416 265)
+Image: energy2
#End
#Ship Gauges
$Resolution: (640 480)
$Ship: GTF Ulysses
$Gauge: Shield Mini
$Text Base: (305 298)
$Text 2 Digit: (307 298) ;Where to place damage text when it's at 10 through 99
$Text 1 Digit: (311 298) ;...0 through 9
#End
I haven't bugtested this build very thoroughly at all, I just got it working with the training mission. :p It fixes a small bug or two, I think.
Anyway...I'm done coding for tonight. Lightspeed, eat your heart out. :p
-
You are getting better day by day!! Now, it doesn't quit right in the middle of a mission(by accidentally targeting a debris, or because it simply has mood to,), it doesn't start up at all. :yes:
-
Is all of this in CVS?
-
Originally posted by WMCoolmon
I can set the positioning any way people like, but it should be decided *soon*, before people start making tables.
Here's my idea: Add full support for all the gauges by specifying exact coordinates, but *only* for 640x480. The game will automatically adjust the coordinates for the other resolutions.
This way people can have the exactitute of specifying absolute pixel coordinates, but the gauges will still be scaled for alternate resolutions. I think doing it by percentages would eventually get far too confusing.
As a bonus, all the values would be integers, so you wouldn't get floating-point slowdown.
-
Goober, I thought about that, but then you have the problem of what happens if you place two gauges beside each other. When the resolution got to 1280, you'd have a pixel or two between the two elements.
kasperl, the stuff in this build is not in CVS. I had to make changes to more stuff than just hudparse.cpp and used pointers extensively and didn't do much testing/checking.
TopAce, I did a little checking and found the bug: I didn't post the new build link. ;)
http://fs2source.warpcore.org/exes/latest/fs2_open_Cex.zip
You won't see any change if you run it w/o hud_gauges.
-
Make it so you can set the radar display and all beautifull stuff ;7
-
I hope it will support the Orb™.
Awsome work!
-
I think everything should be in percentages, we can write a tool for editiing the table later and it would be easier and more acurate if everything is in percentagas
with regards to the ship specific thing, I think there should be a defalt HUD and then a list of specalised HUDs, then linking specalised huds to there ships via ether index or a name given to the HUD entry, you'd have an array of HUDs just like we do for ships and stuff, wich HUD is assosiated with wich ship would be an index in the ship_info structure, defalt position 0.
if we get this working I'll try makeing a HUD.tbl editor (if no one else does)
-
Awesome! Per-ship hds... and a tool to set it up?! *droolz on keyboard*
*BAAZZZZZAAAAPPP!!!*
Ouch...
-
Originally posted by Lightspeed
Make it so you can set the radar display and all beautifull stuff ;7
How about something simpler...like the auto-target gauge? :p
BTW, for CVS users, the code I updated to CVS doesn't work right...I'll clear it up ASAP.
-
OK - first off, this is awesome news! Something I know I (and others by the looks of things) have wanted for a very long time - Per ship modifiable HUDs... awesome!
But, a few Questions
1. Can we use different Sized Anis?
2. Can we add new guages? (I realize the answer to this is probably a very definite no at this point, as they would need to have something to display, but perhaps for future revisions a simple counter setup, or the display of a mission defined variable or FRED numerical returner (eg. Time, position x, distance etc.), or even just flashing/static images controlled by sexp could be used? If there's no controlling sexp, the image is simply displayed as a static HUD element like the crosshairs).
3. Would it be possible to eventually set it up for total modularity, ie. all guages moveable? I understand limiting it for testing purposes, or because it's a lot of work, but I reckon total changability is an admirable goal.
-
WM: Is the mod tbl thing in CVS?
Also, the idea of SEXP controlled HUD items sounds very cool. Together with a is_realkey_pressed SEXP that actually gives the exact key, and not the remapped one, plus a SEXP to disable all controlls except for the key presses going to SEXPs, you would have a system to make a complete in-game UI for the most insane purposes.
-
I was actually thinking more along the lines of Altimeters and new flashers (Ala Collision, Engine Wash etc.), but now that you mention it... :D
-
If you could assign a variable to a gauge using sexps it would be great, but you'd probably have to define the gauge 'type' (Bar, Numeric, Circular?) in the table itself, or stick only to numeric gauges or something.
The Radar, I would have thought, would be a complete ***** to do anything with other than move unfortunately, though I hope I am wrong :)
Either way, awesome work! :D
-
Originally posted by WMCoolmon
Goober, I thought about that, but then you have the problem of what happens if you place two gauges beside each other. When the resolution got to 1280, you'd have a pixel or two between the two elements.
And you have the same problem if you use percentages. :)
How about allowing people to specify specific points for whatever resolutions they're interested in, and the gauges would be re-scaled for the undefined resolutions?
-
Quoted from TBL by WMCoolmon
$Resolution: (640 480)
What if you just used this tag to see if it was pixel, percentage or somethign else? Each ship def can have a number of these thingy's in them, so you can define for every res you want, but you can also define for $Resolution: (1 1) for a 0,1 system, or $Resolution (4 3) or $Resolution(100 100) or Resolution (1024 768).
When the game is running in a resolution not mentioned, it simply takes the first res it finds and reshapes it.
-
Well, my idea is to make HUDs for all individual ships (i.e. The Ursa looks different than an interceptor) so it'd be pretty cool if it would be as modular as possible. :)
Can you include a 'label' field that specifies the text being displayed with it? - You know, like "Hull Integrity" and stuff like that. Could be useful if you could modify that (for example for Vasudan HUDs) :nod:
-
I want Vasudan HUDs on all of my fighters. :p
-
Originally posted by Lightspeed
Well, my idea is to make HUDs for all individual ships (i.e. The Ursa looks different than an interceptor) so it'd be pretty cool if it would be as modular as possible. :)
Can you include a 'label' field that specifies the text being displayed with it? - You know, like "Hull Integrity" and stuff like that. Could be useful if you could modify that (for example for Vasudan HUDs) :nod:
He? Just make another image with a different text, AFAIK.
-
Uhm, WM, can you put this code in CVS, or post the files you changed? I'd like to take a look at how this all works.
Also, are Bob's decal changes and stuff, plus the cloaking changes in CVS? If not, you two might have an intresting merge to do...
-
yeah I bet it's gona be "fun" mergeing my code base back in with CVS given the major changes that I have made with a number of low level functions
-
Originally posted by kasperl
He? Just make another image with a different text, AFAIK.
uh, NO?
The text is written there by the game. You just have a box. The GAME will write "Hull Integrity" over it.
What I want, basically, is that you could change that string to anything you like. For example to "Damage" OR (my original intention) you can change it to "", so the game will not display ANY text there, and you can instead include the 'text' in your image with vasudan font symbols ;)
-
oh yes, now I remember.
-
kasperl: Yes, it is. :) If you want to add some hud gauges, just put them in the array in hud_gauges.cpp and increment MAX_COORD_TYPES. If you change anything else make sure you understand what's happening, it can be pretty confusing.
Lightspeed: I haven't implemented any HUDs you'd want to do that for, but I'll look into adjusting it. That might require some updates...
-
Very good.
In the future things like setting whether its a display or a gauge (i.e. number or thingy like the thruster energy) might be implemented - but I guess that takes quite some reworks.
-
Originally posted by WMCoolmon
kasperl: Yes, it is. :) If you want to add some hud gauges, just put them in the array in hud_gauges.cpp and increment MAX_COORD_TYPES. If you change anything else make sure you understand what's happening, it can be pretty confusing.
So the only way to implement new stuff is by code? :( Is this going to remain, or will it become more mod friendly (ie. sexp control) in the future? I guarantee it'll get used - I can send you 8 separate new HUD elements than me and Vasudan Admiral thought up over a matter of about twenty minutes if you need to be convinced of that. Admittedly, some are highly specifc to some TI situations, but others are far more generally applicable, and if we have specific situations where new HUD elements would be useful, I'm sure other campaigns will too.
-
Currently no. I've tossed in some code to handle custom HUD gauges, not usable yet. But I'm keeping it in mind while working on this.
-
Originally posted by WMCoolmon
kasperl: Yes, it is. :) If you want to add some hud gauges, just put them in the array in hud_gauges.cpp and increment MAX_COORD_TYPES. If you change anything else make sure you understand what's happening, it can be pretty confusing.
Lightspeed: I haven't implemented any HUDs you'd want to do that for, but I'll look into adjusting it. That might require some updates...
Odd, I only have hudgauges.h , and not hudgauges.cpp. I did a checkout on CVS 2 minutes ago.
-
I just updated stuff, so try again.
Custom HUD gauges:
;this should actually work.
#Custom Gauges
$Name: Steak_gauge
$Name: Yo_mama
$Name: Holy_hannah
#End
#Main Gauges
$Default: (640 480)
$Steak_gauge: (256 256)
+Text: Lumberjack
$Yo_mama: (128 128)
+Text: Yo mama
$Holy_hannah: (64 64)
+Image: attacker
#End
At the top of hud_gauges.tbl, all that's needed to add three custom gauges. Once you've added a custom gauge, it's appended to the main gauges (or mini-gauges, if a parent is specified) list.
$Name:
Name of the Custom HUD, also used as the name for variables
$Default640X:
Default X coordinates in 640x480
$Default640Y:
Y coordinates
$Default1024X:
1024x480 X coordinates; used if a nonstandard resolution is specified
$Default1024Y:
ditto, except Y coordinates
$Parent:
Name of the HUD gauge's parent. If this is specified, it is a mini-gauge
$Addparent:
If $Parent is specified, this specifies the HUD gauge to add coordinates on to. This is useful if you need something to be placed right next to another gauge.
Say you wanted a gauge to be exactly 6 pixels to the right of another gauge's coordinates; you would set addparent to that gauge's name, and set the Default X values to 6.
Once added Custom gauges function exactly like normal gauges, except they are static; nothing changes about them. For use on future gauges - all images for an individual gauge should be in an ANI, like Volition's are. Switching image files mid-game is a bad idea.
For now, static images are supported, animations (and ANIs) are not.
My thoughts on SEXPs are that a set-hud-frame and set-hud-text and set-hud-coords could be implemented.
Set-hud-text would take the HUD variable name and the string for the gauge to display.
Set-hud-frame would take the HUD variable name and the frame nubmer in the ANI.
Set-hud-coords would take the var name, and the X coord, and the Y coord.
As of now, there is a limit total of 32 custom gauges.
linkie (http://fs2source.warpcore.org/exes/latest/fs2_open_ex.zip)
Edit: Not sure if I mentioned this, but this is the specification form for ships:
$Ship: GTF Myrmidon
$Resolution: (640 480)
$Gauge: Shield Mini
$Text Base: (310 298)
$Default: (640 480)
$Gauge: Shield Mini
$Text Base: (310 298)
$Ship: ...
Edit 2: BTW, with a set-hud-coords and some creative SEXPing you could build a radar :p.
-
Originally posted by WMCoolmon
Set-hud-text would take the HUD variable name and the string for the gauge to display.
Assuming you'll be able to implement non static stuff in here (ie. a sexp controlled returner like distance, time or get-position-y), then you've just made my day. :D
-
Does the last build there have decals & envmapping?
If not, get together with Bob so we can have all this in one build :)
-
WMCoolmon: I just checked out the fs2_open module to a completely fresh dir, and still, only hugauges.h exists.
-
Ehmm, I checked and it turns out hudgauges.h doesn't seem to have a CPP file. So it shouldn't be a problem...
Incidentally, I haven't touched hudgauges; all the parsing stuff is in hudparse.*, the custom HUD display code is in HUD.cpp (search for custom hud), and I've modified the gauges in hudtarget.cpp and hudshield.cpp. I also had to make a line or two of modifications to freespace2.cpp and one of the cpp files in the mission dir (wherever function commit_pressed is).
BW: That depends how the SEXP stuff works.
Oh, LS: Bob's stuff will be put in CVS after 3.6 is released, when Fractux finishes the...hmm...additional items.
-
Originally posted by WMCoolmon
...
TopAce, I did a little checking and found the bug: I didn't post the new build link. ;)
http://fs2source.warpcore.org/exes/latest/fs2_open_Cex.zip
...
It brings up a 404 error page.
-
Try "linkie" in the last post, I remove old builds to conserve space.
-
Still nothing
-
I'm having no trouble. Try this:
http://fs2source.warpcore.org/exes/latest/fs2_open_ex.zip
Or you can try browsing the directory http://fs2source.warpcore.org/exes/latest
-
The first link seems to be working.
-
Check out the new build:
- Custom gauges can now be ANIs. First frames are shown by default.
- Four SEXPs added: hud-set-text, hud-set-text-num, hud-set-frame, and hud-set-coords. These will work for custom gauges as well as the retail ones I've included in the table.
- Static image (ie PCX) support for custom gauges remains. You can try calling hud-set-frames for it, this may be a way to switch images, but I wouldn't advise using it in a release situation.
I didn't implement attaching a variable to a gauge, however, all the hud-set functions are small enough you should be able to put them in an every-time/true loop without much slowdown.
A side note on making gauges - the display order goes from first to last, so if you want to make a background for a gauge, have it display before the contents and not after.
Custom gauges cannot be flashed (yet).
The zip contains the newest EXE, a FRED build (with the new SEXPs), a test mission, and a hud_gauges.tbl to work with the test mission.
Now let's see some implementation. :p
ZIP link: http://fs2source.warpcore.org/exes/latest/C06012004.zip
-
If they could be linked to game parameters by default that'd be a better solution, since you could use them with existing missions and wouldnt have to SEXP it in every mission.
-
Can you put in Guage-Set-On and Guage-Set-Off as well?
And I'll see about knocking up a guage - if nobody has an alternate request I'll do something simple - Cargo Remaining, for dropping nav buoys, mines etc.
-
Do it, we need to test this stuff. Unfortunately I cannot help there till Bob's stuff is in there too, since i'm working on alpha env maps which would not work with any of these builds. (and switching builds that dont like each other's data all the time is quite annoying).
-
OK. I'll provide it, but someone else will have to test it as I'm still limited to floppy sized Downloads. :(
-
Originally posted by Lightspeed
If they could be linked to game parameters by default that'd be a better solution, since you could use them with existing missions and wouldnt have to SEXP it in every mission.
If you mean SEXP variables, I don't know the SEXP code well enough to do that. If you mean internal game variables (ie number of loaded ships), each one would have to be hardcoded as an option. I'm not saying it's impossible, but it'd take some doing.
-
The next build will remove the addparent variable and coordinates will be computed as floating point numbers. This means you'll be able to do this:
$Default: (1,1)
$Your Gauge: (.5, .5)
-
seeing as you have got the most eperience in playing with new gauges, there was an Idea floated around for a while internaly to speed up the rendering of the HUD, the idea was to break the HUD down into sections, and then render the sections to a texture the HUD would only be actualy rendered if some part of it was changed, and there would be a HUD texture that had all of the fairly static graphics in it, do you think if we gave to some sort of render_to_texture functions that you would be able to get some work done on this? it was mostly abandoned becose nobody knew anything about the HUD.
and addition of a teritary and tactical weapons system is something that has been wanted for a long time, though I think the teritery weapons system became the tactical system (as my origonal idea was for teritery weapons to be countermeasures and mines, tacktical system to be cloaking devices sensor pods and targeting lasers)
-
Yeah, if it means making a texture for the whole screen and then only modifying changed gauges.
If I do anything like that though, it would involve basically revamping the whole HUD system - not a fun task. How much performance increase would this give?
Edit: A quick idea for implementation - the hud rendering system is tied into the keypress system, so whenever a keypress event happens (let's say "fire afterburner") the HUD gauges are checked if the flag matches one of theirs. If it doesn't, the gauge isn't rendered.
Also tie it into the SEXP system, and main gauges flagged as being dependant on SEXP events would be updated when the SEXPs were updated.
Whenever a gauge is updated, all the mini-gauges are re-displayed onto the old HUD. The problem here comes in with text and different-sized images, and I'm not sure if there's a way to get around this... :doubt:
You could make a gauge buffer for each one and then render that every frame unless the gauge is changed, i 'spose.
-
it'd proly be beter to wiat or yu t ge done with he table firs though, after that lts dicuss his further
-
Can this system of custom gauges allow for an escort list display that can show more than 3 ships?
-
Yes - you could modify the escort art, add a few gauges for ship names and HP and the background, then use SEXPs to set it up.
-
Originally posted by Bobboau
seeing as you have got the most eperience in playing with new gauges, there was an Idea floated around for a while internaly to speed up the rendering of the HUD, the idea was to break the HUD down into sections, and then render the sections to a texture the HUD would only be actualy rendered if some part of it was changed, and there would be a HUD texture that had all of the fairly static graphics in it
Ugh, no. This, I think, would be going too far. Sometimes too much optimization is a bad thing.
Focus on the other stuff. Don't invent a new feature when so many other things need doing. :)
-
the HUD actualy is probly one of the slowest things currently