Space Shuttle Ultra 1.25 Revision B development

[Donamy]

One thing that I've always wanted in SSU, is the ability to stow the SSMEs after shutdown. Could anyone look at this ?

 

[SiameseCat]

Checked and there's nothing there. I tried altering the offsets listed in Atlantis_defs.h, with no change.

It's the LSRB/RSRB_ATTACH_POS variables, lines 38 & 39 in Atlantis_defs.h

 

[DaveS]

Donamy: Do you think you could thicken the payload bay doors a bit? They should overlap the bulkhead latch rollers, like in this photo from STS-51J:

 

[Urwumpe]

Donamy: Do you think you could thicken the payload bay doors a bit? They should overlap the bulkhead latch rollers, like in this photo from STS-51J:

It would also be nice if at least the talkbacks of the overhead panel could be made with texture animations instead of painting textures (I mention it every 2 months, I can also remember mentioning it in January), so I can finally have an implementation of the talkbacks there, that works and is fast.

If you want, I can produce a quick demo vessel with such animations to explain the process before I switch my location completely and move my computer into the new apartment (not before December, I won't have a bed room there until the end of November).

But this weekend is still reserved with hauling material. And I have no 18m payload bay for the mission.

BTW: Found a nice compiler programming tutorial for Pascal-like languages, like Ada (BlackAda for the Black Dart) and HAL/S... really fascinating.

 

[Donamy]

It would also be nice if at least the talkbacks of the overhead panel could be made with texture animations instead of painting textures (I mention it every 2 months, I can also remember mentioning it in January), so I can finally have an implementation of the talkbacks there, that works and is fast.

If you want, I can produce a quick demo vessel with such animations to explain the process before I switch my location completely and move my computer into the new apartment (not before December, I won't have a bed room there until the end of November).

But this weekend is still reserved with hauling material. And I have no 18m payload bay for the mission.

BTW: Found a nice compiler programming tutorial for Pascal-like languages, like Ada (BlackAda for the Black Dart) and HAL/S... really fascinating.

Did you ever do anything with the O6 talkbacks ?

 

[Urwumpe]

Did you ever do anything with the O6 talkbacks ?

Yes, GPC status and Star Tracker Door status.

 

[Donamy]

Do they work ?

 

[Urwumpe]

Do they work ?

Not really, since the talkback code currently needs to be adapted for every panel texture again. The size of the area does not fit, we would need a new set of special bitmaps there and then also the code is ineffective as hell as it is now, since we need to transfer huge uncompressed textures to the GPU after every refresh.

That is why I would suggest optimizing this a bit for GPUs... instead of changing the textures, we change how the textures are mapped.

 

[DaveS]

Speaking of the VC: Could the glass covers over the RCS COMMAND indicators(F6), ATT REF PBI(F6, F8) and Abort Mode PBI(F6) be removed?

 

[Donamy]

Speaking of the VC: Could the glass covers over the RCS COMMAND indicators(F6), ATT REF PBI(F6, F8) and Abort Mode PBI(F6) be removed?

I suppose, but should they ?

---------- Post added at 08:07 PM ---------- Previous post was at 08:06 PM ----------

Not really, since the talkback code currently needs to be adapted for every panel texture again. The size of the area does not fit, we would need a new set of special bitmaps there and then also the code is ineffective as hell as it is now, since we need to transfer huge uncompressed textures to the GPU after every refresh.

That is why I would suggest optimizing this a bit for GPUs... instead of changing the textures, we change how the textures are mapped.

Does this have anything to do with the meshes ?

 

[Urwumpe]

Does this have anything to do with the meshes ?

Yes - we need some changes there:

- The talkbacks have to be dedicated quads (two triangles).
- All talkbacks that use the same symbols can be part of the same meshgroup and use the same texture.
- The vertex numbers need to be known.
- The textures contain the symbols and are no longer dynamic.

What is needed then is getting a list of 4 vertex numbers, and manipulate the UV coordinates of them, instead of doing paint operations on textures.

 

[DaveS]

I suppose, but should they ?

Yes. This is a photo of Discovery's panel F6:

 

[Donamy]

My knees are trembling at the number of talkbacks there are.

 

[Urwumpe]

My knees are trembling at the number of talkbacks there are.

I know, but practically, the first talkback should be the hardest, you just need to put the quad on top of the panel surface, better give it a good name, then we can find it again when something changes.

 

[DaveS]

Yes. This is a photo of Discovery's panel F6:

Here's a photo of Atlantis' forward flight deck. Note that there's no covers:

 

[Donamy]

I know, but practically, the first talkback should be the hardest, you just need to put the quad on top of the panel surface, better give it a good name, then we can find it again when something changes.

need more info

 

[DaveS]

Checked in a new orbiter mesh with the thicker payload bay doors along with some other changes like modified rudder/speedbrake panels and new texture for the forward/aft payload bay bulkhead winches.

 

[Poscik]

SiameseCat: any chance to have something like f.e. dap->SetRoll(-65); ? I wanted to play a little bit with reentry, and would need roll guidance. What I want to do? I want to generate something like lookup tables [range to base vs. vertical speed]. Each entry by 10nm of downrange (or less). So I could read needed vertical speed at particular moment and modify it by rolling more or less. Any objections?

 

[SiameseCat]

Take a look at the AerojetDAP class; at the moment it just uses CSS to control the roll (CSS - control stick steering, i.e. the pilot controls the roll). It should be fairly easy to calculate the required roll and set the value; look at the OnPreStep function and CSSRollGuidance functions. Let me know if you have any further questions.

I could be wrong, but I don't think a lookup table for vertical speed will work well. The problem is, if you're too high or too low, controlling vertical speed won't do anything to get you back on course. A better solution (IMHO) is to have a target drag level, and convert that into a target vertical speed.

 

[C3PO]

I could be wrong, but I don't think a lookup table for vertical speed will work well. The problem is, if you're too high or too low, controlling vertical speed won't do anything to get you back on course. A better solution (IMHO) is to have a target drag level, and convert that into a target vertical speed.

Don't you have to check the total energy (speed+alt) vs. range to get the required deceleration?