GLS
Well-known member
No issues here... and there shouldn't be any difference between that keyboard and the other 2.
SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
No issues here... and there shouldn't be any difference between that keyboard and the other 2.
Donamy
Addon Developer
I suppose I can pretend it's there. :hmm:
---------- Post added at 08:28 PM ---------- Previous post was at 08:14 PM ----------
Something to test. Let me know if I forgot anything.
[ame="http://www.orbithangar.com/searchid.php?ID=7076"]STS-88 For SSU 5.0[/ame]
---------- Post added at 08:28 PM ---------- Previous post was at 08:14 PM ----------
Something to test. Let me know if I forgot anything.
[ame="http://www.orbithangar.com/searchid.php?ID=7076"]STS-88 For SSU 5.0[/ame]
You should change the config files to point to their respective SC* modules. As it is now, they all point to GenericVessel which isn't available anymore.
No. All of them point to GenericVessel.
Yes. So far it seems to be the only issue.
Not much we can do about it as it seems to be a bug in the Orbiter core that is handling attachment points. The only one who can fix that would be the Dr.
Is the scenario STS-107 De-orbit in the Hystorical misions folder working properly?
The deorbit burn targets are already inputted (same values as the scenario description) but I have the impression that TIG is way too early for KSC re entry. Also after transitioning to OPS304 and well before E.I. shuttle starts rolling to the left and keeps doing that all the way down (roll induced by the RCS system with P and R in AUTO)
The deorbit burn targets are already inputted (same values as the scenario description) but I have the impression that TIG is way too early for KSC re entry. Also after transitioning to OPS304 and well before E.I. shuttle starts rolling to the left and keeps doing that all the way down (roll induced by the RCS system with P and R in AUTO)
The trajectory is most likely off. It was a best estimate based on actual historic orbiter position for TIG. I have never experienced any control issues during any entries.
So is it possible that the LOC is due to the wrong trajectory that the DAP is unable to cope with? Has anyone tried that scenario? I am just starting to familiarize with SSU so chances are I'm doing something very wrong...
Could be. But even so, the Aerojet DAP should be able to make up for the longer distance. One thing though is that you have to use the Scenario Editor to "dump" IE remove all the propellant from the FRCS tanks. Normally this would be done using the FRCS DUMP command items available in MM302 (ITEMs 36-38). This would cause the FRCS lateral jets to fire in order to get rid of the desired amount of FRCS propellant.
---------- Post added at 05:44 PM ---------- Previous post was at 05:32 PM ----------
So I tried the scenario in question, and for some reason upon transition to MM304, a left roll is immediately commanded, even if the orbiter is well above EI altitude.
At least I am not the only one... have you tried it after adjusting the scn file as suggested by you?
I checked it out and there's a problem. You seem to have used the current mesh that is included with SSU and that's not right. You need to use the one I included with zip file I linked to in my PM. The reason for this is that it has a boatload of fixes and changes that the current one doesn't, not the least to the overall size of the orbiter.
Yes. I only have one zip file in my Dropbox named "New_Orbiter.zip" and it contains the new Orbiter.ac (Not Orbiter2.ac) along with two new WIP textures, Discovery_9thmod_rev2.dds and Columbia_original_rev2.dds.
- Status
Similar threads
