Space Shuttle Ultra 1.25 Revision B development

Yes or any other joystick with a throttle control.

It would be just a bit hard getting the throttle to the current engine thrust level during manual take-over, at least from a user-interface view, since nobody has a Shuttle SBTC at home with the proper markings.
 
It would be just a bit hard getting the throttle to the current engine thrust level during manual take-over, at least from a user-interface view, since nobody has a Shuttle SBTC at home with the proper markings.
Well, it sill 0-100%. And the markings can be found in the Ascent C/L, CC 10-4.
 
It would be just a bit hard getting the throttle to the current engine thrust level during manual take-over, at least from a user-interface view, since nobody has a Shuttle SBTC at home with the proper markings.
Why not just have the user press the MAN PBI for manual take-over. I don't think it's practical to expect users to match the throttle position (especially if they don't have a joystick). The main issue I have with using the engine commands to control the speedbrake is that, unless you have a joystick, it makes controlling the speedbrake position during landing more cumbersome.
 
Why not just have the user press the MAN PBI for manual take-over. I don't think it's practical to expect users to match the throttle position (especially if they don't have a joystick). The main issue I have with using the engine commands to control the speedbrake is that, unless you have a joystick, it makes controlling the speedbrake position during landing more cumbersome.
Why? It wouldn't be much different from what we have now, which is 5% increments/decrements.

Only change would be that the speedbrake setting would be more realistic with throttling. It would also be more realistic in terms of behavior of Commanded vs Actual as the speedbrake can't go from 15% to 100% in a heartbeat.
 
Why? It wouldn't be much different from what we have now, which is 5% increments/decrements.

Only change would be that the speedbrake setting would be more realistic with throttling. It would also be more realistic in terms of behavior of Commanded vs Actual as the speedbrake can't go from 15% to 100% in a heartbeat.
Currently, the speedbrake is opened/closed in 5% increments using the , and . keys.
Do you want to use the Orbiter's engine control scheme (CTRL+ gradually closes the speedbrake, CTRL- gradually opens it, etc.), or just use + and - instead of , and .? The problem I have with using Orbiter's engine control is that it can be difficult for keyboard users to fly the shuttle and control the speedbrake at the same time. If all you want to do is change the keys that open/close the speedbrake in 5% increments, I don't have any objections.
 
Currently, the speedbrake is opened/closed in 5% increments using the , and . keys.
Do you want to use the Orbiter's engine control scheme (CTRL+ gradually closes the speedbrake, CTRL- gradually opens it, etc.), or just use + and - instead of , and .? The problem I have with using Orbiter's engine control is that it can be difficult for keyboard users to fly the shuttle and control the speedbrake at the same time. If all you want to do is change the keys that open/close the speedbrake in 5% increments, I don't have any objections.
What I am looking for is throttling of the speedbrake, just like the SSMEs. That is how the real speedbrake works.

And FYI: the speedbrake is nominally in AUTO. Same for the body flap, also AUTO. Only PITCH, ROLL/YAW is taken to CSS. So for those with problems handling everything at once during landing, they can just leave the speedbrake in AUTO and let the DAP figure out the speebrake setting.
 
What I am looking for is throttling of the speedbrake, just like the SSMEs. That is how the real speedbrake works.

And FYI: the speedbrake is nominally in AUTO. Same for the body flap, also AUTO. Only PITCH, ROLL/YAW is taken to CSS. So for those with problems handling everything at once during landing, they can just leave the speedbrake in AUTO and let the DAP figure out the speebrake setting.
As things stand, the DAP doesn't control the speedbrake well. I can add the engine throttling control, but I'll leave the old control method as well.
 
As things stand, the DAP doesn't control the speedbrake well. I can add the engine throttling control, but I'll leave the old control method as well.
Then the DAP needs to be tweaked. Could the HAC scenario be updated to be a bit ahead of HAC I/C?
 
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!
Should be fixed now.

The VAB project doesn't compile - meshres.h (and a couple of other files) is missing.
 
Should be fixed now.

The VAB project doesn't compile - meshres.h (and a couple of other files) is missing.
Both items confirmed. NWS is back and good.
 
here are the missing files in the quick version, so you can put them into the trunk of SVN, the server-side method takes too long.
 

Attachments

here are the missing files in the quick version, so you can put them into the trunk of SVN, the server-side method takes too long.
The files have now been checked in along with a corrected VC++2008 project file. It compiles fine now.

---------- Post added at 01:49 AM ---------- Previous post was at 01:15 AM ----------

Just wanted to inquire about the status of adapting GlideslopeMFD to a Entry DAP in SSU. That way we wouldn't be dependent on a external utility.
 
I haven't had time to look at Glideslope MFD yet (and it'll be a while before I can do anything with the entry DAP).

---------- Post added at 10:59 PM ---------- Previous post was at 10:47 PM ----------

Some files seem to be missing from the libUltra project as well.

---------- Post added at 11:10 PM ---------- Previous post was at 10:59 PM ----------

Also, commEA1.h seems to be missing (this is in the Atlantis project). EA1.h was recently added - is this the missing file?
 
[/COLOR]Also, commEA1.h seems to be missing (this is in the Atlantis project). EA1.h was recently added - is this the missing file?
Weird. All the projects compile fine for me.
 
It seems to be header files only that are missing, so it might still compile. I've been trying to update the VS2010 project files to match the VS2008 files, which is how I noticed the missing files.
 
Checked in Space Launch Complex 6(SLC-6) meshes and textures. Would be great if someone could code it up.

Edit:
You need to install Usonian's VandenbergAFB - 2006 add-on: [ame="http://www.orbithangar.com/searchid.php?ID=2380"]VandenbergAFB - 2006[/ame]
 
Last edited:
Checked a fixed SLC-6 Access Tower mesh that corrects the missing textures.
 
Updated the HAC Test scenario to just before HAC intercept. Vehicle is Columbia in the STS-107 configuration. Also fixed the retracted position of the Orbiter Access Arm of the SLC-6 Access Tower.

---------- Post added at 11:28 PM ---------- Previous post was at 10:24 PM ----------

Just checking here: Is anybody else besides me getting freezes when using 100x time acceleration? Doesn't matter if the vehicle is in launch or orbiter only config.
 
Back
Top