News The Space Shuttle for Flightgear 3.6

[JMW]

Does FlightGear operate on Windows 10 ?............

 

[Thorsten]

hint/picture number:
a/4
b/2
c/1
d/5
e/3

For the record, I cross-posted this over at the FG forum, and so far no one gave it a try :-/

Just an inefficient burn would mean diverging FU/OX IN values.

I pull my hat to you, Sir! I realized I had made a mistake here after posting this yesterday, and you're quite correct of course.

Does FlightGear operate on Windows 10 ?

Should... I don't use Win 10 myself, so I don't have first-hand experience, but I can't recall any disastrous user reports. If it makes trouble out of the box, usually someone manages to address the problem latest a few weeks later. Also, we have a build server which produces nightly Win and Mac images of the lastest development snapshots, so a fix is quickly available.

 

[JMW]

Problem:
Windows 10
Unable to locate FlightGear executable - not in FlightGear folder....?
C:/Program Files/FlightGear 3.4.0/
Path to data is fine. C:/Program Files/FlightGear 3.4.0/data

Any help appreciated...

 

[Thorsten]

Hard to guess at the problem with so little information and not knowing much on the Win setup myself. It sounds like an error from the launcher.

I guess if you're using the launcher (FGRun) you have to tell it where the executable (fgfs.exe) is - on the first page there should be file path menu items.

At some point the idea seemed to be to phase out the launcher (I know for Mac this has been done) and add the functionality directly to the executable - I don't know whether this has been done for Win already for 3.6.

 

[JMW]

Problem resolved - found fgfs.exe
FGRun not recognizing it but runs from shortcut.
Thanks again.

 

[Scav]

. . . rather suggests a catastrophic failure of the injector milliseconds away from LOCV . . .

TL;DR: You can be puttering along in space and not even realize your day has just ended horribly wrong. :shifty:

 

[Urwumpe]

TL;DR: You can be puttering along in space and not even realize your day has just ended horribly wrong. :shifty:

What's that last thing that crosses the mind of a Shuttle astronaut?




The HPOTP.

 

[GLS]

What's that last thing that crosses the mind of a Shuttle astronaut?




The HPOTP.

:lol:



I'm going to hell :facepalm:

 

[Thorsten]

Some work on visualizing the more drastic failure modes.

This is the failure of the ET - if the Shuttle violates structural limits during ascent, I suspect debris might potentially rip the ET open. Or there's the Challenger scenario.

ET goes in a bright explosion:

The SRBs and the wreckage of the Shuttle (the pressure vessel of Challenger actually survived more or less in one piece) get a wild kick from the explosion, the SRBs continue to burn till their fuel is expended, the OV just continues on a ballistic trajectory:

And here's TPS failure - Shuttle fuselage weakens and breaks up...

... to enter the atmosphere in a slowly separating debris shower:

 

[Thorsten]

Current state of the 3d cockpit works - the first pushbuttons and switches are animated, the forward keyboard units work:

Close-up on the MDUs - the whole selection logic between MEDS and DPS is in place, MDUs are hooked up to given IDPs, they query the GPC array for what major functions are available and respond to the switch commands by changing displays,...

(I think that's OPS 201, SPEC 20 and SM SYS SUMM 2 visible there)

Instrument backlighting at night, casting a soft glow onto the interior cockpit surfaces:

 

[Urwumpe]

Close-up on the MDUs - the whole selection logic between MEDS and DPS is in place, MDUs are hooked up to given IDPs, they query the GPC array for what major functions are available and respond to the switch commands by changing displays,...

(I think that's OPS 201, SPEC 20 and SM SYS SUMM 2 visible there)

Yes, and some kind of a PFD display. The DPS screens miss the IDP number and the coloured bar for the controlling keyboard. Also, you actually can't display DPS on a MFD MDU (the lower two displays in the center) in reality, since the DPS displays are dedicated to the CRT MDUs - unless something fails or astronauts disconnect the only used port of a CRT MDU from the IDP, the IDP would always paint its DPS screen on a CRT MDU. (CRT MDUs use only their primary port, while all others use both primary and secondary port ... that configuration avoided reprogramming most of the FCOS)

And also all displays are driven by the same GPC 1... the FCOS operating system can only handle two displays/IDPs at a time per GPC because of memory and performance issues. Its similar for the BFS.

But that's my TODO list in SSU as well right now. :rofl:

 

[Thorsten]

Yes, and some kind of a PFD display.

It's a template for the actual PFD. The MEDS designs aren't done yet, so it's for testing edge-key switching vs. keypad switching.

And also all displays are driven by the same GPC 1... the FCOS operating system can only handle two displays/IDPs at a time per GPC because of memory and performance issues. Its similar for the BFS.

Well spotted... and easy to fix, the sim already knows what drives what, just the display doesn't show it yet (it is of course always true that the same GPC can't run SM and GNC at the same time...)

Also, you actually can't display DPS on a MFD MDU (the lower two displays in the center) in reality, since the DPS displays are dedicated to the CRT MDUs

Actually, I think you can (at least I didn't find any statement to the contrary anywhere) - 2-6.27 shows DPS assigned to CRT1-3 as typical layout, not as a must. According to 2.6-16 on the manual, MFD listens to the primary port 2 and secondary port 3, so unless I misunderstand something quite drastically it would show the same as CRT 2 if I select DPS via the edge-key selection and don't switch to secondary port.

 

[Urwumpe]

Actually, I think you can (at least I didn't find any statement to the contrary anywhere) - 2-6.27 shows DPS assigned to CRT1-3 as typical layout, not as a must. According to 2.6-16 on the manual, MFD listens to the primary port 2 and secondary port 3, so unless I misunderstand something quite drastically it would show the same as CRT 2 if I select DPS via the edge-key selection and don't switch to secondary port.

What I mean is for example on page 2-6.31f, the automatic port configuration vs alternate port configuration. Or on page 2-6.15 about the port assignments.

MFD1 could for example only display display data of IDP 2 or IDP 3, but which IDP it has can only be selected by manual port configuration.

The Crew software interface training manual states that any MDU that displays DPS from IDP3 is called "CRT3", so it should be possible. But as I understand it from the SCOM description of the IDP and MDU software, this is not possible without the usual CRT3 failing first so that the IDP allows switching the MFD1 to CRT3.

 

[Thorsten]

2.6-31: CRT MDUs show the DPS (CRT) display. In general the CDR and PLT MDUs display the flight instruments while the MFD MDUs display the subsystem displays.

2.6-32: The user can select alternative ports by navigating through the MEDS edgekey menus to either the subsystem menu or the MEDS meintenance menu.

2.6-15: Operationally the CRT MDUs are dedicated to the DPS display.

2.6-27: (explaining the MEDS menu items): The MEDS DPS display shows the DPS displays to the crew

I think it's fairly clear that assigning DPS to the CRT displays, flight instruments to the CDR and systems management to MDU is an operational procedure, not a hardware requirement, and as such can be changed at the simple expense of selecting menu items.

It's also fairly clear that ports can be switched at the simple expense of selecting the appropriate items in the MEDS maintenance menu.

I agree that one usually wouldn't configure the Shuttle's displays the way shown in the screenshots, but I'm actually not interested in hard-coding operational procedures in the sim - if the user operates a system off-nominally, I just want to simulate realistic (well, maybe rather plausible) consequences.

I'm not forcing anyone to use all three APUs upon entry, but then the airfoil response will be priority rate limited. I have no hard coded requirement to keep the avionics bay cooling on, but the bay temperatures will increase over time to the failure temperature of the computers and you'll end up without them. I'm not requiring to do an MPS propellant dump, but then CoG will be off during entry and the Shuttle will lose control and burn (I've done it by accident once - it was instructive...)

So I think it's a feature to be able to configure screens in an off-nominal assignment, not a bug.

 

[Urwumpe]

Well, I am right now about 85% sure, that the IDP can not provide display rendering data to more than one DPS MDU at a time, but I would not refuse information contradicting this.

As said, I a just 85% sure about what the DEU emulation in the IDP can do or not. It is a lot more than what the DEU can, but the old 80386SX CPU in it ain't sure not the fastest processor in comparison. Especially if it is also used for painting complete North Atlantic maps with a single instruction.

 

[Thorsten]

Lots of work on the unglamorous task of wiring the Shuttle up internally, connecting systems to their power sources, making the fuel cell simulation better... I doubt the casual user will ever realize much, but there are always those who enjoy such details...

Here's FC1 in need of a purge - the power load isn't higher than for FC 2 and 3, but the voltage has started to drop, indicating deteriorating efficiency.

Purge initiated (we should not have done this...) and the reactant flow is increased as a result, voltage starts rising as the efficiency increases again:

As the purge line has not been heated properly, the line starts to freeze up and the reactant flow decreases irregularly before the purge is completed and the valve closed:

This is how it should have looked with the purge line heater operated in advance:

The electrical system is pretty neat - the voltages respond to the fuel cell condition and to the power load of all that's currently on (at least in the cases where I could find out what hangs on what bus and what power consumption it has...), one can shorten any component and observe the resulting drop in bus voltage below operational (which trips off the C/W alarms), tie buses to share load or compensate for non-operational fuel cells,

The fuel cells are properly hooked up to the freon loop - if the freon loop is out or doesn't have heat rejection available, they'll overheat (and ultimately fail), likewise if their coolant pumps are damaged same thing happens...

I guess you'll have to click on the two-screen shots to see the details, they show fuel cells and electric power distribution DPS pages side by side:

That's normal operations with the same load hanging on every bus, current power consumption about 14.6 kW, fuel cell stack temperatures around 200.

That's a config with FC 1 (damaged) shut down and saved, and MN a and B buses tied to continue power supply, so FC 2 has a pretty high load and correspondingly low voltage, high stack temperature and reactant consumption. There's less power used on AC 1 than on AC 2 and 3 because the hydrogen and coolant pumps of FC 1 hang on that bus.

I imagine the experience would be quite neat when used via an instructor station (FG has its own webserver, so you can connect via http from an external device and control a craft - or set the various failure modes and watch the trainee's response to the sudden probem...) Simulating failures via scenarios is also okay, but you always sort of know what to expect then...

---------- Post added at 07:42 AM ---------- Previous post was at 07:33 AM ----------

Well, I am right now about 85% sure, that the IDP can not provide display rendering data to more than one DPS MDU at a time, but I would not refuse information contradicting this.

I haven't come across information either way, sorry. We can agree that it's operationally not done the way shown, I'm fairly certain it is possible to make MFD 1 show a DPS page if so desired, though that may mean other displays have to show something else.

Afterthought:

The question may be to some degree moot, because I can't see a way to command an IDP to show two different DPS pages at the same time. So we're not asking whether an IDP can provide DPS screens to two MDUs, we're asking whether it can forward the same data to more than one screen.

I have no idea how the technicalities back then were called, but I do know modern 3d rendering rather well, and there you'd be asking for a copy of the framebuffer to be sent to a second display. Compared with the task of assembling the framebuffer, the workload is pretty much zero - i.e. you don't need much computational power to make two displays show the same screen rather than one.

So an IDP never needs to provide rendering data for more than one screen, the question is whether it can hand copies of that screen to more than one MDU. I don't know whether this is implemented in reality, but it would be technically easy to accomplish at hardly any additional computational cost.

 

[Thorsten]

Okay, I guess watching numbers on the systems displays change in response to situations doesn't get everyone excited.

So here's some more visual update as well: I've added a decent simulation of Aurora Borealis to the FG base code - this is dynamically changing over time (it's procedural GLSL code, not a texture) and knows quite some auroral arc physics - the ionization colors and the de-excitation times (the average time from a collision till light is emitted is about 1 s for the green part but ~ 100 s for the red part, that's why the green part of the aurora is always more structured than the red, because there's lots of time for diffusion to blur the arc). Gives something to see during the night portion of the orbit.

The shots might be a little tricky to see on the bright forum background, but they come out nicely in fullscreen.

And a more normal one, passing over the Caspian sea...

 

[Urwumpe]

So an IDP never needs to provide rendering data for more than one screen, the question is whether it can hand copies of that screen to more than one MDU. I don't know whether this is implemented in reality, but it would be technically easy to accomplish at hardly any additional computational cost.

Should be possible, if the data is already converted and in a buffer. But then, it sure is not really useful to have exactly the same display by the same GPC twice...

 

[Thorsten]

But then, it sure is not really useful to have exactly the same display by the same GPC twice...

Not as such, no. Well, you could duplicate info on CDR1 and PLT2 if you really want - if you're sitting in either seat, the other display is sort of far away.

 

[Urwumpe]

Not as such, no. Well, you could duplicate info on CDR1 and PLT2 if you really want - if you're sitting in either seat, the other display is sort of far away.

Not sure if it makes sense that way. Alone because before you would need this, the five center displays would have to fail first.

But the idea with the Auroras is nice, I wonder if a rendering client for Orbiter could also do that.