[Galemp]

I was fooling around, playing ye olde FS1, and I couldn't help feeling nostalgic about the little clicks and whirrs I heard when adjusting power and targeting. I was wondering, would it be possible to assign a different set of HUD elements and interface sound effects on a per-species basis?

This would be really neat when you're flying a Vasudan ship, and it feels Vasudan, because the gagues are more smoothed and the audio feedback is a little more musical. A Shivan HUD would be even stranger, with shrieks and whines and a blood-red HUD. Another use is to use the species definitions to split up the FS1 and FS2-era fighters (as two species, TerranGTA and TerranGTVA for example) so when you fly an Ursa it looks and sounds more antiquated from the inside (forcing the HUD to be all one color, using FS1 sound effects and lead indicators) than a newer Boanerges.

I know you're in the process of revamping the HUD system, but for now a simple ANI replacement/substitution system would work. I think this would add a lot to the original campaign, the FS Port, and other mods where you fly a variety of ships.

[WMCoolmon]

Well, in-progress is a misnomer. Right now, a lot of the base foundation is complete - there's still some bugs, and some things that would be useful to have aren't in. (Getting at global scripting variables in the code and getting at scripting return values in a non-hackish manner come to mind) Past the initial figuring-out phase, I haven't really felt motivated at all to get it done. I haven't finalized how, exactly, I'd like to deal with the interface, but that's probably not going to take very much time if I'm interested in doing it.

Part of the problem with the HUD is that it's so hard-coded, anything that I do within the current system will have nowhere near the potential as if I just completely skip it and use a user-defined HUD. Compared to the other parts of the code, the HUD is really simple because it just has to show in-game variables in a pretty form. Excepting the radar, of course.

As of now, hud_gauges.tbl does support per-ship HUD settings but it supports very few gauges - the middle shield icon, the two hull/shield status indicators on the bottom, the escort list, and the afterburner/weapons gauges.

So, blah blah blah. If the scripting-HUD stuff were implemented you could do something like this, regardless of the actual table form:

Code: [Select]

if ship.getSpecies() == "Shivan" then
     --Put Shivan HUD stuff here
else
     --Put GTVA HUD stuff here
End
My preliminary thinking on the actual table format was to arrange everything using the Lab GUI stuff, with a new "HUD" object. The code would then use the built-in "Screen" support to arrange collections of each HUD gauge object. Then on a ship, you would choose which Screen that ship would use. The only problem with that method is that the GUI is set up to mostly let a user modify stuff, rather than create it, and support for that would have to be added in interface.tbl if I were going to use the built-in style customization system. But, I don't think it'd be a good idea to link it into interface.tbl.

And actually, I think the best course for the new HUD system would be to essentially make it bypass the default FS2 GUI and be based completely on scripting. That would make the GUI useful, esp. considering that it's outdated with taylor's GUI editor and separate system so there's not any point to continuing development on the system in the direction planned.

Anyway, say some kind of hackish solution...hmm...what you could do - this would be extremely hackish - would be to have an extra table and trigger in the code. When the HUD bitmaps loading phase starts, the code would check the ship species and then go to whatever section in the new table corresponded to that species. In that section of code, you'd have the name of the original file, then the name of the replacement file. These names would be replaced on every use by the proper species one by the core file system.

Other downsides: Extremely minor slowdown in all loading times (Being pessimistic, I'd say a second per mission load. A conditional doesn't take very long to check.). If you viewed from other ships, the HUD would be the same as the player ship's species. Probably more.

[Galemp]

I didn't think the HUD showed up when viewing from other ships?

Anyway, what I understood there sounds good. I guess the major HUD changes will have to wait until the rest of the HUD code gets re-written.

What about the sound effects? Are the pilot interface effects hard-coded or are they drawn from the SFX table? If that's the case, we can just specify alternate effects to play for each numbered entry for each species.

[WMCoolmon]

Yeah, they're hardcoded...not sure if you could use the same method for them.

[Nuke]

i want to at some point have a pirate hud and their own sensors. first off i want to replace lead indicator, target box, and reticle with an nld skool korean war/vietnam era style radar gunsight. essentialy a circle that moves around so that if you put the enemy fighter in that circle its a gauranteed hit. rather than line up 2 gauges you have to line up one reticle (which moves)  and the fighter. it wouldnt track the target but rather any fighter thats in its scan cone. also to obtain missile lock, you have to keep your target in the cone for whatever the missile's lock time is. you wouldnt actually have any targeting controls, as your target is whats in your ships scanning cone. if you wanted to target a capships subsystem you would have to know where it is. its a simple hud that requires more skill to use. the thing is i want to be able to do it all with scripting. some of it i could probibly do now, like the lead indicator, oher stuff il have to wait for abit.

[WMCoolmon]

http://www.hard-light.net/forums/index.php/topic,37769.0.html

Note that variables are automatically persistent between frames.