[Vasudan Admiral]

Well in an incredibly clever act, I seem to have lost the original coloured versions. No matter - I doubt they (or these new ones for that matter) would ever have been final anyway.

So, I've put together the components of the AB and weapon energy guages, and thrown in the speed guage, though I have no idea if that one will be any use.
The speed guage seems kinda built into the left reticle side bar thingie and I have no idea how the game actually uses the more complex HUD component ANIs. :\

[attachment deleted by ninja]

[jr2]

Hmm, does he already know the CVS checkout procedure?

[Backslash]

Samuel, WMCoolmon -- you guys make very good points about the old system vs new systems.  I agree, a complete redesign is necessary... and I would love to see it... but I don't think I have the coding experience for that.  I can probably help with it once a framework is in place -- I'll take another look at the NEW_HUD stuff, too -- but this is why I've been working on the old system: it's there, it works, and I know how to do it (so far).

Granted, if my project were to take half a year or more and the new system were also completed in that time, my time would be sort of a waste -- but even if I were to quit now and only commit what I have so far, it's more than what we have right now.  I'd commit right now if there weren't a couple bugs I'm trying to track down.

Thanks, Vasudan Admiral.  You inspire me to work on the throttle next

Now I'm going to go digest WMCoolmon's paragraphs some more

[Samuel]

I managed to get my development environment working with the source code and decided to dive right into coding a new HUD management system.

The way I will be approaching this is to code the new HUD in an Object Orientated way, reimplementing the existing HUD features through a new interface and making good use of inheritance so that new gauges can be implemented seamlessly.

The HUD layout will be read from file, for easier configuration and modding. The structure of the input file, more importantly what parameters can be defined, should be determined in part by the community.  I assume that SEXP suppot will be required, to allow the modification of HUD behavior through things like FRED.

Hence my question, what kind of things would you like to be able to control? Obviously the position of the gauge on the screen, but other parameters as well.

I don't plan to allow you to script an entirely new gauge; I feel that if you want to come up with a new gauge you are better of inheriting an object, extending it in c++ and exposing its parameters in an input file.

The work Backslash has done will not be wasted, because by seeing how he has generalised the existing HUD components it will make my life of reimplementing it in a new interface easier.

~Samuel

[Cobra]

Uh, this won't screw up the way it already looks, will it?

[jr2]

No.  Or you'd have kara jumping up and down about Retail compatibility.  XD

[Samuel]

Take a look at these HUD from a game called X2: The Threat, released recently.

I'd like the new HUD system to not only be backwards compatible, but to be able to implement something like this:





~Samuel

[Flaser]

Keep in mind though, that the LUA scripting has already taken great strides to wholesale community approval.
I don't say you should tie the whole thing *into* the scripting system, but creating the interface would definitely have merit.

[Samuel]

Hi,

A month has passed, so I wanted to post a quick update on the progress of the new HUD system.
I have found the learning curve pretty damn steep... primarily because things are so very hard coded and functions are strewn ALL over the place. If it weren't for Visual Studios 'Go To Definition' from the drop down menu I think I'd be tearing more hair out than I already have .

I started by reimplementing HUDWingmanStatus in an object orientated way. Just this cpp file alone touches so much other code its frightening! Reimplementation is a very slow process because by carefully looking at each line of code one quickly realizes what other Objects need to be created, so a lot of time is spent trying to figure out how all the pieces will work together. And the more one reads the code, the more puzzle pieces there are.

I'm pretty much done with HUDWingmanStatus and am now in the middle of HUDBrackets. I'm hoping that things will go a bit quicker from now on as I become more familiar with the source code.

Unfortunately, since everything is so intertwined I will not be able to really test everything until the whole new object orientated HUD monster is complete. I am dreading the subsequent debugging.


~Samuel

 

[jr2]

 

Keep it up, man! 

[Nuke]

you could play around with this

consider it an early alpha of the cockpit demo patch for nukemod i was working on. i mainly put it up for the coders to tinker with but i see no harm in letting other people play around with it. its stand alone so just install it like any other mod. dont consider it a mod though, more of a demo for the rtt system. you need this build for it to work. the usual rules about backing up your pilot files still strongly apply.

[Swifty]

Okay, FS2 now has TrackIR support and I've developed a simple method to allow the reticle to slew along with the forward vector of the ship: video. I haven't seen anybody address these latest developments yet in this thread. I want some input from the modders and especially from Samuel (Hey, that's my name). Other than WMC's render to texture and separate cockpit POFs, what else do we need to do so that FS2 can have better 3D 'pit support?

I'll be soon be adding some flags to hud_gauges.tbl so that modders can indicate which gauges they want to be slewable, in other words, gauges that should follow the nose of the ship and not the player's viewpoint. Samuel, will my work ultimately be deprecated by your promised changes?

[Vasudan Admiral]

That's pretty awesome right there. Does it work as freelook for peeps without trackIR?

The main component of the problem is still how to get the HUD elements onto the right locations on the model and keep them there - originally this would have been only possible via RTT, but from the looks of that vid it would also be quite possible to have them slew around. This should certainly be more efficient then the RTT method, but I think it will still require the improved ability to customise HUD element starting locations in the HUD guages tbl that Samuel is working on.

[Swifty]

Yeah, you can use your joystick hat or any other definable key for looking in orthogonal directions. I also programmed in target padlock view which is a decent substitute to TrackIR.

I think 2D slewable HUD elements shouldn't be a compromise we should be satisfied with. However, it should be an option for modders if they want 3D 'pits but choose not to have readouts and the reticle rendered into the cockpit. From your concept art, Vasudan Admiral, it looks like you want all of that.

I'm itching to tackle more of the HUD but I'm not sure how long it'll take for Samuel to finally finish and publish his reengineered HUD system nor do I know what it'll look like in the end. In the meantime, I guess I'll work on extending hud_gauges.tbl for now, with flags indicating if the modder wants a certain HUD element slewable or if they want it to appear or not.

[Backslash]

Salute, Samuel, thanks for the update.  (Thanks Swifty for the bump 'cause I missed it.)
Funny enough, I was just working on HUDWingmanStatus as well!  I feel your pain.  If you have any questions, I'll be glad to help, but yeah a lot of it is just 'hunting'.  Thank heaven for Go To Definition and Call Browser!

Cool beans Nuke, I'll be sure to check that out.

Yeah Swifty's stuff is great.  Unfortunately so far it's only in HEAD (as of now) because it needs those new view direction controls which messes up pilot files... I was planning to strip those out so everything else can be committed to stable branch, but I've been a little sick this week.  Stand by.

Swifty, gimme a day or so and I'll try to diff my code so far so you can see what I'm doing and then pitch in.  I've just been converting gauges to be settable with hud_gauges.tbl so far... Ideally I'd like to eventually connect it to the hud options screen, so that the table can specify on/off/popup and also select color.

[WMCoolmon]

Those are player options, IIRC, so the table ought to only specify the defaults by default.

[Nuke]

is there any chance il be able to get local view orientation and position (based off trackir/slew/padlock view angles) into the scripting system? since im doing of stuff with script generated cameras, i see potential for overriding the view data from the trackir/slew/padlock modes in certain situations where they may be useful (such as the rear facing tail gunner position). if i had a local view matrix and position i could multiply and add those in to the orientation and position data ive already set up.

[Backslash]

Those are player options, IIRC, so the table ought to only specify the defaults by default.

Agreed, though some mods want to be able to disable particular gauges, so I'm thinking a couple additional options along those lines.

I've also extended functionality a tiny bit for certain gauges... for example, the Wingmen Status gauge can now display vertically, and the throttle speed number can be set to be stationary, or move vertical (non-curved).

I love the idea Nuke.  I don't know how to implement that for scripting but hopefully it is not hard.  Swifty hopes to eventually extend it to have new separate mouselook axes, which would be great to combine with your idea for a shoot where the mouse aims, fly where the joystick aims combo.

[Samuel]

Hi all,

Real life commitments meant that I took a 2 week break from this, hence I only read all these posts now. (I needed the break anyway since my head was going to explode from all this c code)

Just took a look at the video Swifty posted. Very cool... I think it already increases the immersion factor. In your opinion swifty, was it difficult to intergrate this extra functionality into the code?

 My biggest motivation for writing a new HUD system is to try to decrease the conceptual complexity of the current system, to make it easier to extend and maintain the HUD. I'm trying to wrap functionality into objects which can be derived from, extended etc.  At the moment my aim is to literally re-implement everything in an object orientated way. So often I literally cut  existing functions and paste them into appropriate methods of an object such as CHUDWingmanStatus. Obviously I have to change the code somewhat, to make it call appropriate methods from other objects etc. The focus is on creating the correct interface.

I will consider my project a success, if I can run an existing version of freespace 2 with this new interface. It doesn't have to be the latest version in the HEAD branch and it doesn't have to support all the features that you all may have developed while I was working on this.

Once the interface is done and it runs on the version of freespace 2 SCP that I downloaded some months ago, I will then take whatever is in the latest version in HEAD and rewrite it to make it fit into what I have done, after which I will release some documentation for this new interface.

This means that your work won't be deprecated or have gone to waste, since I will simply try to port your ideas and your code to work through this new interface.

I expect it will take a few months to have this new interface working properly. I can't give a good estimate at this moment. As I go along and give progress reports I will know more and more how long till the goal is reached.

what else do we need to do so that FS2 can have better 3D 'pit support (Swifty)

In my opinion the single biggest thing that is hindering FS2 from having awesome HUD effects is the interface, i.e. the way it is currently hard-coded to hell!

~Samuel

[Swifty]

Just took a look at the video Swifty posted. Very cool... I think it already increases the immersion factor. In your opinion swifty, was it difficult to intergrate this extra functionality into the code?

I was pretty lucky. Freespace2 already had a command called "Free Look View" which allowed slewing with the flight controls when held down. So basic functionality was there. I just needed to make the game keep drawing the HUD when slewing, rotate and project the ship vector to get the data for HUD slewing behavior, and somehow tie the slewing angles to a TrackIR device.