Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Vasudan Admiral on August 07, 2007, 10:45:16 am
-
Here's what I've been working away on for the past weeks: (all pics are lvlshotted)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/InternalCockpit1.jpg)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/InternalCockpit2.jpg)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/InternalCockpit3.jpg)
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/InternalCockpit4.jpg)
It's yet to be shine and glowmapped, but that'll come - it uses a 1024 res map.
In-game it currently looks like this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/BlankTemplate.jpg)
And we need to get it to display most if not all of this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/FullHUDFeatures.jpg)
So what I currently have in mind is something like this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/Template1.jpg)
So for the artists round here, does anyone fancy having a go at drawing up a better interface layout using the templates above? :)
=====
On the development side of things:
A request was made a long time ago by SCP coders for modelers to build a cockpit model that could be used to properly create an internal cockpit view with. The idea of this one was initially to have it built into HTL models and displayed using "show ship" and an inverted detail box, but I realise that's not going to work very well in this case. The huge amount of work it would be to put it into each model and make sure everything is the right size and all would be insane.
So what I'm now thinking is that there be a "show internal cockpit model" setting in the in-game options. What this would do is render this POF with the POF eyepoint lined up with the players one unless the players ship had "show ship" turned on (in which case it wouldn't do anything). It would probably also need to force the FOV to a specific setting (I used default for my template) so that nothing gets misaligned.
Assuming that can be done, the only question remaining is of how to actually put the HUD down there like that. I kinda doubt scripting would be able to replicate all the HUDs current functions - especially things like radar, so it'd more likely have to be a different HUD layout correct? Or possibly an amalgamation of a new HUD and scripted stuff.
Anyone have any ideas or pointers here? I don't really have a clue where to start. :(
In any case, this separate HUD display would also need to be toggled by that "show internal cockpit model" option.
-
WICKED! :yes:
-
Great job!
-
The problem with your layout is that it's extremely busy. Wing Commander got away with that kind of thing because it had fewer gauges to display. I see no reason why the HUD can't be projected onto the visor of the pilot's helmet, which would give more options as to where to put things.
-
Awesome :yes:
-
Dude! I didn;t know you were this far along.
Layout looks good - personally, I think if people wanted a less-busy data display, they'd turn cockpits off. I do see one or two potential problems though - Cargo and orders will spill outside the available space if they're too long, and the directives and escort lists will be curtailed to being too short. It might be an idea to shift those lists outside of the physial cockpit area and use the freed up space for stuff that the FREDder can enter and potentially make too long. Also, did you do those pictures with a standard HUD screenie, or with the hud layout screenie layout you used above? Keep in mind that anyone using the SCP is probably _not_ running 640, and that does make a difference to the relative sizes of some of the HUD elements. It looks like a standard 1024 screengrab, but if it isn;t you might be able to gain some space in places.
-
That is hot! The layout looks fine to me!
-
i always thought the reticle/directives were displayed on the pilots goggles/visor, like the pilots of the US navy's super-hornet jet fighter.
-
Looks good but needs to be a bit brighter.Also needs some more work. :nod:
-
I stole your ammo/fuel gauges, hope you don't mind. ;7
(http://img.photobucket.com/albums/v74/GenoStar/hudmine.png)
-
more space is needed for the weapons, for ships with more than 2 of each bank.
of course, ship-specific hud layouts and custom copckpits could fix this...
-
The problem with your layout is that it's extremely busy. Wing Commander got away with that kind of thing because it had fewer gauges to display. I see no reason why the HUD can't be projected onto the visor of the pilot's helmet, which would give more options as to where to put things.
I know it's extremely busy - that's why I was hoping people would use the bits and rearrange it as BloodEagle has so we have more options and ideas on how it can look.
As to the HUD projected onto visor thing, I've always disliked that idea because it's not what is seen in the FS1 cutscene, and the standard terran pilot look has no visor anyway.
It also makes for boring cockpits. :p
Dude! I didn;t know you were this far along.
Layout looks good - personally, I think if people wanted a less-busy data display, they'd turn cockpits off. I do see one or two potential problems though - Cargo and orders will spill outside the available space if they're too long, and the directives and escort lists will be curtailed to being too short. It might be an idea to shift those lists outside of the physial cockpit area and use the freed up space for stuff that the FREDder can enter and potentially make too long. Also, did you do those pictures with a standard HUD screenie, or with the hud layout screenie layout you used above? Keep in mind that anyone using the SCP is probably _not_ running 640, and that does make a difference to the relative sizes of some of the HUD elements. It looks like a standard 1024 screengrab, but if it isn;t you might be able to gain some space in places.
The areas you mention are problematic, yeah. I think it'd be a good idea to do as you and BloodEagle suggest and pull the directives and monitoring boxes out and probably put them back in their original places.
Here are the main potential overflow problem areas:
1) Damage - that list can get pretty long very quick IIRC. Easily enough to spill over the radar. It would probably need to be truncated for the cockpit view.
2) Targetted ship cargo and orders. (The speed and distance would likely need truncating as well)
3) Having more than 3 or 4 wings present in the mission. I don't really know how that bit even works - I think it must stretch the box or something. Getting it to correctly display a maximum of just 4 wings might already be too tricky. :\
As to the resolution, good point. :\
I pulled the graphics for the "Full HUD Features" out of the options screen, which looks like it is 640x480. I'm going to redraw my layout using the graphics in sparky-hi then - that should give a clearer image of the scales of the elements and generally look better. :)
I stole your ammo/fuel gauges, hope you don't mind. ;7
lol, no worries - that's the sort of thing I hoped people would do in this thread, so thanks very much for taking the time. :D
As to your layout, there are some things I think look quite good and some I don't.
1) I fully agree with the moving the directives and escort list back onto the main window - I think that's probably really nessecary.
2) Your Enemy Hull integrity placement is a great idea. :D
3) The biggest problem is association really - mainly things like the energy managment system and the Lag icon don't really fit in with their surrounding controls.
4) I think the actual reticle and HUD brackets should really be displayed on the pop-up glass HUD panel it doesn't really have a purpose otherwise. (Incidentally, there's a single pixel in the centre of the HUD pane to let you line up the reticle - it's centre-screen and exactly where the real reticle usually appears)
more space is needed for the weapons, for ships with more than 2 of each bank.
of course, ship-specific hud layouts and custom copckpits could fix this...
The weapons are the one part of the HUD that isn't actually going to overflow at all - there's enough verticle space there to correctly display 3 gunbanks and maybe up to 4 missile banks. :p
As to the ship specific HUD layouts - that'd be an enormous undertaking to make a separate one for each ship, and considering that really the only things to change from ship to ship are the shield icon and weapons, I don't think it's a good idea really.
Anyway, I'm gonna draw up another layout based on what's been said so far. I also encourage more people to follow BloodEagles example if you have a good idea for this. ;)
-
i dont realy see a point in having two indicators for your weapon, so...
-
I see no reason why the HUD can't be projected onto the visor of the pilot's helmet, which would give more options as to where to put things.
I guess I should point out: in the opening FS1 cutscene, during a couple of the shots you can see that front 'screen' thing (directly in the centre of these screenshots), and the entire HUD as it appears ingame is visible on it. I remember that distinctly. With that in mind, 'sticking to canon' isn't so much an issue I guess... Even though that makes no sense since the text would be too small for the pilot to read, it's what was there.
Oh, and as for the busy-ness... I liked that. One of the more unique features of aircraft or spacecraft is this just /mass/ of buttons and gauges. It may be confusing at first, but I think you'd get used to it quite quickly, and it just seems 'authentic' to me.
Plus, who says we have to adhere to this new uber-minimalistic HUD all the game makers are doing these days? :p
-
Whoops, I mean't to take that out! :lol:
Maybe I could place the energy system there....
:EDIT:
Here it is.
(http://img.photobucket.com/albums/v74/GenoStar/hudmine2-1.png)
-
Plus, who says we have to adhere to this new uber-minimalistic HUD all the game makers are doing these days? :p
The minimalism makes the HUD easier to read and quicker to grasp the information, which gives you an edge in combat.
-
Hot damn, Grimloq returns!
Also, good god, I want that. I WANT THAT COCKPIT.
-
wait for twisted infinites.
-
It won't be coming out for a long while. :p
-
wait till "when its done"*
*known to christians as "the apocalypse"
-
Not just for TI - this is intended for the media VPs to be used to display cockpit models instead of the current "show ship" method (unless "show ship" is turned on for that particular ship).
The idea is that there be an in-game option for turning on visible cockpit models, and if that option is turned on, this POF will display as in the screens, and the HUD will switch to the one we're designing now.
It will definitely need a coders help there though.
Oh, and I expect I'll use it in some of TI's cutscenes though - that was one of the reasons I put a lot of effort into texturing the rest of the cockpit nicely. ;)
-
can you remove those two sticks sticking out of the cockpits upper level? (i think it might be a HUD panel remnant)
-
No because they _are_ the hud panel frames - which is still going to be nessecary. ;)
-
*marge grumble*
well, atleast theres no opaque black square in between them...
-
Currently there is that as well actually. :p
It'll become shiny glass for the final though.
-
i like the "displayed on visor" idea alot better...
buit then again, HUD panels are to me what cockpits are to snail
-
Not just for TI - this is intended for the media VPs to be used to display cockpit models instead of the current "show ship" method (unless "show ship" is turned on for that particular ship).
The idea is that there be an in-game option for turning on visible cockpit models, and if that option is turned on, this POF will display as in the screens, and the HUD will switch to the one we're designing now.
This sounds like a pretty good idea, but you have to remember that FreeSpace ship cockpits have wildly varying shapes. What works for an Apollo might not work for an Erinyes or anything Aldo makes (all those struts...).
-
Oh crap - I'd completely forgotten about cockpit struts. :\
Errm, I'll have to work out how to get them working.
-
I think that would require some creative coding or LUA scripting.
-
Oh crap - I'd completely forgotten about cockpit struts. :\
Errm, I'll have to work out how to get them working.
The only real solution I see is individualized cockpit models, as ships have cockpits of wildly differing sizes, and some that have completely unorthodox shapes, like the Boanerges.
-
On some level it will have to be individualised, but creating custom cockpits like this one here is more work than building an entire HTL fighter, so doing this sorta thing on a per ship basis isn't the way to go about it.
Perhaps creating different ship cockpit frames on this cockpit model and having them as subobjects that either the game or a LUA script can control would work.
Ie, if the script detects that the ship is say, an Ursa, it hides all cockpit strut subobjects but the Ursa's. It would default to no struts.
-
The thing is, an Ursa's cockpit is taller, longer, and wider than an Apollo's, and the Apollo seems to be the main reference for FS cockpit design.
-
We could CUT half of the ETS system display...I mean, any particular reason why you got bars on BOTH sides of the G, S, E letters???? :wtf:
-
Amazing dude !! I think in a near futur we could have 3D planets with the possibilities to travel into system to another like Independance War 2 :p
-
I was never a big fan of these type of cockpits... But this one makes me think that yeah, I could use this.
-
We could CUT half of the ETS system display...I mean, any particular reason why you got bars on BOTH sides of the G, S, E letters???? :wtf:
You realize it's on the top and bottom in the original HUD, yes? :wtf:
-
Trash is weird.
-
why not just stick this cockpit model in all of the ships, with small mofications so it fits?
-
Cobra, Snail - are you high?
WTF are you on about? Shields, Weapons and Engines energy distribution is displayed on ONE place only...and the % bars go both ways. I was saying we can save space buy simply removing one way..there's no need for it..or do I need to make a pic to demonstrate this utterly simple principle?
-
I like trash's idea.
-
but it would be un-freespacey.
-
*GASPS* you are Takashi!
-
no, im snailwich. or am i topturey? or i could be nukoober5000....
-
yep, takashi.
-
back on topic:
nice work VA. it would be nice if we could have a table that allows you to rearnge the BHUD with X/Y coords, and even make it fighter specific, like this:
#HUD TYPES
$Name: HUD1
reticle: ( x, y )
afterburn gauge: ( x, y )
weapon energy: ( x, y )
(ect)
(and even custom gauges)
$Custom gauge:
+ani: enemyhullintegrity
+function: (possibly scripting-related)
+location: x, y
(the above could possibly have no purpose, as such a gauge could be implemented by the SCP)
#END
ship table option:
$Custom HUD: HUD1
-
I'm afraid I'll have to agree with akenashi here; I'd like something that doesn't redesign the original HUD art.
-
Maybe i didn't read it, or didn't saw it, but what about Communication? I really can't think, where they might fit in.
-
In the upper-right corner, where it always was.
-
hud_gauges.tbl already exists.. and iirc has sort of been abandoned due lack on interest (or something)
I have just rearranged shield gauges near the top edge of screen but that is all the little what i have done with it.
http://www.hard-light.net/wiki/index.php/Hud_gauges.tbl
-
well dont put down scripting to much. a 2d radar is actually vary easy to implement in lua. you need to rotate all ships positions to your orientation, then map the coords for each onto your display. now i admit ive never tried this for every ship in a large mission (i did do a test for a single object while writing my turret control script. i needed debug data for what i was doing, and i thought, i could make a radar with this), and i estimate that it could possibly slow down the engine alot. a 3d radar could be done too, but that requires some projection code, and some matrix math if you want something like the orb radar.
there is suffietient scriptability to create a hud with at least 85% of the data on the current hud. and to do things like working levers and joysticks in the cockpit itself. the only thing were really missing is some proper rtt to draw graphics to panels. scripting itself needs to mature abit more and people need to learn it.
-
The 3d radar will work on this thing, right? I liked BloodEagle's implementation.
-
its a damn fine cockpit graphically. but its still not a fully interactive virtual cockpit. ideally id like to see more capabilities as far as those go, even trackir support. we just need that extra 15% of the features in the engine needed to finish the job.
-
Yeah.. 2d radar is possible to do.. but there are lots of HUD options that can not be atm made via scripts (missile lock-on effects for example). I would rather keep the current hud and just move and rearrange the gauges and if needed create a few more but that is about it. Option to RTT - or to get scripting access to - the current elements would be great but using scripting to make an almost identical HUD system doesn't seem reasonable to me.
-
http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/Template1.jpg
I think there would be some troubles. Don't forget that we could display more than 2 squads. And in this case, the display will be mess up. It would be the same for the directives and the monitoring.
I think, you must redesign all the HUD if you want to display all of them in this 3D cockpit.
-
You know it's not exactly HUD if it isn't Heads-Up, right?
-
Exactly - I've been watching this thread with a moderate amount of puzzlement - because it seems everyone is looking at the instrument panels, and saying "HUD".
Personally, as a long-time space simmer - a cockpit instrument panel covers that much of my view - which means it's too large. I prefer to have no instrument panel showing at all. Just a... HUD. Go figure :D Moderately transparent, no view obscuration. Besides - why do we need instrument panels, at a tech level like this? I've always been annoyed when an instrument panel covers half to two-thirds of my viewing area.
-
Can we have the cockpit textures (in 512x512 resolution) My Precioussssss ????
fixed!
-
Worst in cockpit instrument panels is that their usefulness depends totally on the players monitor and its resolution.. For example when i played IL2 - which uses instrument panels - with my 'spare monitor'i had to zoom in to see anything from certain panels which is extremely annoying. Not everyone has 50" plasma screens (or even 20" CRT/TFT screens) or video projector in their household.
12 x 512 :wtf:
-
Yeah.. 2d radar is possible to do.. but there are lots of HUD options that can not be atm made via scripts (missile lock-on effects for example). I would rather keep the current hud and just move and rearrange the gauges and if needed create a few more but that is about it. Option to RTT - or to get scripting access to - the current elements would be great but using scripting to make an almost identical HUD system doesn't seem reasonable to me.
thats pretty much the way i see it. with the option to be able to turn off certain gauges which im replacing with similar but not identical gauges and to take gauges off the hud and rtt them to the panel instead. in the end i hope to be able to integrate the hud, panel and 3d contols into a realistic virtual cockpit.
Personally, as a long-time space simmer - a cockpit instrument panel covers that much of my view - which means it's too large. I prefer to have no instrument panel showing at all. Just a... HUD. Go figure :D Moderately transparent, no view obscuration. Besides - why do we need instrument panels, at a tech level like this? I've always been annoyed when an instrument panel covers half to two-thirds of my viewing area.
if youve seen video of a pilot strapped into his plane, you will always notice the hud is inches from his face. there is no way the panel should be visible while facing full forward. this is why we have a full overlay of the hud. this of course is a very antiquated way of doing things. :D
instead you create a full cockpit with all the goodies i mentioned, combine that with something like a trackir or a couple view axes, and you got some total awesome. then you can have your panel which you can look at as needed, a hud at boresight where you need it and you can now follow the first rule of fighter combat, keep your head on a swivel :D
-
Hmph. What about the new HUD-on-helmet visor thingy?
-
Helmet mounted displays have been implemented with the latest fighter jets like the F-35 and the JAS 39 Gripen.
BTW, I'm one of karajorma's newbies from BTRL. I'm planned on popping my FSSCP cherry by working on a slewable 3D cockpit view, maybe compatible with TrackIR, for full support for situational awareness. So, karajorma led me to this thread and I'd like to help out on this part of the project. Nuke's explanation has pretty much reflects what I want to do.
instead you create a full cockpit with all the goodies i mentioned, combine that with something like a trackir or a couple view axes, and you got some total awesome. then you can have your panel which you can look at as needed, a hud at boresight where you need it and you can now follow the first rule of fighter combat, keep your head on a swivel
-
:welcomeblue:
:D
-
Oh noes! all my eyepoint recoractions in the HTL models where for naught!
-
oh well, your's needed the jpgatga flag to be turned off anyway.
-
No they didn't. :wtf:
-
it didnt?
god...i keep reading the wrong topics.
-
instead you create a full cockpit with all the goodies i mentioned, combine that with something like a trackir or a couple view axes, and you got some total awesome. then you can have your panel which you can look at as needed, a hud at boresight where you need it and you can now follow the first rule of fighter combat, keep your head on a swivel
Question regarding this: The red dot that is present when one is using the mouse look, can that be turned off? cuz it gets annoying after a while, plus, it wouldn't look good with this idea.
Oh, and if idea was put into FS2, i would go out and BUY the TrackIR just for it. :D
-
I'm currently partway through drawing up some more fitting elements for the in-cockpit view in vector graphics, which I am hoping will then be usable no matter which way the cockpit view ends up being implemented. They're essentially just going to make better use of the available space and the colours won't clash with the modeled control panel as those in the template do. :)
As to the implementation:
Currently I'm leaning towards just reconfiguring the existing HUD to make it look like some elements are being displayed on the panels.
I'd prefer to just reconfigure the existing HUD as opposed to script it using RTT as it's less work, probably a lot faster, closer to being possible at the moment and won't be basically re-implementing already existing features. It also has the advantage that the flashing guage effect you see in training missions will still work correctly.
On the other hand, this has me interested, and would probably need RTT:
BTW, I'm one of karajorma's newbies from BTRL. I'm planned on popping my FSSCP cherry by working on a slewable 3D cockpit view, maybe compatible with TrackIR, for full support for situational awareness. So, karajorma led me to this thread and I'd like to help out on this part of the project. Nuke's explanation has pretty much reflects what I want to do.
What sort of features are you refering to here? Ie, when you look at the cockpit in the pics, what sort of things would you hope to interact with in some way?
I ask because if you're willing to do the code behind it, I'd be happy to do things like moving controls, buttons that light up and that kind of thing. :)
Basically, if you want the model to do something, let me know what and how you'd need it set up and I'll implement it at the model level. :)
-
Well.. the idea behind the script thing was that then it might be possible to selectively replace hud gauges with scripted versions - instead of all or nothing system we currently have - and to move the gauges more or less freely on the hud. In addition to RTT that is.
-
it didnt?
god...i keep reading the wrong topics.
Well, turning of the Jpg/tga flag was one of the solutions... the other one was removing all other cockpit files or getting on with the cvs builds
-
What sort of features are you refering to here? Ie, when you look at the cockpit in the pics, what sort of things would you hope to interact with in some way?
I ask because if you're willing to do the code behind it, I'd be happy to do things like moving controls, buttons that light up and that kind of thing. :)
Basically, if you want the model to do something, let me know what and how you'd need it set up and I'll implement it at the model level. :)
Well, for starters, I'm just on implementing a simple continuous padlock view where instead of having four different views (up, 3 o'clock, 6 o'clock, 9 o'clock), we can essentially have a continuous rotating pitch/yaw. I'm still just trying to get myself acquainted with the source code before I go on to do bigger and better things for BTRL and the FSSCP as a whole. Getting scripted avionics and instruments gauges implemented into a 3D cockpit right now is a bit way over my head... As of the moment. :P However, it is indeed something I'd like to pursue if I manage to gain some momentum contributing to the codebase.
-
Hmph. What about the new HUD-on-helmet visor thingy?
usually when a game has a helmet visor hud, its usually an excuse for doing a screen overlay. when they do this it should look like its been projected on to a curved screen.
this actually brings up the question of what were gonna do with the hud when we have fully interactive view controls. we can rtt the thing and stick it onto a modeled hud in the virtual cockpit. which changes the math for some hud emlements. like when you need to figure out where to put a lead indicator on an arbitrary surface in space while youre view angle changes as you look about. the math there is alot more complicated. definatly its gonna break the getScreenCoords function.you could probibly steal the solution from the orbiter source code.
the more likely solution is that the were gonna do the horrid thing that i really dont want to do, keep the hud drawn on the screen dispite the angle of the view. the function for gretting world coords to screen coords should still work.
for the wrap around hud viser look, rtt the whole thing and map it onts a partial sphere, then render it on top of everything. this of course fisheyes everything and things like get screen coords will no longer work properly. im sure theres some other math you can do to compensate the fishbowl effect.
a 4th possibility is something i wanted to do on the phoenix fighter, a holographic hud. actual 3d models or wireframe will be rendered in the forward section of cockpit where the hud would normally be. theese would either be submodels in the cockpit or models rendered through renderTechModel(). this would be on the same per-ship implementation for things like yokes, sticks, levers, pedals, and orientation spheres i already plan to use.
-
Well.. the idea behind the script thing was that then it might be possible to selectively replace hud gauges with scripted versions - instead of all or nothing system we currently have - and to move the gauges more or less freely on the hud. In addition to RTT that is.
I've thought about that, yeah. If this free-look thing happens, then the HUD will have to be RTT'ed onto the viewscreens. How feasible, how efficient and how good looking this would be I'm not sure.
At this stage though I'm just going to approach it as though it will just be the usual HUD elements reskinned and repositioned to *look* as though they're being displayed on the panels.
================================
Anyway, the next phase of development is really up to the coders. Here's the POF, texture, COB and TBM in it's current state if it's needed for testing:
http://webzoom.freewebs.com/twisted-infinities-va/TerranCockpit.rar
Note to modders: These files are NOT the final version! Don't begin incorporating them into fighters or anything, because you'll only have to yank them out and replace them when we get a final version happening!
I posted this list on Sectorgame, but maybe a coder here will read it and respond:
Before I go further with this, I really need a coders thoughts on the implementation.
What would be the best way to handle players turning cockpit view on or off?
My current idea is to have it as an in-game or at least launcher option rather than having to add bits and pieces in the right places.
==========
To get such a feature working, it would need a couple of aspects to it:
1) If the flag "show ship" is present on the ship the player is in, then nothing should happen. (Ie, this assumes the modder has their own cockpit model they want to use)
2) It would need to lock the FOV the game used to the default. (Using something else would totally mess it up)
3) It would need to load up this cockpit POF and position it so that the models eyepoint is placed around the viewpoint, and rendered only when in normal view (ie, it would be hidden when in chase view)
4) It would need to switch the HUD over to this alternate layout (once a form has been decided on). I'm not really sure how this would be handled - and it's the main part I need a coders input for.
===========
There are a couple of longer term and slightly more complex features that should probably be implemented eventually too:
5) This might be possible to do via scripting already, but it'd need to display the appropriate canopy struts for the ship the player is in. They'd then be set up as separate appropriately named submodels in the cockpit POF that could be hidden or revealed by the script/code.
Ie, you'd call the Herc's strut submodel "fighter06" or "GTF Hercules" depending on which is better/easier to access.
6) Some way for the modder to define the cockpit POF used so it could basically be changed on a per-fighter basis for anyone macho enough to make multiple cockpit models. This would really be needed for things like the SWC or BTRL which have craft that have very distinct cockpits rather than FS' style of one standard fits all. :)
I'm more than willing to help out the coders on the modeling/texturing/interface art side of things. :)
Incidentally, the HUD_gauges.tbl feature is currently only partially implemented. As is we can only modify: "Player Shield, Target Shield, Shield Mini, Afterburner Energy, Weapons Energy and Escort List" according to the Wiki. Any chance this could be completed?
=======================
Well, for starters, I'm just on implementing a simple continuous padlock view where instead of having four different views (up, 3 o'clock, 6 o'clock, 9 o'clock), we can essentially have a continuous rotating pitch/yaw. I'm still just trying to get myself acquainted with the source code before I go on to do bigger and better things for BTRL and the FSSCP as a whole. Getting scripted avionics and instruments gauges implemented into a 3D cockpit right now is a bit way over my head... As of the moment. :P However, it is indeed something I'd like to pursue if I manage to gain some momentum contributing to the codebase.
Ok, fair enough. :)
-
hud_gauges.tbl was designed from the start to be accessible to other coders besides me.
It looks like the main difficulty is that the NEW_HUD stuff clutters things up a bit. I don't think that's in use. I remember that it was 'better', but it was a work in progress when it was discontinued. Basically, I wanted to focus on the scripting stuff, because I was ending up redoing a lot of the internal FS2 gauges via copy-paste, and it seemed a bit silly to do all that when a full scripting language would let someone re-implement the entire HUD, and then other people could base various modifications off of that re-implemented HUD. Those modifications could have far more variety than just different images, text, or positions.
I'm doing some cursory looking at the code right now.
Old hud_gauges
I'm assuming this is the current version because NEW_HUD is commented out in hudparse.h
The old HUD system defines an array at the very top of hudparse.cpp. It's very big, you can't miss it. Each entry in this array represents a HUD gauge. Rather than taking responsibility for drawing each gauge, though, the old HUD system simply manages the information required to store the gauge, and even then, only in a limited fashion. You can store the position and size (which is what people are most interested in) as well as an image, some text, and a color. These are specified either via SEXPs or via hud_gauges.tbl.
The interesting thing about the way the array stores the data lies in the offset operation it uses to do so.
To add a gauge to hud_gauges.tbl, you:
(1) Add variables (of the appropriate type, of course) to the hud_info struct in hudparse.h. Look at the custom_gauge_* variables to see what kind of information hud_gauges.tbl supports. If you wanted to add support for the radar, for instance, a good starting point would be to create a "int radar_coords[2];" array to store the coordinates for the radar in.
(2) Add a new line to the "gauges" array at the top of hudparse.cpp. If the gauge location is independent of anything else, it should go in the top row. If it is dependent, it should go in the bottom row.
(3) Fill out the new line in the "gauges" array
(3a) Parent specifies the parent gauge, if there is one. For example, the parent gauge of an entry in the escort list would be the main escort gauge.
(3b) coord_dest refers to one of the variables you added in one, specifically, the one you created for the gauge coordinates (an int[2] array...right?). To refer to it, just use "HUD_VAR()" with the name in between the parentheses. Do not ask what HUD_VAR does, assume it is magic and it works. Or look at the define and do research on your own.
(3c) The token name that the gauge should be referred to in the table. This includes the "$" and ":", see the existing entries.
(3d) The next four variables are integers specifying the default X and Y positions in 640x480 and 1024x768, respectively. This one is the X for 640x480
(3e) Y 640x480
(3f) X 1024x768
(3g) Y 1024x768
(3h) This refers to the variable in hud_info for the gauge size (int[2])
(3i) Ditto for the image name (char[MAX_FILENAME_LEN])
(3j) Frame number of image to display (int)
(3k) Text to display (char[NAME_LENGTH])
(3l) Color of gauge (color)
(3m) Placement flags. Basically, the system will automatically offset child gauges from their parent gauge by the specified coordinates unless you add the HG_NOADD flag here. If you are dealing with the position of list items, you will want to use HG_NOADD and handle the values specified for the list items in the HUD update function. See the escort list for more details.
(3n) Show flags. I don't know if this actually does anything so ignore it.
(4) If you added fields for color, size, text, etc you should specify the default values in the load_hud_defaults() function. See the comments in that function.
(Timeout) Now that you have all the info for the gauge_info struct filled in, you should be able to specify the gauge in hud_gauges.tbl and have Freespace 2 load it. However, you will see no changes.
(5) Go to the location in the code where the gauge is displayed. This is the fun part. You can now access any of the variables that you created in step 1 using the current_hud-> pointer. hud_gauges.tbl will take care of filling out this pointer (though an assert wouldn't be a bad idea). In addition, hud_gauges.tbl will take care of filling out the values and interpolating for the various screen resolutions. You can choose to use the fields in whatever way you please.
(6) Increment Num_gauge_types to reflect the number of items in the gauges array.
New hud gauges
I spent a lot of time on the last section so I will only provide a brief summary of what I remember/have determined about the new hud gauges.
The idea of the new HUD gauges was to redesign the entire Freespace 2 HUD API to make it infinitely easier to work with, mostly by making things object oriented. This would also add some nifty new functionality, like gauges would be tied into the ship you're currently viewing from, rather than always being focused on the player ship.
In addition, it was supposed to add the ability to predefine certain gauge types and create all-new gauges. So you could turn a number gauge into a bar gauge, for instance.
As time went on, though, it became apparent I would have to implement a fair chunk of a scripting system's functionality in order to make the new HUD gauge system fully functional. So I dropped it in favor of scripting, which became my focus for the next two years. (That's kinda scary, actually)
The new system is infinitely better than the old one, IMHO. However, it requires extra work on a per-gauge basis to get the :V: gauges to conform to the new system. It doesn't implement a table, although it would probably be only moderately difficult to tie it into the hud_gauges.tbl system. Furthermore, key features like flashing are not implemented with the new system. The idea was to have it be possible to transparently swap the :V: system for the new HUD system. But that was, IIRC, starting to become something of a nightmare because of how hardcoded the :V: system was. Imagine the Beast from Homeworld infesting the FS2_Open HUD subroutines. That's kind of what it seemed like.
The NEW_HUD stuff also worked on the idea that the update functions for each hud gauge should not directly display the HUD media. This would allow the data to be cached and the image or text to simply be re-displayed without any calculations for each frame that the gauge didn't change.
At this point, it would be great to see some of those advancements hit the FS2_Open HUD system. But it would take a lot of work to get to a 'completed' point.
Summary[/u]
Adding gauges to hud_gauges.tbl is not as scary as it seems, once you figure it out. Beware the NEW_HUD defines.
-
Hmm...I didn't mean to scare everyone off.
-
its just that none of us understand that mass of code you call hudparse.h and hudparse.cpp.
-
Have you even seen it? I really doubt you have.
-
yes
#ifndef NEW_HUD
//Set coord_x or coord_y to -1 to not change that value
//void resize_coords(int* values, float* factors);
//void set_coords_if_clear(int* dest_coords, int coord_x, int coord_y = -1);
//ADD YOUR VARIABLES HERE
//Gauges MUST come first, and all variables MUST be in the hud struct.
//Use this when setting gauge variables. It gets the OFFSET of the value in the hud_info struct
#define HUD_VAR(a) offsetof(hud_info, a)
gauge_info gauges[MAX_HUD_GAUGE_TYPES] = {
{ NULL, HUD_VAR(Player_shield_coords), "$Player Shield:", 396, 379, 634, 670, 0, 0, 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Target_shield_coords), "$Target Shield:", 142, 379, 292, 670, 0, 0, 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Shield_mini_coords), "$Shield Mini:", 305, 291, 497, 470, 0, HUD_VAR(Shield_mini_fname), 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Aburn_coords), "$Afterburner Energy:", 171, 265, 274, 424, HUD_VAR(Aburn_size), HUD_VAR(Aburn_fname), 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Wenergy_coords), "$Weapons Energy:", 416, 265, 666, 424, HUD_VAR(Wenergy_size), HUD_VAR(Wenergy_fname), 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Wenergy_text_coords), "$Weapons Energy Text:", 439, 318, 708, 509, 0, 0, 0, 0, 0, -1, -1 },
{ NULL, HUD_VAR(Escort_coords), "$Escort List:", 486, 206, 865, 330, 0, HUD_VAR(Escort_filename[0]), 0, HUD_VAR(Escort_htext), 0, -1, -1 },
//Mini-gauges
{ &gauges[2], HUD_VAR(Hud_mini_3digit), "$Text Base:", 310, 298, 502, 477, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[2], HUD_VAR(Hud_mini_1digit), "$Text 1 digit:", 316, 298, 511, 477, 0, 0, 0, 0, 0, -1, -1 },
// { &gauges[2], HUD_VAR(Hud_mini_2digit), "$Text 2 digit:", 213, 298, 346, 477, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[2], HUD_VAR(Hud_mini_2digit), "$Text 2 digit:", 313, 298, 506, 477, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[5], HUD_VAR(Escort_htext_coords), "$Header Text:", 489, 208, 869, 331, 0, 0, 0, 0, 0, -1, -1 },
{ &gauges[5], HUD_VAR(Escort_list), "$List:", 0, 12, 0, 13, 0, 0, 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_entry), "$Ship:", 0, 11, 0, 11, 0, HUD_VAR(Escort_filename[1]), 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_entry_last), "$Last Ship:", 0, 11, 0, 11, 0, HUD_VAR(Escort_filename[2]), 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_name), "$Ship Name:", 3, 0, 4, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_integrity), "$Ship Hull:", 128, 0, 116, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 },
{ &gauges[5], HUD_VAR(Escort_status), "$Ship Status:", -12, 0, -11, 0, 0, 0, 0, 0, 0, HG_NOADD, -1 }
};
-
:eek2:
...Well, I'm speechless.
-
...Well, I'm speechless.
Aken is now backing up his claims.
-
want the picture of khonsu in a hitler outfit to back up my claim of vasudans-are-evil?
-
want the picture of khonsu in a hitler outfit to back up my claim of vasudans-are-evil?
Jews come and eat you up.
Germans come and eat you up.
Vasudans come and eat you up*
* - Well your head at least.
Why are Vasudans evil? Without the fishes, Sol would be a giant crop circle by 2335.
-
Yes, he is. Now stop picking on him, it's really grating.
-
Huh? It's not like I was picking on him?
-
Oops. I was replying to the banter on the previous page, I didn't see that there was another page. Still, stop doing it, it's done in almost every thread he posts in.
Continue as you were :p
-
its just that none of us understand that mass of code you call hudparse.h and hudparse.cpp.
Well the code segment you quoted is supposed to be the most complex code you'll have to mess with in those files. I listed out what each field does in step 3. I guess it's not indented consistently, but it's just your standard kind of situation of creating a new array and initializing it with a bunch of default values. The same thing is done in parse/sexp.cpp, so I figured it would be Freespace coder-friendly.
-
the only code i know is how to create a simple DOS-based mad-lib program :blah:
-
That actually sounds kind of fun :D (http://www.youtube.com/watch?v=OVLuHDEeCPM)
-
WMC: I'm unclear if what you're saying here is what a coder would need to do or what a TBL modder could do.
I *think* what you're saying is that the reason it appears to be half finished is that you've not gone right through hard-coding default HUD_guages.tbl compatible entries for each existing HUD item?
If that's correct, does that mean I could re-create the rest of the standard HUD guages using the tbl already (Ie, without touching the code)?
-
it sounds to me like theres a rather large volume of rather unexciting code to write, and noone wants to do iut :D
-
Write the code, people, we want a functioning cockpit. :P
-
WMC: I'm unclear if what you're saying here is what a coder would need to do or what a TBL modder could do.
I *think* what you're saying is that the reason it appears to be half finished is that you've not gone right through hard-coding default HUD_guages.tbl compatible entries for each existing HUD item?
If that's correct, does that mean I could re-create the rest of the standard HUD guages using the tbl already (Ie, without touching the code)?
Er, from a modding persepctive it means that you only have access to the gauges in the table that are included in the reposted code segment. All of the other gauges use hardcoded :V: defaults that are outside the control of the hud_gauges.tbl system.
What needs to be done is that a coder needs to add the data for those gauges into the hud_gauges array, and change the hardcoded :V: gauges to use the hud_gauges variables. (The many-step procedure I outlined above). It's not that hard, and Nuke is spot-on about it being a lot of uninteresting code to write. It's not even that likely to cause bugs unless you mess up basic syntax or miscopy a number.
Speaking of which, that actually makes me realize that I left a step out. The "Num_gauge_types" needs to be set to the number of default gauges in the array. Right now it looks like it's off by one.
-
WMC: Ok, thanks. A pity it's code changes though - I'm not at that level yet or I'd already be working on it. :(
==========
Right, new layout. It's pretty much all vectors, and so I can easily turn it into a new HUD graphics set.
Full feature set:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/Template2_Full.jpg)
Typical feature set:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/Template2_Typical.jpg)
And my favourite look - what it could end up like after just having a glow added:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/Template2_Brightened.jpg)
Any suggestions or anything for this layout?
====================
Well aside from layout fiddling, I think I'm now at the limit of what I can do to get internal cockpits working without a coders help. It really needs the functionality I listed before to be implemented before it can be taken further. :\
-
How about directives, monitoring, and in game chatter ?
-
looks pretty nice with the glow...the cockpit could be more detailed though, but this thread is not about the cockpit themselves I figured.
But what about widescreen monitors like the one I use? will the HUD be properly displayed on 16:10 and 16:9 formats?
-
keep hte escort list and wingman list out of the cockpit..leave it where it was (a projection on the helmet glass)
Another problem I see is the ship status...it's nice when you got a smal lfighter with exactly 5 subsystems....but what I fly a bomber with 4 engines and 4 turrets??
Everything else looks...schweeeeet
-
What i am worried is the equipment (monitors etc) and resolution (as well as width:height ratio) dependency of these cockpits
-
How about directives, monitoring, and in game chatter ?
Yeah, forgot to put in the messages, objective complete/failed messages, lag indicator, comm system, escort list and directives - they're supposed to just be in their original places. Some of them can quickly get far too big to fit on the console screens.
looks pretty nice with the glow...the cockpit could be more detailed though, but this thread is not about the cockpit themselves I figured.
But what about widescreen monitors like the one I use? will the HUD be properly displayed on 16:10 and 16:9 formats?
I couldn't really detail it up too much more than I already have - it's supposed to be based on the one seen in the FS1 intro. Remember it's still an in-game model that uses a 1024 res map with shine and glowmaps (if it ends up not using RTT stuff though, I can probably cut it down to 1024x512)
As to the widescreen (and ratio) dependancy - yeah it's a problem, but again I don't have the means to solve it. We need a coder.
keep hte escort list and wingman list out of the cockpit..leave it where it was (a projection on the helmet glass)
Another problem I see is the ship status...it's nice when you got a smal lfighter with exactly 5 subsystems....but what I fly a bomber with 4 engines and 4 turrets??
Everything else looks...schweeeeet
The ship status thing isn't really a problem - the list can just be truncated to display 5 as a max, or it could scroll through them. Again it'd need a coders help for that though.
BTW, the idea is that nothing is projected to the pilots helmet, simply because the FS pilots helmet has no faceplate glass anyway. I'd envisiage the directives and escort list appearing as holographic projections in mid-air.
-
Well if mouselook and whatnot ever gets implemented, you could always add another screen between the pilot's legs, like several jet fighters have today. You could probably fit most nonessential stuff there.
-
Woah... Much better but, the Black areas could be abit more erm...MOre detailed or like have GreenGlow like in the cutscene IIRC.
-
I could probably give the console screens a background of the standard menu backdrop - the faint greebly thing. I can't really put much else in without it likely overlapping something in an ugly way.
And UT: Yeah - there's a fair bit of screen area down there already (see the first pic in the thread) but probably not enough to fit everything. :\
-
How about a very faint grid of green lines for the backdrop?
-
In what way? 'X', '\', '/', '-', '|', or '+'?
-
As to the widescreen (and ratio) dependancy - yeah it's a problem, but again I don't have the means to solve it. We need a coder.
You need a gimmick to get a coder. Coders are always in short supply 'round here, as everything is quickly becoming dated by 'modern' standards. (Take a look at Prey - meanwhile, we can't even get intrasystem warping implemented properly, you need a FRED hack to do it. Don't even mention bumpmapping, shaders are IIRC slated to maybe appear in another year.) There is nothing innovative to attract people, nothing that makes people go "Cool, I want to see how they did that!" or "Cool, I'd love to help out with the AI system, it's so flexible." The last major thread I read about attracting new coders, the guy suggesting a post got shouted down by everyone because he suggested adding new capabilities rather than bugfixing. (The argument being that the engine is so broken/outdated that the new capability couldn't even be added without a lot of bugfixing)
There's the chance that people will crawl out of the woodwork and volunteer to clean up other people's messes because they want the experience it will get them. But, it's very unlikely. Most people seem to want to help out because they see something cool.
So here's my roundabout point. If you get what you want, a coder who visits these forums, somebody else loses out on what they want. Bumpmapping gets pushed back another month. Multiplayer changes get shelved for 3.6.10. One of the big TCs can't implement a critical feature, because the coder who's supposed to be doing it is working on your changes.
The solution: Figure out a way to bring in more resources, or make the gain outweigh the cost. This could be learning to code (http://www.hard-light.net/wiki/index.php/Coding_In_C), figuring out a way to attract coders, figuring out a way to make the HUD without (http://www.hard-light.net/wiki/index.php/FS2_Open_Lua_Scripting) hardcoding (http://www.hard-light.net/wiki/index.php/Scripting.tbl). Or you could try to ally yourself with a larger project who might also be interested in the feature you're requesting (http://www.hard-light.net/forums/index.php/board,46.0.html), whose success could lead to the recruitment of further coders (or who might have 'in house' coders willing to work on it).
"Nothing in life worth doing is easy".
-
Err, you make it sound a bit like I'm whinging about there not being a coder who is jumping up and down to work on this - I know there isn't and I'm not really worried. :)
Basically I was looking over the past cockpit implementation argument threads and found that it usually ended with something along the lines of 'build us a cockpit to use, and we'll code it' from a few different people.
So; I've done the freespace version of a cockpit model and texture for use with the FSU project. I know UT has a Viper cockpit in store for BTRL, and if mods like the SWC or WCSaga want to use cockpits I'd imagine they'll all support any coder willing to do the work out a cockpit system.
I know there are portions of the community who do want to see cockpits like this, so I'm quite sure it will come in eventually - which is why this is a 'HUD layout' thread and not a 'Pwese code in cockpits now!' thread. ;)
As such, this cockpit is basically for the community rather than because I want cockpits. Heck, I would originally have been one of the peeps to turn them off. :p (After working on this for the weeks that I have though, I've changed my mind about that. I think it does improve the immersion factor.)
As for the other options, I am currently trying to learn scripting, and I do have every intention of learning C++ eventually. However, remember that we're also somewhat short on HTL modelers/UVmappers/texturers - which are all areas where I've focused my attention over the past years, and so can have more of an impact.
-
If I could pound it into my thick skull I'd help, but C just looks like a jumble of integers and variables. Yet for some reason I feel like I have some level of understanding it. :wtf:
-
Coders are always in short supply 'round here, as everything is quickly becoming dated by 'modern' standards. (Take a look at Prey - meanwhile, we can't even get intrasystem warping implemented properly, you need a FRED hack to do it. Don't even mention bumpmapping, shaders are IIRC slated to maybe appear in another year.)
Semi OT, but wow, that comment made me realize for the first time that FS2 is, well, old.
-
In what way? 'X', '\', '/', '-', '|', or '+'?
A grid of straight vertical and horizontal lines, like graph paper.
-
the way i see it virtual cockpits only require at most a few minor features. view code, a few more script accessible vars, and rtt fixes. with the way im picking up programming il probibly be releasing builds of my own features by next year (that is assuming i can find the time).
-
Hi,
I just recently stumbled across FreeSpace 2 and absolutely loved it. The space-sim genre has pretty much died in favor of yet another RTS or FPS, so when I stumbled upon this gem I was very happy indeed :)
I would like to contribute to the project coding wise and I'm still busy familiarizing myself with the code. I'm looking for things to work on and was actually wanting to work on the AI, but having read this thread and seeing that Vasudan Admiral is devoting time to actually drawing cockpit views etc. I would like to try to help out to get the cockpit views implemented.
Quite a few ideas were raised, in terms of how the cockpit views should be implemented. From a fish-eye projection onto a computer player's helmet, to a 3-d holographic projection, to a mouseview system where one can look around the cockpit... and then also some kind of drawing created by an artist that gets overlayed(If I understand correctly, this is what you have done Vasudan Admiral? Or is your cockpit some kind of 3D model? ).
The initial idea I had, was to have each gauge to be a picture that can be arbitrarily placed anywhere on the screen, with some sort of scripting or table editing to specify the coordinates of the gauges. Additionally, I thought that the gauges could be animated and that certain events such as increasing speed, trigger animations (by for example moving to the next frame for an animation) for that particular gauge. The process of bringing up a communications window for example, could also be an animation albeit a very short one.
What are your thought on that idea?
The problem comes in when you want to have a mouseview in all directions. A fisheye projection of the above gauges etc is a possible solution, but the problem of drawing the main reticle still remains. The reticle can't move along with the visor unless the guns actually move along with the person. A possible solution is to not draw the reticle unless the player is facing the front (with some tolerance).
Personally, I think we should not start off being to ambitious. We should only worry about mouseviews and the like once we can refractor the code so that the placement of new cockpit textures and the scripting thereof is sorted out. Once the basics are in place, then the code can be refractored some more to include new ideas.
I think that once we start seeing some small successes, perhaps more momentum will fall behind this endeavour.
-
:welcome:
Another coder would be fantastic. :D
As to the cockpit, since this thread there's been another in the SCP forum: http://www.hard-light.net/forums/index.php/topic,50537.0.html
By the looks of it, 3d cockpits and the appropriate HUD display changes are indeed either planned or in development, so you'd need to ask a coder about where that's up to. According to Taylor, the initial goal is just going to involve the ability to specify a separate cockpit model from the ships table for each ship. In the long run, it will involve being able to render individual HUD elements onto a texture which is then applied to that cockpit model. Doing it that way would allow for correct mouselook views. (Not sure how the system would handle HUDs that have half of the elements done the old way and half on RTT though).
I'm sure everyone would greatly appreciate any help you could provide with any of the planned features. :)
-
Samuel, thank you SO much for bumping this thread, because I never saw it!
Quite a few months ago, even before this thread began, I started work on expanding the hud_gauges.tbl code (originally by WCSaga's request). I didn't want to say anything yet because I was focusing on the new gliding system and a few other things. Then in August my RL work began sucking the life out of me, and I kind of vanished from the forums for a while. Then I had some hardware troubles and nearly lost all my code, but with some clever use of recovery utilities and virtual machines I ended up saving most of it this month.
Long story short: I'm working on expanding the "old method" of the hud_gauges.tbl code and am making progress again! As Nuke said, it's a lot of unexciting code, but it is not too complicated and I can do it, so I am. So far I have mostly done:
-the directives (as well as a "$Max Directives:" setting, hooray)
-the talking head window
-the target box and stats
-the flashing threat gauges
-the reticle and arc frames (not the throttle yet)
Halfway done with the radar, but it's being stubborn. Not looking forward to the complicated weapons selection gauge.
Vasudan Admiral, could you make available those ammo/fuel gauges in some form? I wanna put them in .ani format for um... testing :D [it wouldn't be testing anything NEW because weapon / afterburner energy already works in the hud_gauges.tbl ;)] I'd do it now except I don't know what they look like empty...
-
That's great. :D
My desktop is currently mid-render so it'll have to wait till that's done, but I'll put them together as soon as I can. Do you want the HUD elements each as a set of images that matches how the current guages are set up? Ie, one frame for each 'incriment' of the speed indicator?
-
That'd be perfect. Like that they would already work as drop-in replacements, since those gauges are already in the code. No rush -- it's just eye candy as I fiddle around with the rest of the stuff.
Hey you OTHER coders out there, testing this stuff would be a bit easier if we had a command-line way to immediately launch a specific mission ;)
An interesting observation: Turns out the retail code doesn't use the hi-res images for the escort, directive, comm window, minishield, and target box gauges.
-
lol, that's interesting - I suspected something was amiss when I was first making these templates. I pasted all the high res ones over a template hud screenie, and then was like 'Hey....they don't fit.'
-
Having read the thread
http://www.hard-light.net/forums/index.php/topic,50537.0.html (http://www.hard-light.net/forums/index.php/topic,50537.0.html)
I see that the decision is to move away from a fish-eye kind of effect, to complete 3D models for cockpits which would then allow a mouseview inside it. I'm not sure how it is planned, but I anticipate that most of the current code (the current way of doing HUD's) is going to be ripped out. It also looks like a long term goal (6-9 months), and since Backslash has already expanded the flexibility of the current HUD method, perhaps it would be worthwhile to finish this before we embark on the long term goal of 3D cockpits. This would at least give modders a little more flexibility and the look of the game could be enhanced quite a bit, while we work on the more long term 3D cockpits.
What is your view on it backslash? I'm sure you wouldn't want all your work to go to waste ;)
-
The current HUD code is a mishmash of animated clipping, multi-frame animations with individual frames overlaid over each other and gamma-controlled to show information, and other very interesting but somewhat obscure tricks.
I really think if you do anything with the HUD, you should aim to go far beyond what's in there now. The HUD is such a total waste of potential, because there's a lot of great bizarre gauges you could do with a little 2D knowledge and some 3D functions. It also practically hasn't been changed since Freespace 2 was released...even though the majority of it simple 2D functions. It's hard to deal with "the HUD" because it's so scattered and intertwined with the rest of the code, and incredibly hardcoded to boot. (Just check out the section of the code where it deals with the options screen for adjusting the brightness and settings of the various gauges....yuck.)
I wouldn't mind seeing any of that being changed. The current hud_gauges stuff is mostly a hack that tries to get around the convolutedness of the current code by just defining values to replace the ones that the original code uses. But it's not expected to be real consistent or flexible. If you add a 'text' field to the shield gauge, where ought it go? Should it be the same color? What font should it use? What coordinates should it use - relative to the gauge, relative to some corner of the screen, relative to another gauge? Pretty soon you have enough options to use a significant number of variables and require a lot of code to deal with, none of which is really supported by the current HUD.
I think one way of dealing with this would be to define a standardized method for dealing with screen events that might impact the HUD, then develop some way of piping these events into gauges. That would be a ***** to do properly, but could be done cleverly...for example, a pipe to a text object generator that's connected to an autoscroller, so that the end result is to copy the current messaging window. That sort of thing would let you do HUD stuff in C space, rather than scripting or SEXP space, so you could work with what was coded in more efficiently.
Another route to go is with predefined gauge types (eg variable-height image, variable-transparency image, text, etc) whose attributes are settable via scripting, or SEXPs.
I think the base thing, though, is that I would hate to see something designed that's based on the current HUD. If it's flexible enough people will redesign the retail HUD. In fact, that's kind of ideal, because then you could distribute the scripting or configuration or whatever-file to people and they could tweak something that they're already familiar with. You could include it with the code, so you didn't have to rely on the hardcoded stuff and wouldn't have two separate ways of doing the same thing. Actually, I do think it's possible to convert a lot of the hardcoded stuff to use dynamic gauge names and such that would still be compatible with all missions.
Anyway, it's painful to me to read those threads because people get all worked up about things. "We're going to add in separate cockpit models" - that's about 15 lines of code. "We need to rip out the current way of doing cockpit models because it's stupid" - that's about 25 lines of code. The crux of that is 1 line in an if statement's conditional, the rest is just dealing with resetting the clipping plane and the code to toggle it from the table. Now, when you talk about all the nice little spoofs, showing damage and stuff, then you can add enough features to your heart's content and add as many lines of code as you want.
And when you talk about 3D hud gauges, you're talking about something else entirely different from 3D cockpits.
That last thread especially really bugs me because it should not take 6-8 months to implement separate cockpit models. It probably literally took me longer to write this post than it would take to implement that feature. The only saving grace is that taylor talks about adding in LOD scaling and other nice features like that.
So detailed summary:
3D Cockpits as separate models:
So easy that it's not even worth talking about anymore. I think after I finish this post, I'm just going to do it because I'm sick of people talking about it.
3D HUD Gauges:
Also pretty easy. Freespace already has functions for drawing dots and lines and stuff in mission space for use with FRED. And obviously it can draw models in mission space too. So with a little use of model_find_world_point and some code in ship_render, after the ship- and cockpit- rendering stuff, you render your 3D gauges and presto! You can look around the cockpit and you have fixed 3D gauges (fixed relative to the ship, not to your view) floating in the air. If you're not happy with that, you just ignore the zbuffer and render them on top of whatever's there, and you can get 3D hud items much like the ship models in the targeting computer.
HUD gauges on 3D cockpits:
bm_make_render_target. bm_set_render_target. Render gauge to your heart's content. bm_set_render_target(-1). Replace a texture on the 3D cockpit model with the render target texture. Rinse and repeat. (In fact you don't have to repeat bm_make or the texture replacement, just keep the texture handle around and re-render to it every time)
Another HUD management system:
Priceless. And this is where the pain starts. Actually rendering 3D HUD gauges is already possible. But this is where you have to figure out how you're going to let the modder connect the data to the HUD gauges, and you have several options that involve tradeoffs between ease of use vs potential vs processing power.
This would be a perfect place for dual core stuff, in fact it may be the only place in Freespace 2 that dual core stuff would be practical to add, because the display is mostly passive and if it's off by even a half-second nobody cares.
You also have to figure out how to handle the retail HUD gauges. Are you going to leave them hardcoded and rewrite a completely new system that ignores the old code? Are you going to leave them hardcoded but integrate them into the new system? Or are you going to write the new system and then rewrite the retail gauges using the new system? How are you going to handle the options screen? What aspects will you give users to control vs modders vs mission-makers? Will you let any of these groups control what another group can do?
Will you allow interactivity with the HUD? How? Mouse/joystick/keyboard/TrackIR/speech?
How will you let people specify where HUD gauges go? Percentages? Pixels? Or will you let them use both? How will you let people specify if they need a hud gauge to move around, or be offset from a 3D object that may or may not be on the screen at a given time (eg the missile lockon indicator).
OK, I'll stop there so I don't scare you off. If I haven't already. ;)
-
And...time! (Working test completed)
Hmm...so about an hour. Although I did implement a scripting variable too, I couldn't resist. :p
EDIT:
The implementation
Basically it displays a model using the current FOV, assuming that the camera is located in the exact center of the model. I've added padlock & slew view support, as well as an 'offset' parameter.
What does concern me a bit is that right now, I'm resetting the projection matrix to get the right clipping distance. From what I understand from taylor, this is costly in terms of time. If I don't set the projection matrix, it will force all cockpit polygons to be at least 1 meter from the camera at all times, which would probably break scaling.
EDIT 2:
Release (http://www.hard-light.net/forums/index.php/topic,51203.0.html)
-
Thanks for you valuable input WMCoolmon. The freespace community is very fortunate to have someone of your calibre on the team, not only because of your coding talent and knowledge of the source code (1 hour lol!!!) but because you have an incredible knack of presenting the issues and problems in a very clear and concise manner.
I'd like to pick your brain a little more on this issue ;)
Another HUD management system:
From your discussion, clearly this is the way forward. You point out the different possibilities and the various design decisions that have to be made. I'm very new to the source code, and also don't know what process you as developers follow. So my question is: who is going to make some of those key design decisions? Is it up to the person who decides to tackle this? Is the design discussed in the internal forum? I think whoever starts working on it would do well with periodic feedback from you or others who are more experienced.
Personally, I think that the HUD management system should be totally redesigned and the existing HUD reimplemented in the new system. You have already alluded to the benefits of this. Firstly it will make debugging the system easier since we KNOW what and how things are supposed to function. Also, the resulting scripts, tables or whatever will make more sense to modders since they know how the existing HUD behaves and could act as a sort of tutorial for the new HUD management system.
To summarize, my key question is can you offer some way forward for someone who wants to help code the new HUD system.
-
Thanks. :)
Whoever designs the system generally gets ultimate power in the design. The only hard limitations are that you maintain backwards compatibility - so the existing HUD uses the same external media files and acts the same way in-game as it does now - and don't degrade overall performance in backwards compatibility mode.
Since you're not in the SCP, the code will probably be scrutinized before it's committed, so if there are obvious mistakes or serious improvements that could be made, you'll probably be asked to attend to them before it's added. Most likely these would all be related to performance/stability. If there are issues people have with the design, they might complain, but I doubt your code would be outright rejected over opinions over design.
So as far as a way forward, it's entirely up to you up until you decide that the code is submitted to be committed to CVS. You might want to fix some bugs or add some small features to get familiar with the code before you embark on a project as large as this. You'll probably want to make new .cpp and .h files for the main portion of the code, and familiarize yourself with def_files.cpp so you can add the default table when you're ready.
You might want to do a little design first before you start a thread devoted to talking about the system, so that people have something more concrete to talk about.
You'll probably want to start coding from the unstable branch, since that will be the base for future SCP releases in the longer-term. You should familiarize yourself with SEXPs, if you haven't already, look over the basic table parsing functions and check out the scripting section of the code. hudparse.cpp could also be valuable. There's actually portions of an incomplete alternate HUD system in there under the NEW_HUD defines, besides the hud_gauges stuff. It's not well-commented but I can probably explain anything you have questions about.
And finally, you should know about the HUD gauges already implemented in the HUD, so you know the minimum feature set you need to implement. :p Stuff like the comm menu, for instance, will require responding to keyboard events and knowing the key bindings.
-
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]
-
Hmm, does he already know the CVS checkout procedure (http://www.hard-light.net/wiki/index.php/Getting_the_FreeSpace2:_SCP_Source_Code)?
-
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 :D
Now I'm going to go digest WMCoolmon's paragraphs some more ;)
-
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
-
Uh, this won't screw up the way it already looks, will it? :nervous:
-
No. Or you'd have kara jumping up and down about Retail compatibility. XD
-
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:
(http://images.eurogamer.net/assets/articles/a/5/4/4/7/5/3.jpg)
(http://images.eurogamer.net/assets/articles/a/5/4/4/7/5/1.jpg)
~Samuel
-
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.
-
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 :mad:.
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
-
:yes: :cool:
Keep it up, man! :D
-
you could play around with this (http://www.game-warden.com/nukemod-cos/downloads/cockpit test.rar)
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 (http://freespace.volitionwatch.com/blackwater/fs2_open_r_bobboau_1-15-08_rtt.zip) build for it to work. the usual rules about backing up your pilot files still strongly apply.
-
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 (http://www.moddb.com/games/6596/bsg-beyond-the-red-line/videos). 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?
-
That's pretty awesome right there. :D 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.
-
Yeah, you can use your joystick hat or any other definable key for looking in orthogonal directions. I also programmed in target padlock view (http://www.youtube.com/watch?v=4JgfzsUNm4E) 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.
-
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. :yes:
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.
-
Those are player options, IIRC, so the table ought to only specify the defaults by default.
-
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 alot 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.
-
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. :)
-
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
-
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.
-
You should probably try to base it on the stable branch if you can at this point. Recent developments in the SCP internal suggest that we may end up restarting the unstable branch due to how unstable it is, and selectively porting code over to the new one. Or something like that. But basically the plan is to have the stable be the starting point for the new new unstable.
-
You should probably try to base it on the stable branch if you can at this point
Thanks for the advice WMCoolmon, I will do that...
I've just completed porting HUDbrackets to CHUDBrackets, and after doing so I have a few questions. I think Backslash will be in the best positing to answer, but If anyone else can give some input it will be much appreciated.
In HUDBrackets, in the function hud_target_show_dist_on_bracket(int x, int y, float distance) there is a line:
displayed_distance = distance * Hud_unit_multiplier;
Now Hud_unit_multiplier is declared in hudparse.cpp, and not in
hudparse.h, and HUDbrackets includes neither of these files.
By what voodoo magic is this variable visible?
There is something even more curious in HUDbrackets, a function definition standing by itself:
int num_ships_attacking(int target_objnum);
but this function is again declared in AiCode.cpp, this time with an implementation.
In HUDbrackets in a function called draw_bounding_brackets
the function above is actually called in the line:
//Maybe show + for each additional fighter or bomber attacking target.
if ( (target_objnum != -1) && hud_gauge_active(HUD_ATTACKING_TARGET_COUNT) ) {
int num_attacking = num_ships_attacking(target_objnum);
}
Now, this line seems pointless because as far as I can see it is going to use the definition of num_ships_attacking that is defined in HUDbrackets, which as you can see has no implementation whatsoever.
Furthermore, it bothers me that AiCode.cpp does not have a header file? How is it ever used?
I hope someone can shed some light on these issues.
Many thanks
Samuel
P.S. The code seems to be littered with magic variables and functions like the ones I mentioned above. Is it perhaps an abuse of #includes?
-
You should probably try to base it on the stable branch if you can at this point
Thanks for the advice WMCoolmon, I will do that...
I've just completed porting HUDbrackets to CHUDBrackets, and after doing so I have a few questions. I think Backslash will be in the best positing to answer, but If anyone else can give some input it will be much appreciated.
In HUDBrackets, in the function hud_target_show_dist_on_bracket(int x, int y, float distance) there is a line:
displayed_distance = distance * Hud_unit_multiplier;
Now Hud_unit_multiplier is declared in hudparse.cpp, and not in
hudparse.h, and HUDbrackets includes neither of these files.
By what voodoo magic is this variable visible?
Hud_unit_multiplier is declared on line 352 or so of hudparse.h, and hudparse.h is included in hud.h, which is included in hudbrackets.cpp.
hudparse.h doesn't appear to be in the project file for MSVC2003 though, I can't speak for other versions. That means if you search "Entire Solution", hudparse.h isn't going to appear in any of the search results. It really ought to be added to the project.
There is something even more curious in HUDbrackets, a function definition standing by itself:
int num_ships_attacking(int target_objnum);
but this function is again declared in AiCode.cpp, this time with an implementation.
In HUDbrackets in a function called draw_bounding_brackets
the function above is actually called in the line:
//Maybe show + for each additional fighter or bomber attacking target.
if ( (target_objnum != -1) && hud_gauge_active(HUD_ATTACKING_TARGET_COUNT) ) {
int num_attacking = num_ships_attacking(target_objnum);
}
Now, this line seems pointless because as far as I can see it is going to use the definition of num_ships_attacking that is defined in HUDbrackets, which as you can see has no implementation whatsoever.
Er, what? As you pointed out, num_ships_attacking is only declared in hudbrackets.cpp, not defined, and it is defined in aicode.cpp. Function declarations can be for a function definition in a separate file; it's a major part of the C and C++ programming language.
Furthermore, it bothers me that AiCode.cpp does not have a header file? How is it ever used?
Most of the functions are declared in ai.h, IIRC.
I hope someone can shed some light on these issues.
Many thanks
Samuel
P.S. The code seems to be littered with magic variables and functions like the ones I mentioned above. Is it perhaps an abuse of #includes?
I can't answer that without being a little rude - all of your complaints about 'magic' seem to be the result of inexperience rather than due to abuse. The header files are definitely not really organized, but you should be able to find all of the functions in less than 30 seconds or however long it takes you to do a find for the entire solution. In this case I can see why that wouldn't work; but when I first read your post, you made it sound like you had searched hudparse.h specifically and couldn't find any declarations, which makes it sound like an out-of-sync-with-SVN error.
There's rarely any coding magic of this sort that's involved. If your declarations and definitions are mixed up, it generally means that either the compiler/linker is working with a different set of source code files than you are, or you have out-of-date intermediate files that are getting linked. But that only happens if you had a function and then changed it, and generally intermediate files will only cause a definition to appear or disappear; the compiler will complain about a lack of declaration when it tries to create the intermediate files. Deleting all the intermediate files and compiling with scratch, or compiling from a fresh checkout from SVN/CVS, will get rid of linker errors due to intermediate file mixups.
-
I can't answer that without being a little rude - all of your complaints about 'magic' seem to be the result of inexperience rather than due to abuse. (WMCoolmon)
You are totally right about my inexperience, and I will be a bit more careful of slinging terms such as voodoo and magic.
I am using the MSVC2003.
I don't see the point of declaring a function in a totally (conceptually) unrelated .cpp file such as HUDbrackets.cpp which is actually used in AiCode.cpp. In my opinion that is bad software design, even if the programming language technically allows for such a thing. Nevertheless, since it is done and I am inexperienced in C/C++ I don't want to argue the point.
Thanks for taking the time to respond. I don't find this insulting, but rather insightful since I learned something and that's the whole reason for why I want to get involved anyway.
~Samuel
-
I don't see the point of declaring a function in a totally (conceptually) unrelated .cpp file such as HUDbrackets.cpp which is actually used in AiCode.cpp. In my opinion that is bad software design, even if the programming language technically allows for such a thing. Nevertheless, since it is done and I am inexperienced in C/C++ I don't want to argue the point.
Er, that wasn't what I was trying to say. :)
Disorganized header files is bad software design, but things have a tendency to get that way unless someone makes a concerted effort to fix them. Things in the FSSCP are not that bad right now; there's roughly one header file per cpp file, and although some of the #includes could be more efficient and some of the functions could be declared better, they just aren't.
Abuse, at least to me, suggests something altogether different from disorganization due to inattention. Like having one header file per struct, or a header file for structs and one for functions, even if there's no compelling reason to do so and especially if there's only one member per struct or one function per header file. Or if you had a trail of six header files leading up to the one with the only function declarations. Something that's obviously going to a lot of extra effort just to shoot yourself in the foot.
-
Indeed... never attribute to malice that which can be explained by stupidity. Or laziness combined with snowballed complexity, in this case ;)
I think a lot of it has to do with how old some of this code is. (It's hard to believe it's already been 10 years since the game came out!) Back in the '90s a lot of 'proper' C++ style hadn't taken hold. The HUD in partcular is mostly just C, some of it "bad C" (at least, as I understand) and a lot of it was probably just recycled from Freespace 1.
I'm speaking as another programmer with not a lot of experience (yet), but I see lots of stuff in there that my computer science professors taught me not to do. There's even GOTOs, ffs! :eek2:
So yeah, it's high time for what you're doing and it'll make everything better. I'll do my best not to make your job harder with my changes :)
P.S. Just about done with the weapons gauge, and I've enhanced support for more than 4 primaries and secondaries, should we add support for that in the future elsewhere in the code! :yes:
-
first: awesome! this is way better than those other cockpitted ships!
second: it doesn't have to be symetrical in the outline shape. that way you could fit in more.
third: will this work in-game?
-
Dude, it already does. It just doesn't have any functionality at the moment other than having a (buggy) cockpit without needing -show_ship in the tables.
-
In case no one's already suggested this, maybe something similar to X-Plane, regarding how it works. Instead of having to make a full 3d cockpit each time, you could use a default or custom 2d panel and drag the instruments around, rotate them, scale them, etc. Even make your own bitmaps for the instruments. It would require a huge rewrite of the .pof file format, but it could work.
-
Not to mention a complete (re)rewrite of the interface code.
-
Not to mention a complete (re)rewrite of the interface code.
Yeah, that too. Maybe we can schedule it for FS2_open version 4 or 5 (or 6 or 7)? I'd try to help as much as I can, but I'd be new to the code, and I'm a novice programmer anyway. It would, of course have to have an option in the launcher to use the normal hud, in case you accidentally delete all of your hud/panel files. Or maybe just restore the default. Eh, whatever, it's not high on my priority list.
-
In case no one's already suggested this, maybe something similar to X-Plane, regarding how it works. Instead of having to make a full 3d cockpit each time, you could use a default or custom 2d panel and drag the instruments around, rotate them, scale them, etc. Even make your own bitmaps for the instruments. It would require a huge rewrite of the .pof file format, but it could work.
You don't need to rewrite the POF, you just need a file with a set of values. You could probably work it out with Lua right now, provided you used RTT with a render-to-polygon function that let you control all of those.
-
I'm speaking as another programmer with not a lot of experience (yet), but I see lots of stuff in there that my computer science professors taught me not to do. There's even GOTOs, ffs! :eek2:
There's a few situations where GOTO isn't terrible. In fact sometimes can actually make things cleaner (example, something fails, start over and try again).
-
I always use goto instead of loops.
j\k
-
P.S. Just about done with the weapons gauge, and I've enhanced support for more than 4 primaries and secondaries, should we add support for that in the future elsewhere in the code! :yes:
you know how long ive been hearing that. :D
so how many other pieces of code need to be reworked th have a virtually limitless and rather rediculous supply of guns. :D soon as those get tossed in il start working on a battletech mod :D
anyway what is the purpose of a .h file, what makes it different from a .c file. ive never been able to figure that out. i tend to just stick everything in a c file myself (or rather cpp cause i suck at c). i understand how to program fairly well but i havent a clue what the compiler is doing or how it really works.
-
anyway what is the purpose of a .h file, what makes it different from a .c file. ive never been able to figure that out. i tend to just stick everything in a c file myself (or rather cpp cause i suck at c). i understand how to program fairly well but i havent a clue what the compiler is doing or how it really works.
I tend to put things like classes, structs, and functions I'll use a lot in the header files, then just have the c files include them. What the compiler does when it encounters:
#include "file.h"
is it basically copies the contents of "file.h" into the C file it's compiling, at compile time. The stuff in the header file is not actually copied into the C file.
What a compiler does, or at least, what I'd design a compiler to do, is it takes the code and turns each item, a variable, function, etc., into a token. The tokens are then turned into assembler code or the hex equivalent. The hex is then turned into the binary ascii stuff that you see when you open an executable in a text editor. Then the computer reads the binary and follows its instructions. I could go into how a processor works, but I don't think you need that much info.
-
:D
//I thought this was a neat demo trick:
#include <iostream>
#define REPEAT do{
#define UNTIL( condition ) }while(!(condition));
using namespace std;
int main(int argc, char *argv[])
{
int count_Up = 0;
int count_Down = 12;
REPEAT
cout << "The value of count_Up adding to 12 =: " << count_Up << "\t Counts. " << endl;
cout << "With count_Down subtracting from 12 =: " << count_Down << "\t Counts. " << endl;
count_Up++;
count_Down--;
UNTIL(count_Up==12 || count_Down==0)
system("PAUSE");
return EXIT_SUCCESS;
}
-
Hey, I've been watching these forums for a while now, And I'd like to help. I'm not much in the way of a coder, but I do know a little of the basics. I don't really have any idea where to start though.
-
Target aquired! Lurker configuratoin!
FIRE ALL BEAMZ!
:welcomeblue:
-
The beam is blue now? And where is the obligatory orientation?
-
the beam is any color you want it to be now.
:welcomered:
:welcome:
see?
and goober doesn't like welcome speeches.
-
Hey, I've been watching these forums for a while now, And I'd like to help. I'm not much in the way of a coder, but I do know a little of the basics. I don't really have any idea where to start though.
A number of coders here actually learned to code by just practicing with the FS source, so that's probably a good way to start. I'd think tutorials and stuff would help too, but I'd suggest just trying to implement little things at first, and just get better and better. :)
-
Stupid and likely lazy question... I figured the answer is better here than searching every old link for an hour or so...
I have VS 2005 and wondered where I could download the most current source packages to check out.
It seems your using ANSI based code for the most part to insure cross platform compatibility.
I could be wrong based upon the .h files missing, for the most part I avoided use of them and never really made anything large enough that would prove the necessity was worth the confusion. Of course there may be significant speed advantages similiar to using vla rather than commands in AutoLisp system API's for AutoCAD.
-
Here. Use this (http://www.hard-light.net/forums/index.php/topic,52845.0.html) link.
-
Mucho Gracias Stormkeeper :D