SSU Development Thread (2.0 to 3.0)

Status
Not open for further replies.
I hope it will be a helluv alot easier than that.

It must be removed before release anyway. There should be no debug Strings at all in a release, unless the player wishes so.
 
I saw where you guys are looking to maybe use brianj's Sunnyvale addon for SSU, why don't you swap him a working Shuttle/Centaur payload for shuttle fleet. I think he has plans for an STS 34 next year and would have an alternative centaur upper stage scenario
 
So I went to check exactly what the debug string showed and found there's an offset in the GOX vents... all visible in the picture. The number in the debug string is constantly changing.
 

Attachments

  • debugstring_ventoffset.png
    debugstring_ventoffset.png
    380.8 KB · Views: 530
So I went to check exactly what the debug string showed and found there's an offset in the GOX vents... all visible in the picture. The number in the debug string is constantly changing.
The numbers jumping around is normal due to the singularity effect, it essentially causes a confusion in the calculations.

The GOX vents problem is probably due to an outdated mesh that isn't compatible with the code which uses the post-2007 pad A as the base.
 
Jumping or still, why don't the numbers show in other scenarios? Is something wrong with the CISS/Centaur or the shuttle, or is it all normal?
About the GOX vent, I'm using the latest revision... recent changes?
 
So I went to check exactly what the debug string showed and found there's an offset in the GOX vents... all visible in the picture. The number in the debug string is constantly changing.
The debug string has nothing to do with the GOX vent offset; it just indicates the state of the Ready-To-Latch flag. I'll go through the code and get rid of all the debug strings.
 
The debug string has nothing to do with the GOX vent offset; it just indicates the state of the Ready-To-Latch flag. I'll go through the code and get rid of all the debug strings.

Yes, I'm pretty sure they have nothing to do with each other, I just happened to find the vent "bug" when I went to get a screen grab of the debug string. :lol:
 
Jumping or still, why don't the numbers show in other scenarios? Is something wrong with the CISS/Centaur or the shuttle, or is it all normal?
About the GOX vent, I'm using the latest revision... recent changes?
The 1985 version of the pad meshes (FSS/RSS) are old, I haven't worked on them in quite awhile. I'm not even sure that they match the 2007(current) meshes which is why the vents are in the wrong location on the 1985 version.

And there's nothing wrong with the RTL status text. As I wrote, due to the singularity effect, Orbiter can't calculate the delta between the payload attachment point the indicated latch attachment point. This leads to Orbiter try to find a solution every timestep but ends up failing over and over again.
 
And there's nothing wrong with the RTL status text. As I wrote, due to the singularity effect, Orbiter can't calculate the delta between the payload attachment point the indicated latch attachment point. This leads to Orbiter try to find a solution every timestep but ends up failing over and over again.
Wrong. The number keeps changing because it's generating a new (random) number each timestep. This makes debugging easier, because it's easy to see when the object moves out of the RTL range (the numbers stop updating).
 
The 1985 version of the pad meshes (FSS/RSS) are old, I haven't worked on them in quite awhile. I'm not even sure that they match the 2007(current) meshes which is why the vents are in the wrong location on the 1985 version.

So, we have to declare this feature unfit for release? Or can you fix the meshes quickly?
 
So, we have to declare this feature unfit for release? Or can you fix the meshes quickly?
No chance of fixing them quickly. For now I recommend simply changing the scenarios to use SSUPad instead of SSUPad1985.
 
No chance of fixing them quickly. For now I recommend simply changing the scenarios to use SSUPad instead of SSUPad1985.

OK, will be done.

Something else, we should maybe include in the next release: Calculating as much maneuvering data as possible in-game for making SSU easier to use.

G104 should calculate the OMS-1 maneuver target when initially displayed
G105 should calculate the OMS-2 maneuver target when initially displayed

Both should also get support for I-loaded maneuver target data for aborts.

For G202, there should be a some kind of manual way to define a target orbit and then get the maneuver data displayed somewhere.

My gold-plated solution would be creating a custom dialog for SSU, that we can open anytime by a key combination, which has three buttons on the bottom: "<<<", "Close", ">>>" and displays maneuver pad data in the same form as it is printed on-board the space Shuttle.
 
Donamy, could you add the aft midbody umbilical cavities to the PLB? Here's a photo from STS-26 that shows the port one, the arrow points to it.

Midbody%20umbilical.jpg


It connects the PLB to this exterior panel, in fact you can see the inside face of this panel in the STS-26 photo. It's the one labeled Centaur/H2 servicing panel.
Discovery_Centaur_LH2_dump_port.jpg
 
Donamy, could you add the aft midbody umbilical cavities to the PLB? Here's a photo from STS-26 that shows the port one, the arrow points to it.

Midbody%20umbilical.jpg


It connects the PLB to this exterior panel, in fact you can see the inside face of this panel in the STS-26 photo. It's the one labeled Centaur/H2 servicing panel.
Discovery_Centaur_LH2_dump_port.jpg

What are the x,y,z coords and the dimantions ?
 
What are the x,y,z coords and the dimantions ?
The dimensions of the panel itself is 0.51x0.58(m). For the coordinates, do you want them according to the real shuttle coordinate system?
 
The dimensions of the panel itself is 0.51x0.58(m). For the coordinates, do you want them according to the real shuttle coordinate system?

I think it would be better, to just add it to the texture for now. Too much work and part rearranging. Right now, I'm working on getting the animation angles done for a release. Speaking of which, what is the angle for PLBY door opening ?
 
I think it would be better, to just add it to the texture for now. Too much work and part rearranging. Right now, I'm working on getting the animation angles done for a release. Speaking of which, what is the angle for PLBY door opening ?
175.5°. No need for the angles, we already have them correct. All that is needed is the rotation points.
 
Yes, but in order to have the pull and push rods correct, because of sizing and moving, it needs to be known.

---------- Post added at 04:28 PM ---------- Previous post was at 04:27 PM ----------

Also, where do the radiators hinge ?
 
Do you have a diagram showing the PLBY push-pull hinge ?
 
Status
Not open for further replies.
Back
Top