Space Shuttle Ultra 1.25 Revision B development

[DaveS]

It just deploys in little bit different way.

Yes. The dish now rotates to the Master Index Pulse(MIP) position which is the position where the avionics that controls the Ku band system reports the EL/AZ on panel A2 as 000/000.

 

[Poscik]

I'm just wondering if we can borrow some code from GlideslopeMFD. It calculates awesome reentry path for all bases in earth.cfg file. Also it provides DelAZ information and some de-orbit burn calculations. So Roll/Yaw autopilot could be connected to it and follow the path. Program to calculate De-Orbit burn could act as simple built-in MCC, and estimate TIG and targets.

 

[DaveS]

I'm just wondering if we can borrow some code from GlideslopeMFD. It calculates awesome reentry path for all bases in earth.cfg file. Also it provides DelAZ information and some de-orbit burn calculations. So Roll/Yaw autopilot could be connected to it and follow the path. Program to calculate De-Orbit burn could act as simple built-in MCC, and estimate TIG and targets.

I for one would love to see this implemented! Just a note though: After a bit of experimentation, I have determined that GlideslopeMFD only loads the bases that exists in the Earth\Base folder. This means that it isn't loading any data on bases that SSU exclusively makes use which exists in Earth\SSU.

 

[SiameseCat]

I for one would love to see this implemented! Just a note though: After a bit of experimentation, I have determined that GlideslopeMFD only loads the bases that exists in the Earth\Base folder. This means that it isn't loading any data on bases that SSU exclusively makes use which exists in Earth\SSU.

If we get permission to use the code, this should be easy to fix. I'll take a look at Glideslope MFD and see how useful this would be for an autopilot.

 

[DaveS]

If we get permission to use the code, this should be easy to fix. I'll take a look at Glideslope MFD and see how useful this would be for an autopilot.

Well, the code is licensed under LGPL just like SSU. And it is written by one of the Shuttle Deluxe/SSU founders, kwan.

 

[Poscik]

This is what I'm working on. It also has EDW all-range maps, rest of KSC maps, final approach to docking display and TORVA/TORFA display. A lot more are estimated to be coded. Here is reentry path I generated for my STS-96 mission. Scenario I used, starts at 52km altitude, which is beginning of the path. Overlay on short range map is also fixed now. Application gives ability to track reentry live. Green plot is just simulated plot, and yellow plot will be drawed during "official" reentry, just like NASA does on NASA TV!

Medium Range:

Short Range(fixed one):

 

[Urwumpe]

Did you include the difference between geocentric and geographic coordinates?

 

[Poscik]

Did you include the difference between geocentric and geographic coordinates?

No, I didn't. Where I can read about that difference?

[EDIT]
As I understood, orbiter uses geocentric?


[EDIT2]
I found an article about that, and I think such conversion is not needed, as I'm obtaining coordinates via GetEquPos();

 

[zerofay32]

Would those be used externally or in-sim? I know the crew uses PGSC's to display final approach to docking and TORVA/TORFA displays.

 

[Poscik]

It is completely external tool for future mission control. Written in WinAPI GDI.

 

[STS]

It is completely external tool for future mission control. Written in WinAPI GDI.

Marvelous

 

[Poscik]

I partially fixed path drawing. But it is very no-professional. I checked data for SLF33:
Scenario editor returns -80.683200 28.597884 where GetEquPos() returns -80.724124 28.612389

So, such big difference given by GetEquPos() is because GetEquPos() considers Earth as sphere? If yes, how Scenario Editor calculate correct position?

And fixed drawing (I failed a little in HAC )

 

[Donamy]

looks close enough fo government work.:thumbup:

 

[DaveS]

Checked in a Orbiter Transporter System(OTS) mesh+texture for any one to get up and running.

 

[DaveS]

Would be possible to tie the speedbrake control to the main engine thrust keys? They're after all control by the same lever in the real orbiter, so it feels a bit odd having two different key sets in SSU.

 

[Urwumpe]

Would be possible to tie the speedbrake control to the main engine thrust keys? They're after all control by the same lever in the real orbiter, so it feels a bit odd having two different key sets in SSU.

Likely yes. But I can't tell you if the throttle behavior can be done as in the real one.

 

[DaveS]

Likely yes. But I can't tell you if the throttle behavior can be done as in the real one.

Can't we settle for close?
Seems like there's a bug: The steeringforce code in AerojetDAP.cpp doesn't work. I have tried altering it for improved NWS behavior, but it doesn't have any effect when recompiled. Currently it acts like we do not have any NWS at all!

 

[SiameseCat]

Would be possible to tie the speedbrake control to the main engine thrust keys? They're after all control by the same lever in the real orbiter, so it feels a bit odd having two different key sets in SSU.

We could, but I don't think it would be a good idea. When you're landing, being able to open and close the speedbrakes by pressing only one key (instead of holding down two keys) is fairly helpful, I think.

 

[DaveS]

We could, but I don't think it would be a good idea. When you're landing, being able to open and close the speedbrakes by pressing only one key (instead of holding down two keys) is fairly helpful, I think.

How about throttling it instead or just increasing it in 5% increments? That would be more realistic.

 

[Donamy]

As in something like a CH Throttle ?