Interceptor
Well-known member
Hi Thorsten,I would love to check this out,is there some link you could post to show how to install this?do I need to install flight gear first,or is this mod stand alone?Thanks
News The Space Shuttle for Flightgear 3.6
- Thread starter Thorsten
- Start date
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
You need to install FG first
http://www.flightgear.org/download/
(pick your OS - we're multi-platform)
FG offers support for simple download of aircraft via the launcher these days - so if you wait till after the new release (in some two weeks from now), the Shuttle will be conveniently available via that as we're planning to update the official version from our devel repo till then.
Otherwise you can get an (oversized) tarball of the last devel state from
http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball
(it's oversized because the devel repository contains the artwork sources - which a user really doesn't need...)
Hires Earth textures we have not (yet) dared to push to the default repo - links are here
http://wiki.flightgear.org/Earthview
And that should be pretty much it (we don't believe much in addons... usually things just get merged into mainline if they're useful) - so there's nothing you need to add for city lights, the aurora or so. Also low altitude terrain download is automatic at the simple expense of just enabling the option.
Bring a good computer... Shuttle is probably the most detailed craft FG ships...
http://www.flightgear.org/download/
(pick your OS - we're multi-platform)
FG offers support for simple download of aircraft via the launcher these days - so if you wait till after the new release (in some two weeks from now), the Shuttle will be conveniently available via that as we're planning to update the official version from our devel repo till then.
Otherwise you can get an (oversized) tarball of the last devel state from
http://sourceforge.net/p/fgspaceshuttledev/code/ci/development/tarball
(it's oversized because the devel repository contains the artwork sources - which a user really doesn't need...)
Hires Earth textures we have not (yet) dared to push to the default repo - links are here
http://wiki.flightgear.org/Earthview
And that should be pretty much it (we don't believe much in addons... usually things just get merged into mainline if they're useful) - so there's nothing you need to add for city lights, the aurora or so. Also low altitude terrain download is automatic at the simple expense of just enabling the option.
Bring a good computer... Shuttle is probably the most detailed craft FG ships...
Last edited:
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
You mean the exterior 3d mesh? There's nothing special about it - it's definitely not a 2 million poly kickass mesh with mm-sized details. It looks acceptable from most outside views and you don't usually get to see it from outside much when flying - so for the purpose of immersion into the sim, the flightdeck is much much more important - the focus of the devel team is really not on the exterior mesh at the moment.
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
Somewhat to my surprise, the work on the avionics is actually drawing to a close, and with SM DISP 88 (thermal management for freon loops, water loops and APU) the list of DPS pages that can be reasonably supported is implemented (not with all options fully supported, mind, just 70% or so - but the layout of all these exists).
As a result we're gradually shifting attention to the rest of the flightdeck with getting all panels textured and switches animated. Texturing is progressing rather faster:
So far only the OMS and RCS propellant flow switches and the valve talkbacks are fully implemented on the overhead panels.
They can be used to set up all supported crossfeeds, or to extinguish thrusters failed ON by closing their manifold off (they can be later edited from the jet table in the software).
As there's LOTS of switches (not counting the circuit breakers for which only very limited support is planned), this will still take a while to finish...
As a result we're gradually shifting attention to the rest of the flightdeck with getting all panels textured and switches animated. Texturing is progressing rather faster:
So far only the OMS and RCS propellant flow switches and the valve talkbacks are fully implemented on the overhead panels.
They can be used to set up all supported crossfeeds, or to extinguish thrusters failed ON by closing their manifold off (they can be later edited from the jet table in the software).
As there's LOTS of switches (not counting the circuit breakers for which only very limited support is planned), this will still take a while to finish...
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
Been side-tracked with an interesting (though overall rather irrelevant) math problem - how to give the drag chute the organic look of some flexible cloth fluttering in the wind rather than a hard 3d mesh. The idea is to apply suitable time and situation dependent displacement function in the vertex shader to get the required smooth deformations. It's not perfect yet, but I think even the current proof of concept stage is kind of cool:
Drag chute under high load:
Under reduced load, diameter widens:
Just after release, diameter widens to near full, chute goes into a wobble as it is no longer pulled into shape...
... and starts to flutter around wildly as it moves away:
---------- Post added 12-07-16 at 07:53 AM ---------- Previous post was 12-06-16 at 05:53 PM ----------
For anyone who wants to give the recent milestone 7 a try but isn't so much into reading 1000+ pages of SCOM - the Flight Manuals with easy tutorials and simulation-specific reference materials are now available:
(click me)
Drag chute under high load:
Under reduced load, diameter widens:
Just after release, diameter widens to near full, chute goes into a wobble as it is no longer pulled into shape...
... and starts to flutter around wildly as it moves away:
---------- Post added 12-07-16 at 07:53 AM ---------- Previous post was 12-06-16 at 05:53 PM ----------
For anyone who wants to give the recent milestone 7 a try but isn't so much into reading 1000+ pages of SCOM - the Flight Manuals with easy tutorials and simulation-specific reference materials are now available:
(click me)
Last edited:
Notebook
Addon Developer
- Joined
- Nov 20, 2007
- Messages
- 11,825
- Reaction score
- 644
- Points
- 188
Not just a different page, different book!
Your link above works fine(didn't know grey-elves were into Flight-Gear?). The .png link in #127 above just shows the graphic to me, clicking on it does nothing?
N.
Your link above works fine(didn't know grey-elves were into Flight-Gear?). The .png link in #127 above just shows the graphic to me, clicking on it does nothing?
N.
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
Different browser/forum software interaction I guess... (?) Anyway, thanks for the clarification, to be on the safe side I've made the text above also clickable.
As they say, correlation isn't causation
I'm both into Elvish and Flightgear (among a couple of other things)...
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
HUD test with the symbology during the TAEM phase into KSC
... and a gorgeous evening sky after touchdown!
---------- Post added 12-20-16 at 10:14 AM ---------- Previous post was 12-19-16 at 03:51 PM ----------
Bad state vector on approach...
(it's actually something that happens for the real Shuttle and can be seen in YouTube videos of Shuttle landings)
---------- Post added 12-21-16 at 08:57 AM ---------- Previous post was 12-20-16 at 10:14 AM ----------
... and some liberal application of GLSL magic to make it all look that there's actually light projected onto a glass surface
Sun glare brings out the faint glass scratches through light forward scattering:
... and a gorgeous evening sky after touchdown!
---------- Post added 12-20-16 at 10:14 AM ---------- Previous post was 12-19-16 at 03:51 PM ----------
Bad state vector on approach...
(it's actually something that happens for the real Shuttle and can be seen in YouTube videos of Shuttle landings)
---------- Post added 12-21-16 at 08:57 AM ---------- Previous post was 12-20-16 at 10:14 AM ----------
... and some liberal application of GLSL magic to make it all look that there's actually light projected onto a glass surface
Sun glare brings out the faint glass scratches through light forward scattering:
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
I'm slowly but gradually hammering area nav into shape. I have now modeled three independent TACAN receivers all with their characteristics, and they all show different bearing and distance to the beacon based on that.
The software then either merges them into a composite signal to cancel errors, or, if one of them (as in the example TAC2) deviates from the other two beyond tolerances, it gets voted out as faulty and the composite signal is only created by the other two.
Alternatively, it is possible to manually de-select any of the three data streams (or switch off the receiver). If all three differ from each other by equal amounts, they're marked as being in a dilemma and the crew must make a selection which one to use manually.
The resulting TACAN composite information is then used to constrain state vector drift as maintained by the IMUs, taking into account the distance-dependence of the expected accuracy of TACAN transmitters.
If the selected receivers happen to be the faulty ones of course, that means the state vector is driven off by incorporating the TACAN data...
Since that's possibly a handful to deal with for the casual user, I guess I'll just add one detail level to the simulation of navigation, then we have
1) perfect - the state vector known to GNC always is simulated truth
2) perfect instruments - the state vector drifts unless constrained by the navigation instruments, but the instruments always work
3) realistic - instruments may experience faults and simply show wrong and the crew needs to deal with this
The software then either merges them into a composite signal to cancel errors, or, if one of them (as in the example TAC2) deviates from the other two beyond tolerances, it gets voted out as faulty and the composite signal is only created by the other two.
Alternatively, it is possible to manually de-select any of the three data streams (or switch off the receiver). If all three differ from each other by equal amounts, they're marked as being in a dilemma and the crew must make a selection which one to use manually.
The resulting TACAN composite information is then used to constrain state vector drift as maintained by the IMUs, taking into account the distance-dependence of the expected accuracy of TACAN transmitters.
If the selected receivers happen to be the faulty ones of course, that means the state vector is driven off by incorporating the TACAN data...
Since that's possibly a handful to deal with for the casual user, I guess I'll just add one detail level to the simulation of navigation, then we have
1) perfect - the state vector known to GNC always is simulated truth
2) perfect instruments - the state vector drifts unless constrained by the navigation instruments, but the instruments always work
3) realistic - instruments may experience faults and simply show wrong and the crew needs to deal with this
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
I've been playing through some of the scenarios described in the Navigation Aids Workbook (USA006055) and this is actually pretty instructive. I've tried
* good TACAN signal merged into a good state vector
* good TACAN forced in updating a bad state vector
* one bad TACAN signal forced into the navigation leading the orbiter astray
* GPS update of a bad state vector as one time shot
* bad TACAN signal recognized on account of disagreeing with state vector and disagreements among receivers
If you're really into some of the details of how radio navigation works when it's not perfect, you can learn a lot setting something up and work through it by the book.
* good TACAN signal merged into a good state vector
* good TACAN forced in updating a bad state vector
* one bad TACAN signal forced into the navigation leading the orbiter astray
* GPS update of a bad state vector as one time shot
* bad TACAN signal recognized on account of disagreeing with state vector and disagreements among receivers
If you're really into some of the details of how radio navigation works when it's not perfect, you can learn a lot setting something up and work through it by the book.
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
3d and texturing work on the rear flightdeck is progressing nicely:
As of today, there's more than 60 different switches, dials and talkbacks animated and supported in the picture you see - S-band and Ku-band antenna controls, OMS, RCS and APU heating elements, the GPS power and preamp, the various lights of the rear cockpit and the RMS arm deploy and control elements.
As of today, there's more than 60 different switches, dials and talkbacks animated and supported in the picture you see - S-band and Ku-band antenna controls, OMS, RCS and APU heating elements, the GPS power and preamp, the various lights of the rear cockpit and the RMS arm deploy and control elements.
Thorsten
Active member
- Joined
- Dec 7, 2013
- Messages
- 785
- Reaction score
- 56
- Points
- 43
I've sort of managed to bring another pet project of a close - the simulation of the antenna systems.
The Ku-antenna now implements the GPC and manual target acquisition modes. If the Shuttle has attitude errors, the GPC pointing will target the corresponding wrong location and will not achieve a lock - you then have to search around the location, yet once there is a lock, the antenna can follow.
The connection between GPC and antenna can be severed, then no automatic pointing works, it all has to be done by hand, but AUTO TRACK can still follow a target once acquired.
There's also various ways in which the antenna can be damaged (and it can ultimately be jettisoned by a pyro charge if it refuses to move, then you see it floating off).
The two S-band antennas are done on a similar level, through the pointing problem is of course not there.
I just love to put in all these details - I'm ready to admit they don't serve much use unless you really want to train for massive systems failures - but it makes a difference to me knowing it's all done properly.
The Ku-antenna now implements the GPC and manual target acquisition modes. If the Shuttle has attitude errors, the GPC pointing will target the corresponding wrong location and will not achieve a lock - you then have to search around the location, yet once there is a lock, the antenna can follow.
The connection between GPC and antenna can be severed, then no automatic pointing works, it all has to be done by hand, but AUTO TRACK can still follow a target once acquired.
There's also various ways in which the antenna can be damaged (and it can ultimately be jettisoned by a pyro charge if it refuses to move, then you see it floating off).
The two S-band antennas are done on a similar level, through the pointing problem is of course not there.
I just love to put in all these details - I'm ready to admit they don't serve much use unless you really want to train for massive systems failures - but it makes a difference to me knowing it's all done properly.
Similar threads
