Space Shuttle Ultra 1.25 Revision B development
- Thread starter Urwumpe
- Start date
OK, got it.
SiameseCat
Addon Developer
I'm thinking it might be a good idea to set the Y-pos of the attachments as well, so we don't have to edit the config file of each payload to work with SSU. Any objections to this?
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I think in the long run, it is simpler editing the configuration files of the payloads than including complex fixes for permitting using payloads for other add-ons.
Next we would need to change the orientation of the payload attachment point coordinate system for permitting other payloads. Then we would need to use a special logic for the RMS to permit using payloads of other add-ons. Or resize the payload bay to allow integrating payloads for add-ons that had historically a wrong payload bay dimension.
Maybe it is better to adapt a "mer san mer" (Bavarian: we are we) attitude and require payloads to be explicitly adapted to SSU, then permitting badly converted payloads to be integrated into SSU with brute force. What do we have to loose? I think we have a higher risk in trying to please any add-on to be a payload for us, then having a slightly higher standard for the payloads to be transported.
Or in different words: I don't want to spend time for perfectly having the DPS screens of the real Shuttle implemented, only to then transport sloppy made add-ons for other Shuttles or Gliders with it.
I'd prefer being a bit elitist.
Last edited:
Donamy
Addon Developer
I agree. It would also help people learn how to make addons of their own, to work with SSU.
SiameseCat
Addon Developer
Haven't had the chance to do the texture work yet; I'll probably do it on Thursday (unless Urwumpe has already done it by then).
OK, just to let you know, I checked in some minor corrections to the two Columbia textures. Which leads to me to another question: How do we handle Columbia? It wasn't until her last OMDP(1999 to 2001) that she had her name written on the starboard wing, like the rest of the fleet.
From 1985 to 1999 she only had the name written on the forward fuselage sides. And from 1981 to 1985, the name was written on the forward PLBD sides.
So how are we going to handle this? By removing the dynamic wing painting function and have the name as part of the texture file itself?
Yes, that's the plan. BTW, how's the work coming along? I'm currently working on the OTF SRBs. Once they're done, I'll start working on the STS-1 and STS-2 ETs.
Donamy: I'm going to need some help with the FRL texture for the STS-1 and 2 ET LOX tanks: http://www-pao.ksc.nasa.gov/kscpao/images/large/80PC0709.jpg
Notice the ridged surface of the LOX tank. That was due to the application of the FRL layer over the foam.
---------- Post added at 03:27 AM ---------- Previous post was at 01:09 AM ----------
The OFT LH-SRB is almost complete. Just need to finish up the FWD Skirt Assy. and then add the various aft skirt elements. THen I'll move on to the RH-SRB. Should be all done in a day or so.
Both yes and no. That psd was for post-SRB sep texture. Here I'm talking about the FRL or Fire Retardant Latex coating layer, the white "paint" on the first two ETs. The FRL was applied to minimize propellant boil-off during the countdown and to protect the ET from aerodynamic heating during ascent.
After STS-1, they realized that the FRL wasn't needed so it was deleted from future ETs, saving 595 lbs of mass to MECO. The first mission to use an ET completely free of the FRL was STS-6 which also happened to use the first Lightweight ET(LWT).
STS-1 through 5 used the only batch of Standard Weight ETs(SWTs).
SiameseCat
Addon Developer
I've checked in the keyboard controls for the cameras, as well as a preliminary version of the texture swapping. At the moment, the 'OrbiterTexture' parameter specifes the name of the texture (in the Textures\SSU directory) to be used.
The wing painting code hasn't been modified yet; how exactly do you want to implement this? I'm thinking the best solution is to turn the wing-painting off completely and use textures with the name directly on the texture.
The wing painting code hasn't been modified yet; how exactly do you want to implement this? I'm thinking the best solution is to turn the wing-painting off completely and use textures with the name directly on the texture.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I thought it might make sense setting a decimal number option in the mission file, for setting how the wing names should be rendered, in case you want to use a generic texture...would make it possible for people to use custom orbiters without custom textures... and allow custom textures for better looks.
Thanks, but I can't get it to compile. First it fails on making the help file, then it can't find the file afxwin.h.
---------- Post added at 06:27 PM ---------- Previous post was at 06:12 PM ----------
Just checked in a STS-1 mission file and a L-10 launch scenario. Here's a bug for you to try to fix: The ascent AP is never initialized. If you try the the STS-1 launch scenario you'll notice that the ascent AP isn't going active after lift-off.
It loads the mission file just right but the ascent AP parameters in it isn't being read leading to a dead nonfunctional AP.
