Space Shuttle Ultra 4.0 PRESS TO MECO

[DaveS]

That does not sound properly at all - the RealRCS implementation should stop at the thruster groups, if I remember correctly.

I don't know what to tell you, other than the behavior I observe which is that the RealRCS implementation just isn't performing as it should.

 

[Urwumpe]

I don't know what to tell you, other than the behavior I observe which is that the RealRCS implementation just isn't performing as it should.

Yes, I would say, something in our DAP code is directly talking to thrusters instead of thruster groups. Since the number of thrusters and the grouping of the thrusters changed, this could explain it.

 

[DaveS]

Quick Q: Would it be possible to implement custom OMS pod textures similar to what we have for the orbiter exterior? It is kinda grating to see the final OMS pod TPS config for the early missions. That design didn't debut until STS-51B in April 1985 on Challenger.

 

[GLS]

I think it's possible. I'll look into that tomorrow.

---------- Post added at 11:50 AM ---------- Previous post was at 01:21 AM ----------

Are the "new OMS pods" going on 4.0 or 5.0? I vote for 5.0, as changes might bring bugs (see ODS changes in previous pages), and if 4.0 is coming out then we should keep it stable.

If the RCS changes take time and Urwumpe is busy (not complaining... it's life), why not just correct the CISS animation coordinates and release 4.0? The RCS changes would have more time to catch the next train (5.0).
The "new" Orbiter came out over a month ago, and right now we are still thinking about releasing, sometime in the future, a SSU version for the "old" Orbiter version... meanwhile we are still not near to 5.0 release... I don't think we can't continue this "2-front development" much longer with the just 0.7 programmers.

 

[DaveS]

I think it's possible. I'll look into that tomorrow.

---------- Post added at 11:50 AM ---------- Previous post was at 01:21 AM ----------

Are the "new OMS pods" going on 4.0 or 5.0? I vote for 5.0, as changes might bring bugs (see ODS changes in previous pages), and if 4.0 is coming out then we should keep it stable.

If the RCS changes take time and Urwumpe is busy (not complaining... it's life), why not just correct the CISS animation coordinates and release 4.0? The RCS changes would have more time to catch the next train (5.0).
The "new" Orbiter came out over a month ago, and right now we are still thinking about releasing, sometime in the future, a SSU version for the "old" Orbiter version... meanwhile we are still not near to 5.0 release... I don't think we can't continue this "2-front development" much longer with the just 0.7 programmers.

Maybe we should create a poll on the subject? That should show the path we should consider taking. Also, what we have now in the beta branch is actually pretty stable so maybe 4.0 could be released for both 2010-P1 and 2016 with the explicit understanding that 4.0 will be the last for 2010-P1?

 

[Urwumpe]

If the RCS changes take time and Urwumpe is busy (not complaining... it's life), why not just correct the CISS animation coordinates and release 4.0? The RCS changes would have more time to catch the next train (5.0).
The "new" Orbiter came out over a month ago, and right now we are still thinking about releasing, sometime in the future, a SSU version for the "old" Orbiter version... meanwhile we are still not near to 5.0 release... I don't think we can't continue this "2-front development" much longer with the just 0.7 programmers.

I agree there, we should limit the few resources we have on few features and stick to them, instead of bouncing from feature to feature. Also we should try reducing extra work as good as possible.

 

[GLS]

Maybe we should create a poll on the subject? That should show the path we should consider taking. Also, what we have now in the beta branch is actually pretty stable so maybe 4.0 could be released for both 2010-P1 and 2016 with the explicit understanding that 4.0 will be the last for 2010-P1?

Fly the EDW TAEM scenario all the way to wheels stop, and then let me hear you talk about releasing for Orbiter 2016 in the near future. :lol:

IMO, 4.0 is the last (major) release for 2010. We could eventually release a patch or a 4.1 with a fix to a major bug or add some new simple stuff (maybe a texture or mesh update), but other than that I think we should get it out of the way and focus (more) seriously on 5.0 for 2016, instead of staying in the middle of the bridge not knowing which way to go while the river runs by.

 

[DaveS]

Fly the EDW TAEM scenario all the way to wheels stop, and then let me hear you talk about releasing for Orbiter 2016 in the near future. :lol:

Well, considering that we can't compute a proper de-orbit burn, landing is currently irrelevant. You could always land at KSC, it's nice and flat.

 

[indy91]

Well, considering that we can't compute a proper de-orbit burn, landing is currently irrelevant.

Isn't this done with the onboard computer? Has that not been added yet?

 

[Urwumpe]

Isn't this done with the onboard computer? Has that not been added yet?

It can be done with onboard computer. But usually, the data is calculated on the ground by mission control and uplinked to the crew.

 

[indy91]

It can be done with onboard computer. But usually, the data is calculated on the ground by mission control and uplinked to the crew.

I guess there is no option onboard to calculate the correct TIG and EI parameters (C1, C2 and central angle) to set up the Shuttle for a specific landing site, right? I have basically developed just that for NASSP, including Maneuver PAD and everything. So I would certainly be interested to help SSU with a few of these GNC problems, maybe when we get the NASSP 7.0 release ready in a few weeks/months. I don't want to take away any work from a dedicated SSU developer for these problems of course. :lol:

 

[GLS]

I think a makeshift deorbit burn calculator could be added to SSU Workbench, by (somehow) giving it the vehicle state vector and a target runway, and it would calculate if the deorbit burn was done now, targeting a certain FPA at EI, what would the range and crossrange be for the target runway. If those parameters are within the limits = deorbit opportunity, if not, propagate the state vector 1 minute (or something else) into the future and try it again, etc, etc...
Yes, it could be geologically slow to search a couple of orbits, but as it would not run inside Orbiter it doesn't hurt the sim performance.

 

[Urwumpe]

I think a makeshift deorbit burn calculator could be added to SSU Workbench, by (somehow) giving it the vehicle state vector and a target runway, and it would calculate if the deorbit burn was done now, targeting a certain FPA at EI, what would the range and crossrange be for the target runway. If those parameters are within the limits = deorbit opportunity, if not, propagate the state vector 1 minute (or something else) into the future and try it again, etc, etc...
Yes, it could be geologically slow to search a couple of orbits, but as it would not run inside Orbiter it doesn't hurt the sim performance.

I think it would be better to have such a function inside the run-time of SSU, so it is corresponding to the current Orbit parameters.

Maybe by having a "cheat" key binding to trigger such a calculation or by having a Dialog window that allows calculating the next deorbit opportunity for a landing site.

 

[GLS]

So, how will we specify the textures for the OMS pods? By naming the texture for each side individually or together? Or should we have a "OMS_TPS_Config=number" and the number represents one of the flown configurations, and from that the code loads the correct textures?
Or should we have both, the number being the default, but also allowing user textures to be used via another parameter? (OMS_TPS_TEX maybe?)

BTW, texture naming, is this good?
LOMS_TPS_1.tex (config A in diagram)
LOMS_TPS_2.tex (config B in diagram)
LOMS_TPS_3.tex (config C in diagram),
LOMS_TPS_4.tex (config D in diagram, but all LRSI in the front)
LOMS_TPS_5.tex (config D as in the diagram)

 

[Urwumpe]

Keep it simple, I would say. Just the texture file name should be good enough, if the player edits nonsense into it, its fine. Otherwise we would have a filename generator + the important action.

If we need a logic to configure an orbiter to a special historic configuration, I would say, that is a task that fits great into the SSU Workbench idea.

It would be different, if we would pay attention to the actual heat shield and its thermal/DynPress limits. (In that case, it might be better to group the data into an extra configuration file, including the texture file name)

 

[GLS]

The LOMSPodTexture and ROMSPodTexture mission file entries now control the OMS pod texture.
I didn't change the name of the textures, but I'm liking this system more and more:
LOMS_TPS_1.tex (config A in diagram)
LOMS_TPS_2.tex (config B in diagram)
LOMS_TPS_3.tex (config C in diagram)
LOMS_TPS_4.tex (config D in diagram, but all LRSI in the front)
LOMS_TPS_5.tex (config D as in the diagram)

DaveS, if you have the time, could you move the fwd bulkhead and docking lights into a separate group, so we can hide them when they are not there? There are just too many points for me to work by hand in my lifetime.

Any news about the 4.0 release?

 

[DaveS]

DaveS, if you have the time, could you move the fwd bulkhead and docking lights into a separate group, so we can hide them when they are not there? There are just too many points for me to work by hand in my lifetime.

They have now been separated in the source file, I have a few more changes to do, but once those are good, I'll check it in.

 

[DaveS]

I have checked in the updated orbiter mesh that has FWD light separated into their mesh groups.

 

[GLS]

I have checked in the updated orbiter mesh that has FWD light separated into their mesh groups.

... and now they don't appear when they are not used!

BTW1: The forward bulkhead texture should be edited to remove the lights from it, so when they are not used it looks there's just a blanket there.

BTW2: I only needed the lights separated from the rest of the forward bulkhead stuff, they could be in the same group instead of 2 separate ones. It works anyway.

BTW3: I noticed that there's a big gap between the upper fuselage and the forward bulkhead, and a gap between the last 2 RCC panels of the right wing.

 

[DaveS]

BTW3: I noticed that there's a big gap between the upper fuselage and the forward bulkhead, and a gap between the last 2 RCC panels of the right wing.

I can't see anything wrong here. No gaps or anything.