[ethaninja]

Hey folks, another newbie question from the NewbieNinja

I was wondering if it was possible or if anyone has attempted to do a 3D Cockpit mod?

Also, I know this is a bit more off topic.. well pretty much completely off topic, but does the glide control work? Or do I have to wait for a certain ship ?

[Angelus]

Hey folks, another newbie question from the NewbieNinja

I was wondering if it was possible or if anyone has attempted to do a 3D Cockpit mod?

Also, I know this is a bit more off topic.. well pretty much completely off topic, but does the glide control work? Or do I have to wait for a certain ship ?

You have to create a .tbm with these entries to enalble Glide in FSO:

http://www.hard-light.net/wiki/index.php/Ships.tbl#.24Glide:


Consult the Wiki on how to do that:

http://www.hard-light.net/wiki/index.php/Tables



You can enable cockpit view via table flag, but "usable" ( full Sim style ) cockpits are atm only via scripting possible.

[Scooby_Doo]

Hey folks, another newbie question from the NewbieNinja

I was wondering if it was possible or if anyone has attempted to do a 3D Cockpit mod?

Also, I know this is a bit more off topic.. well pretty much completely off topic, but does the glide control work? Or do I have to wait for a certain ship ?

You can enable cockpit view via table flag, but "usable" ( full Sim style ) cockpits are atm only via scripting possible.

Seperate model cockpits are doable without scripting.    The way I have to do them is have the ships hull and cockpit attached to a simple hidden-out-of-the-way box named detail0. and vola.  The cockpit hud controls however are still not operational 

[ethaninja]

Hey folks, another newbie question from the NewbieNinja

I was wondering if it was possible or if anyone has attempted to do a 3D Cockpit mod?

Also, I know this is a bit more off topic.. well pretty much completely off topic, but does the glide control work? Or do I have to wait for a certain ship ?

You can enable cockpit view via table flag, but "usable" ( full Sim style ) cockpits are atm only via scripting possible.

Seperate model cockpits are doable without scripting.    The way I have to do them is have the ships hull and cockpit attached to a simple hidden-out-of-the-way box named detail0. and vola.  The cockpit hud controls however are still not operational 

Oh wow is that a completed mod? If so, where can I get it?

[Getter Robo G]

There is no thing as a cockpit "mod", however some ships have had the "Terrain Cockpit" made by a community member added to the newer HTL models I believe.


For example, I have a cockpit I intend to use as a generic one for all (Robotech) ships, but I would need to alter it to clean it up, and fix a uv map error, as well as make it fit size wise to each individual fighter.

[actual_glue]

You know, didn't I read something about moving the elements of the HUD around to different locations?  I think it was scripting.  Can that be used to put them outside of the normal forward-facing view?  It seems like, if you can move it around like that, you can sort of cheat your displays over on top of a blank cockpit screens, and when you look around with target padlock, the displays will stay where they need to be.

In fact, I bet we (meaning I if I get the time, because I'm job hunting and because scripting takes me a while) can throw together a script to switch the HUD displays back and forth from their default positions to those cockpit screen locations.  There will be a few limitations until someone of greater coding prowess than I tackles the project, though.  Even if I get that to work, the displays will only work for a certain cockpit workout and they will always appear to directly facing the player's eye.

Thoughts?

[The E]

Yes, I have a thought. Instead of going down a route that will only cause headaches and result in utter failure, why not help us in getting the HUD rewrite done? Because THAT effort, unlike any of the lua workarounds, will be easier to get working in a fashion that does not completely destroy performance (which a scripting-driven render-to-target approach does).

[Swifty]

You know, didn't I read something about moving the elements of the HUD around to different locations?  I think it was scripting.  Can that be used to put them outside of the normal forward-facing view?  It seems like, if you can move it around like that, you can sort of cheat your displays over on top of a blank cockpit screens, and when you look around with target padlock, the displays will stay where they need to be.

In fact, I bet we (meaning I if I get the time, because I'm job hunting and because scripting takes me a while) can throw together a script to switch the HUD displays back and forth from their default positions to those cockpit screen locations.  There will be a few limitations until someone of greater coding prowess than I tackles the project, though.  Even if I get that to work, the displays will only work for a certain cockpit workout and they will always appear to directly facing the player's eye.

Thoughts?

Uh, yeah. The current code as it is can already do that right now. When I implemented TrackIR head tracking, I coded it so that the reticle gauges follow the nose vector of the player to indicate where his ship is flying relative to his viewpoint. The next version of Freespace Open will allow modders to choose which gauges follow and which gauges don't along with the ability to choose their positions around the screen.

But really, the solution you're describing is really half assed. People don't want a 2D screen aligned bitmap drawn over their gauge that doesn't occlude/shear/scale along with the player's viewpoint. However, the gauges would look awesome if rendered to the textures of the cockpit directly then rendered on the polygons of the cockpit...

That's something I'm also working on for the next version of FSO.

[ethaninja]

snip

Uh, yeah. The current code as it is can already do that right now. When I implemented TrackIR head tracking, I coded it so that the reticle gauges follow the nose vector of the player to indicate where his ship is flying relative to his viewpoint. The next version of Freespace Open will allow modders to choose which gauges follow and which gauges don't along with the ability to choose their positions around the screen.

But really, the solution you're describing is really half assed. People don't want a 2D screen aligned bitmap drawn over their gauge that doesn't occlude/shear/scale along with the player's viewpoint. However, the gauges would look awesome if rendered to the textures of the cockpit directly then rendered on the polygons of the cockpit...

That's something I'm also working on for the next version of FSO.

I thought the latest version was final? Or maybe I read it wrong? Probably did, knowing me

[The E]

It's final in the sense that it's the recommended stable build for now. Development continues as always.

[actual_glue]

...But really, the solution you're describing is really half assed. People don't want a 2D screen aligned bitmap drawn over their gauge that doesn't occlude/shear/scale along with the player's viewpoint. However, the gauges would look awesome if rendered to the textures of the cockpit directly then rendered on the polygons of the cockpit...

Yes, I have a thought. Instead of going down a route that will only cause headaches and result in utter failure, why not help us in getting the HUD rewrite done? Because THAT effort, unlike any of the lua workarounds, will be easier to get working in a fashion that does not completely destroy performance (which a scripting-driven render-to-target approach does).

Yikes.  Well, yeah, guys, it's half-assed and stuff, but it's not a perfect fix.  It would just be a temporary workaround.

I would be honored to help with the HUD rewrite, and I'll give it my best effort, but I'm not a great coder.

[Scooby_Doo]

BTW I finally got it uploaded to youtube

http://www.youtube.com/watch?v=cyCvMqBcXjc

[Nuke]

You know, didn't I read something about moving the elements of the HUD around to different locations?  I think it was scripting.  Can that be used to put them outside of the normal forward-facing view?  It seems like, if you can move it around like that, you can sort of cheat your displays over on top of a blank cockpit screens, and when you look around with target padlock, the displays will stay where they need to be.

In fact, I bet we (meaning I if I get the time, because I'm job hunting and because scripting takes me a while) can throw together a script to switch the HUD displays back and forth from their default positions to those cockpit screen locations.  There will be a few limitations until someone of greater coding prowess than I tackles the project, though.  Even if I get that to work, the displays will only work for a certain cockpit workout and they will always appear to directly facing the player's eye.

Thoughts?

Uh, yeah. The current code as it is can already do that right now. When I implemented TrackIR head tracking, I coded it so that the reticle gauges follow the nose vector of the player to indicate where his ship is flying relative to his viewpoint. The next version of Freespace Open will allow modders to choose which gauges follow and which gauges don't along with the ability to choose their positions around the screen.

But really, the solution you're describing is really half assed. People don't want a 2D screen aligned bitmap drawn over their gauge that doesn't occlude/shear/scale along with the player's viewpoint. However, the gauges would look awesome if rendered to the textures of the cockpit directly then rendered on the polygons of the cockpit...

That's something I'm also working on for the next version of FSO.

i have a theory about how to accomplish this.

first you would need a model with a cockpit and a hud screen (probibly transparent with its own texture, this will be replaced by an rtt trxture in the script), and a script. the script would need to know two things, the players view offset and oriantation (ship local), and also the for corner verts of the polygon (also ship local). you would also need a camera. this camera is placed at the players current viewpoint and with the same orientation (would be easier if there was a way to just gain access to the default camera with view tweaks applied). you would set the camera, after that you would figure out the fov to set the camera to based off the cameras distance to the hud polygon. if the player was looking square at it, then the view frustum must intersect the edges of the polygon. the fov this occurs at is the fov you use.  then you would set your render target to a dynamic texture. you would render the hud to it. you then unset target and camera. after all that you would have the script replace the hud polygon texture with the one the script generated. of course ive not tested this theory, but its something ive wanted to test for some time.

[TomJeffersonJones]

BTW I finally got it uploaded to youtube

http://www.youtube.com/watch?v=cyCvMqBcXjc

Scooby would it be possible to play the retail FS2 campaign with one of your 3d pits in a current FSO build?  I wouldn't mind the stand-in guage art or the fact that every ship had the same pit, - it would just be great to have some 3d-structure to complement the view slewing possible in recent builds, but not have to abuse one's eyes with the low-poly/texture 'showship' method.  

[Scooby_Doo]

I don't see why it couldn't be used a placeholder.