SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.
Was it put on for expediency ? Maybe to much of a bother to put it on and take off.

---------- Post added at 06:25 PM ---------- Previous post was at 06:24 PM ----------

Also, will the bridge rails be able to be selected for missions not flown or custom flights ?
 
Also, will the bridge rails be able to be selected for missions not flown or custom flights ?

Yes, you can select which the bridgerails are installed via mission file.
 
GLS: How do I take manual control of the speedbrake? I read the manual and am a bit of confused by which key the "minus" refers to. Is it the hyphen/underscore key to the left of the right shift key? I've tried that with no success. I've tried every other key as well with no success.
 
GLS: How do I take manual control of the speedbrake? I read the manual and am a bit of confused by which key the "minus" refers to. Is it the hyphen/underscore key to the left of the right shift key? I've tried that with no success. I've tried every other key as well with no success.

To move the SBTC the + (add) and - (subtract) keys are used, and they should be the keypad ones. The - is above the +, and so the - moves it forward and the + moves it back (so, reverse the signs, but I tried to follow the key placement on the keyboard).
IMO, the takeover button is the tricky one: it uses the -(minus) key, which on my portuguese keyboard happens to be a key that has nothing to do with signs... :uhh: But it should be one of the keys between the letters and the (big) enter. Anyway, it doesn't show up in the keymap.cfg file, so there should be no conflicts with main Orbiter functions.
 
To move the SBTC the + (add) and - (subtract) keys are used, and they should be the keypad ones. The - is above the +, and so the - moves it forward and the + moves it back (so, reverse the signs, but I tried to follow the key placement on the keyboard).
IMO, the takeover button is the tricky one: it uses the -(minus) key, which on my portuguese keyboard happens to be a key that has nothing to do with signs... :uhh: But it should be one of the keys between the letters and the (big) enter. Anyway, it doesn't show up in the keymap.cfg file, so there should be no conflicts with main Orbiter functions.
I found the key, it's the one that is two keys to the left of the backspace key, one key to right of the alphanumeric "0" key.


And with that I discovered a problem, the Aerojet DAP isn't relinquishing control of the speedbrake once WOW is sensed. This makes closing the speedbrake following wheel stop which is part of the post-landing procedures an impossible task. No matter what setting I had on the SBTC, the Aerojet DAP refused to hand over the control of the speedbrake.
 
I found the key, it's the one that is two keys to the left of the backspace key, one key to right of the alphanumeric "0" key.


And with that I discovered a problem, the Aerojet DAP isn't relinquishing control of the speedbrake once WOW is sensed. This makes closing the speedbrake following wheel stop which is part of the post-landing procedures an impossible task. No matter what setting I had on the SBTC, the Aerojet DAP refused to hand over the control of the speedbrake.

Yep, the current (trunk) AerojetDAP isn't very structured to allow manual control. I hope I can make the guidance part and a better organized AerojetDAP (not really interested in getting into the FCS business... but I'll probably have to :facepalm:) to allow more things to be done.

"Fun" related bit: there are 2 flags that are set upon main gear touchdown, the WOWLON and the FLATTURN. But why 2, isn't one enough? From what I understand, the idea was for the FLATTURN flag to be set just before touchdown, and it would signal the FCS to level the wings so the loads on the gears would be +/- even. For whatever reason (I forgot why) this never went forward, and so instead of deleting the flag it is set together with WOWLON, thus no leveling of the wings occurs before landing.

---------- Post added 06-10-18 at 10:10 AM ---------- Previous post was 06-09-18 at 11:20 PM ----------

Decided to take a look at the ET mesh... is there a reason for the LOX feedline elbow/cover/whatever at the intertank to have faces outside and inside?
 
Decided to take a look at the ET mesh... is there a reason for the LOX feedline elbow/cover/whatever at the intertank to have faces outside and inside?
It's called the "doghouse" or LOX feedline fairing and was where the ET camera lived starting with STS-114. STS-112 had it mounted in a special housing attached to the LOX cable tray. And to answer your question: no, there isn't.
 
While checking in Orbiter if my changes to the ET worked (will finish that tomorrow), I noticed that (1) the MLP texture is not correct, and (2) the stack is not correctly placed in the MLP (too north).

---------- Post added at 12:54 PM ---------- Previous post was at 12:00 AM ----------

Finished work in the SWT.msh: less 9% vertices and 8% triangles, and there are more that could go. Here's the "complain" list:
Code:
* hole above fwd SRB attach points
* hole between LH2 tank and intertank
* is a complete LH2 fwd dome needed? only the bottom should be needed to attach to the intertank
* both LH2 domes have a cut
* hole fwd and aft of umbilical plate
* "doghouses" have an inward surface with different shape from the outer one, so that needs a decision as to what is correct and what goes
* LOX disconnect valve isn't flush with the pipe around (the LH2 one is)
* disconnects have some surfaces inside that probably could go
* back faces of GOX press line supports could be deleted if they were flush against the tank (could probably be deleted as is) (same for LOX PAL ramp)
I didn't work the LWT and SLWT, honestly because it's a PITA and there is also work to do in the "code department". But the issues above and the work I did probably apply to those 2 tanks as well (maybe some groups are the same and could be copy/pasted).


Other fresh issues:
Code:
* pad meshes: water tower supports have flipped normals (checked the log and it's a 10 year old issue)
* east sphere has potential material issue, as it looks black in Orbiter, while the west sphere looks fine
* tons of hidden faces in hardstand (e.g. we are paying about 15% more for the water pipes under the MLP, and that's a big group)
* Challenger has the black chines from Columbia
* left SPM/HPM SRB has messed up sep motors
* SRBs don't sit exactly in HDPs

Also, with all these issues to track, maybe this is a good time to decide the ticket location... :shrug: IMO, it probably would be easier to have 1 issue = 1 ticket, and work (and commit) each one separately (when possible). This way potential errors could be isolated more easily.

---------- Post added at 08:26 PM ---------- Previous post was at 12:54 PM ----------

I have been working an issue today that I don't think I can fix (for now at least): the SSME GOX vent positions not being updated with the animation at the start. The issue is that the position we use comes from the LOCALVERTEXLIST, and that is not being updated in the first timestep, so the nozzles are animated to the correct place, the vents remain at the null position.
I remember a similar problem.... sometime ago... with some other part that uses a similar scheme... I searched but didn't find any references to this... :facepalm:
So, here's another good ticket candidate to be fixed when the ATVC gets its makeover.
 


I have been working an issue today that I don't think I can fix (for now at least): the SSME GOX vent positions not being updated with the animation at the start. The issue is that the position we use comes from the LOCALVERTEXLIST, and that is not being updated in the first timestep, so the nozzles are animated to the correct place, the vents remain at the null position.
I remember a similar problem.... sometime ago... with some other part that uses a similar scheme... I searched but didn't find any references to this... :facepalm:
So, here's another good ticket candidate to be fixed when the ATVC gets its makeover.


Would the XYZ position be better ?
 
Would the XYZ position be better ?
We use XYZ for it... :uhh: the problem is the source of the coordinates. Currently we rely on Orbiter calculating new ones each time the animation runs, so the point moves with the animation, effectively "animating" the point. We could calculate the point manually... :shrug:
 
We use XYZ for it... :uhh: the problem is the source of the coordinates. Currently we rely on Orbiter calculating new ones each time the animation runs, so the point moves with the animation, effectively "animating" the point. We could calculate the point manually... :shrug:


Are you ready to finalize the mesh ?
 
I'm certainly not done with the orbiter yet. I still have the PLBD handrails and some stuff with the payload bay left to check into.
 
I'm certainly not done with the orbiter yet. I still have the PLBD handrails and some stuff with the payload bay left to check into.
That could be a separate mesh.
 
:rofl:
I meant so Wolf can finish his Orbiter textures.

Oh... yes groups should be worked as individually as possible, to avoid major changes all at once. IMO, most of the items on that massive list I posted should be one commit.
 
Can you make a normal map that mimics the surface of the real rail? :hmm:

(And maybe use this normal map to maybe also replace some triangles, looks relatively high poly for a such a small part, but then, it might be seen from close)
 
Status
Not open for further replies.
Back
Top