GLS
Well-known member
It's up! No more miscalculations now. :tiphat:
SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
It's up! No more miscalculations now. :tiphat:
I have hit a bit of stumbling block on fixing the hole in the wing box (bottom of bays 12/13) with the current implementation of the liner as there was no liner there. This can be seen in this photo of the PLBD Closure in the OPF for STS-125(last mission to use the liner): https://www.dropbox.com/s/hl3msf1yp77twhj/08pd2120.jpg?dl=0
So the implementation has to be changed to be like all the other mission-optional equipment, that only the liner is affected by the HasPLBLiner parameter and not the regular TCS blankets. We're talking about 793 faces here.
So the implementation has to be changed to be like all the other mission-optional equipment, that only the liner is affected by the HasPLBLiner parameter and not the regular TCS blankets. We're talking about 793 faces here.
GLS
Well-known member
Could those blankets in bays 12 and 13 be put in a separate group? That way we would only hide the forward ones and leave those always visible. :shrug:
Found this interesting document on NTRS on the PLBDs: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19790014389.pdf
It includes a detail description of the PLBD motion mechanics with force measurements.
---------- Post added at 12:18 PM ---------- Previous post was at 12:17 PM ----------
It includes a detail description of the PLBD motion mechanics with force measurements.
---------- Post added at 12:18 PM ---------- Previous post was at 12:17 PM ----------
That could be done. I'll look at it.
GLS
Well-known member
It doesn't have what we need: torque shaft position and angle of rotation (figure 4), so the mechanism can be animated accurately. Currently those values are guessed and tuned so the PLBDs open what they should.
This photo of the torque shaft for the right PLBD shows where it is located: https://www.dropbox.com/s/v8auwcrla554m4t/04pd1282.jpg?dl=0
Based on that photo, I would say that the coordinates for it are as follows:
Xo660
Yo95
Zo402
The push/pull-rods are approx. 11 inches long and with the doors fully closed, have angle of approx. 2.65°s. When open, their angle is approx. 6.5°s.
GLS
Well-known member
I've just seen the result of my work in correcting the include dependencies: I changed the SimpleGPCSystem.h file and just had to compile a few files (the GPC software stuff), instead of recompiling the full solution. 
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I've just seen the result of my work in correcting the include dependencies: I changed the SimpleGPCSystem.h file and just had to compile a few files (the GPC software stuff), instead of recompiling the full solution.
Yeah, SOLID is a great thing to remember.
S - Single-responsiblity principle
O - Open-closed principle
L - Liskov substitution principle
I - Interface segregation principle
D - Dependency Inversion Principle
GLS
Well-known member
About our license "headers": should we use the same text in the libUltra files?
GLS
Well-known member
Is there any info about the conversion from NZ error to "guidance diamond" vertical position in the HUD?
Donamy
Addon Developer
We need a release, that works with Orbiter 2016. Taking advantage, of the new DxD9 enhancements is a must, IMO. Couldn't someone compile it and release as a alpha build ?
I would start to setup some ISS building payloads for it.
I would start to setup some ISS building payloads for it.
GLS
Well-known member
Yes we do, I've been saying this since before Orbiter 2016 was released. But with only one person coding, things don't move very fast, even with me working day and night. :shrug: I still have to (1) finish the AerojetDAP, then (2) add more code to temporarily feed data to the displays (otherwise things would take much much longer), (3) finish the HUD (add smoothing of display items and correct the runway overlay), (4) workout "small" (but not easy) details on the whole entry code, (5) finish the "state variables" scenario load/save (I still have to check which ones are needed), (6) update the scenarios and (7) merge the whole enchilada to the trunk.
After that there is still documentation to be written. Plus the Crawler has to be fixed/replaced/whatever.
There is still work to do on the meshes (OV, MLP and SRBs from what I can see). There is also the "hidden triangle" issue which we MUST fix... we just can't release, again, meshes in which 20-30% of triangles/vertices do absolutely nothing except eat performance/disk space.
I'd like to also have a VC which fits the OV, but that's gonna miss the train... :facepalm:
Donamy
Addon Developer
I've seen posts, of people who have compiled a working version in Orbiter 2016. Could we get a working shuttle for Orbit use only ?
Just moving the VC in the the mesh, would break the whole thing I assume.
Just moving the VC in the the mesh, would break the whole thing I assume.
It's not a question of moving it, it's making actually fit the exterior mesh. The VC was made for a incorrectly scaled exterior mesh so you can clearly see that the VC mesh doesn't fit anymore.
Here's two examples: https://www.dropbox.com/s/hkjz8z7otxs6rce/SSU_VC_alignment.jpg?dl=0
https://www.dropbox.com/s/ezvluwnaeddd2up/SSU_VC_alignment_2.jpg?dl=0
Pretty much. We adjust the offset of the meshes in the code. For the VC, the offset relative is this: 0.0, -1.32, -2.22. The problem as mentioned before isn't a offset issue but a scale issue. The VC is off in the Z-axis (longitudinal axis) as well as in the X-axis (lateral axis).
Not sure as GLS have been pretty good at separating each panel into its own entity which should have isolated them from the main VC. Not sure which panels remain as part of the main VC entity though as not all of them have been separated.
- Status
Similar threads
