SSU V1.25 Release

Status
Not open for further replies.
I made a launch few minutes ago. I flown to MECO with no problems. And it was time to ET sep, but instead of ET, shuttle separated... UMMU. Camera switched to UMMU and RCS engines didn't shut down after +Z translation. ET disappeared.
 
I made a launch few minutes ago. I flown to MECO with no problems. And it was time to ET sep, but instead of ET, shuttle separated... UMMU. Camera switched to UMMU and RCS engines didn't shut down after +Z translation. ET disappeared.

SSU does not support UMMU as far as I remember. Did you have an add-on like UMMUFA active?
 
No, I haven't active. I mean, that ET disappeared, but I camera switched me to Discovery_MMU view. When you press CTRL+E, you will se human in space suit.
 
Dennis,

Were you able to fix the ODS panels ?
 
I don't think the MDU buttons should hold up release. I think if the ODS buttons are fixed and we can get the launch roll bug fixed, we could release.
 
I don't think the MDU buttons should hold up release. I think if the ODS buttons are fixed and we can get the launch roll bug fixed, we could release.

I just want to have the whole VC mess solved before I commit. It is no large bugfix, but I just have little time for SSU, as my Visual Studio is mostly in the hands of my university project.


-----Post Added-----


BTW: Could we already include a fictive STS-144 mission into the next release? How much would be missing for a HST retrieval mission? Most of the payload already exists, the question is just - which features would need to be implemented then in 1.25?

http://en.wikipedia.org/wiki/STS-144


I think the payload system would need to learn how to grapple things, which is a medium-size task. Can we fit the ODS and Hubble into the payload bay?
 
BTW: Could we already include a fictive STS-144 mission into the next release? How much would be missing for a HST retrieval mission? Most of the payload already exists, the question is just - which features would need to be implemented then in 1.25?
EVA tasks really to get rid of the SA3's that were installed on 109. They won't fit into the bay along with the HST, so they would have to be jettisoned into space like the damaged SA1 on 61.


I think the payload system would need to learn how to grapple things, which is a medium-size task. Can we fit the ODS and Hubble into the payload bay?
Maybe, if they could move the aft trunnion PRLs further aft so that HST would occupy the last two sections of the bay, bays 12/13.

I have attached a photo of HST in Discovery's payload bay prior to PLBD closure at the pad for flight.
 

Attachments

  • HST in Discovery PLB.jpg
    HST in Discovery PLB.jpg
    180.2 KB · Views: 598
BTW, does this mean you're considering adding Columbia to the SSU orbiter fleet? Would make sense as she was the only orbiter with an internal airlock and had the entire bay free for payloads.

I believe the plan for the original 118 mission was for Columbia to borrow Discovery's External Airlock/ODS while keeping her internal airlock as Discovery was in a OMDP at the time.
 
BTW, does this mean you're considering adding Columbia to the SSU orbiter fleet? Would make sense as she was the only orbiter with an internal airlock and had the entire bay free for payloads.

Yes, I consider it, but not on a high priority level. Adding the internal airlock would be a mid-deck visual task, don't know if this still fits into the next release, as we are damn close to it now.

If the STS-144 plan gets too complex, I think it is better waiting with it for the following release. While working on the entry code and optimizing the performance, we could also find time to add the internal airlock option to the Mid-Deck.

And if we delay it for the 1.26 release, we could also think about implementing good EVAs. For which a Hubble mission would be a good development object, as Hubble is a very nice monolithic (not modular) playground.

Currently it sounds more like this mission might be better delayed for 1.26.


-----Post Added-----


Uploaded a fix for the ODS panels and the F7 MDU buttons, but I am still not happy with the position, though the error had become much smaller now.

Maybe somebody can find four better positions of the corners of the mouse sensitive area.
 
If we skip the whole external/internal airlock bit for now, what would it take to implement Columbia? I got the texture and SILTS pod ready.
 
If we skip the whole external/internal airlock bit for now, what would it take to implement Columbia? I got the texture and SILTS pod ready.

Swapping hull texture could be done in about 2 hours, including testing.
Not sure about the SILTS pod, possible that this can be done also in a short time.

How would you like to define the orbiter? In the scenario or by configuration file?
 
Swapping hull texture could be done in about 2 hours, including testing.
Not sure about the SILTS pod, possible that this can be done also in a short time.

How would you like to define the orbiter? In the scenario or by configuration file?
How about the scenario? Wouldn't that be the most logical choice? I'll check in the SILTS pod and texture.
 
How about the scenario? Wouldn't that be the most logical choice? I'll check in the SILTS pod and texture.

Well, both would work, it is not like the SILTS pod gets swapped every other mission.
 
Columbia specific items have now been checked in.
 
The Middeck will be available soon maybe less than a month. I'm guessing it won't make this release. I've not modeled the internal airlock, yet. Has anyone modeled the external airlock+interior.

On the to-do texture list:
Galley - almost complete, refining textures.
Escape pole,
Baggage,
Celling and sides of the middeck

On the to-do Modeling list:
Middeck seat folded - 2 minute job.
WCS - for the moment I'm leaving the door closed on this version due to lack of info.
Internal airlock - I suspect the interior will be somewhat similar to the external version, but with two doors (ISS and External)

BTW are the Textures in the cockpit Baked?
 
Swapping hull texture could be done in about 2 hours, including testing.
Not sure about the SILTS pod, possible that this can be done also in a short time.

How would you like to define the orbiter? In the scenario or by configuration file?
My thinking is that we should have a mission-specific configuration file for each set of scenarios. This would define the shuttle, RMS, ODS/airlock, etc. The actual scenario file would then just contain the name of the configuration file.
 
My thinking is that we should have a mission-specific configuration file for each set of scenarios. This would define the shuttle, RMS, ODS/airlock, etc. The actual scenario file would then just contain the name of the configuration file.
Good idea. How hard would this be to implement?
 
Status
Not open for further replies.
Back
Top