Project Space Shuttle Vessel
- Thread starter GLS
- Start date
After tweaking the SSV to fit accurately on the LC39 pad by hutchinson / DaveS, I finally discovered that the SSV won't launch 
The LCC won't connect to it, and won't be able to issue the automated launch commands.
I'll be in the bathub crying in fetal position
The LCC won't connect to it, and won't be able to issue the automated launch commands.I'll be in the bathub crying in fetal position
the LCC, pad and all has their own code to launch the Shuttle. Even is needed to be at the KSC or Vanderberg, I tried to place SLC-6 at Kourou in French Guyana, it didn't workAfter tweaking the SSV to fit accurately on the LC39 pad by hutchinson / DaveS, I finally discovered that the SSV won't launch
I'll be in the bathub crying in fetal position
View attachment 34578
I wonder if we edit the textures and save them as transparent (1x1 pixel even), would it make the vessel transparent ? It's a method we use in X-Plane to hide object wich still need to be present so we can place other objects instead at the same location.
That way you could place the HD LC39 and still have the default SSV LC39 working in background.
Last edited:
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 37,681
- Reaction score
- 2,407
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
the LCC, pad and all has their own code to launch the Shuttle. Even is needed to be at the KSC or Vanderberg, I tried to place SLC-6 at Kourou in French Guyana, it didn't work
Its pretty much hard coded by heritage, it COULD launch elsewhere with special guidance software constants (ILOADS).
GLS
Well-known member
Release Tuesday!!! 
This one took a while, but it is finally here!
The SPDS is of course the major addition, but there was also some bug fixing, namely the ODS mesh visibility.
About the SPDS, I have no idea what the colors would be, so I'm sure I got them wrong, but nobody can prove it.
Payload re-stow isn't implemented... it would take a bit more time to work the logic and as there are no failures, it can wait.
If you have any questions about the SPDS, please ask and I'll answer what I know, and probably add more info to the manual about this little known device.
Main work now switches to v2.0, but before that gets out, expect a "stop-gap" v1.9 with small improvements and features.
This one took a while, but it is finally here!
The SPDS is of course the major addition, but there was also some bug fixing, namely the ODS mesh visibility.
About the SPDS, I have no idea what the colors would be, so I'm sure I got them wrong, but nobody can prove it.
Payload re-stow isn't implemented... it would take a bit more time to work the logic and as there are no failures, it can wait.
If you have any questions about the SPDS, please ask and I'll answer what I know, and probably add more info to the manual about this little known device.
Main work now switches to v2.0, but before that gets out, expect a "stop-gap" v1.9 with small improvements and features.
GLS
Well-known member
Currently it will feature new OMS/RCS (plus the OMS Kit), and tied to that probably some more features in orbit attitude control.
Then I started to work on a small improvement to the GPC-IDP interface. It quickly went supernova and is now a complete rework of the data flow for the Dedicated Displays.
The displays themselves will look pretty much the same (maybe 1 or 2 new things), but the data sources will be much more correct, i.e., the correct software module will produce them, and with the correct accuracy. It will, e.g., (eventually) allow the ADI to work properly, with the 3 options of attitude reference, without (more) hacking, as the ADI data source will now be in the GPC and not in the MDU. It also opens the door for the original MCDS flight deck, as the data will now come out of the GPCs in the correct format. Still, initially there will be lots of data missing, as the source (and subsystem) modules are implemented yet (IMU, ADTA, TACAN, etc), but IMO it is a good foundation for new things in the future. Plus, the IDP-MDU interface should also move forward, with the MDU becoming very dependent on the IDP. I've also reworked the MDU mesh, so the power switches are now animated.Both of these areas will take lots and lots of work, so don't expect v2.0 this year.
Question: Could be SPEC105 TCS CONTROL be implemented for post-landing SSME REPO and VENT DOOR PURGE POSITIONING procedures? That is part of GNC9. Feels a bit empty leaving the speedbrake open and the SSMEs in their entry positions.
Last edited:
GLS
Well-known member
Eventually, but not in the near future...
GLS
Well-known member
Hi!
I can't read the message... too much desktop, too little error message.
kuddel
Donator
- Joined
- Apr 1, 2008
- Messages
- 2,065
- Reaction score
- 508
- Points
- 113
Classic dot vs. comma decimal separator issue?
French (as german as well) uses comma as decimal separator, not a dot. This might be the issue.
From experiance: Try to avoid (or set to "C-Standard" or something like this) locales when exporting or importing from files.
French (as german as well) uses comma as decimal separator, not a dot. This might be the issue.
From experiance: Try to avoid (or set to "C-Standard" or something like this) locales when exporting or importing from files.
GLS
Well-known member
Very likely, but I haven't had the time to check as I'm neck-deep in ADI rotation matrices (and not having much luck
).
GLS
Well-known member
First, get Shuttle FDO MFD by @indy91: https://www.orbiter-forum.com/threads/shuttle-fdo-mfd.36912/
It handles both the ground-calculated burns (the early, usually large burns) and also the onboard-calculated burns (the ones on the day of the rendezvous).
SSV (again, thanks to @indy91) also does the onboard calculations, just like the real Shuttle did, and you can try the final burns of the rendezvous using SPEC 34*, and a rendezvous checklist (https://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html), in the "Testing scenarios\Rendezvous testing scenario.scn" scenario.
Of note, there is no navigation to be performed yet, so there is no Star Tracker, Radar, state vector update, etc, to worry about. The Orbit DAP pointing capability isn't good enough to have the vehicle pointing at the target, like the real Shuttle did. The SSV ascent guidance is what it is, so hitting a target plane depends only on the launch time.
*) SPEC 34 looks menacing, but basically it calculates 2 burns to get the vehicle to a user-defined position and speed relative to a target. The way the rendezvous burns are performed is do the first burn of the profile as burn 1, then do the second burn again as burn 1, etc, never actually performing the burn 2 until after the last burn in the profile, and only if you want to really hit target position and speed, as opposed to proceeding immediately closer for docking or grapple.
This is not a simple subject, and many failed rendezvous will happen before it works, but it is very rewarding to get to "something" up there.
On the Mission Editor error message: I hope to have sometime for that during the weekend.
GLS
Well-known member
Looking at this, if I input "1,2" instead of "1.2" (like I usually do), I get 12 (which is wrong) and no exception. That exception only shows up if I type 2 decimal points, e.g., "1.2.3".Same for me!
Switched the Windows settings to have the decimal symbol ",", and it seems to work as is ("1,2" is parsed correctly, and "1.2" gives 12)... so again, the exception seems to be related to something else.
In that situation where the exception occurs: what is in the Other Vessels, Scenario Parameters text box?
Could you please load mission STS-101, and then without changes, try to create a scenario? Does it throw the exception? Do the numbers on the ISS scenario block match what is in the Other Vessels tab?
(this made my head hurt more than the ADI
)Similar threads
