SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
GLS
Well-known member
Started looking at the mesh, and noticed a very obvious step in the right wing, behind the top end of the RCC. As that wasn't there, and there was a mapping issue noted in that area, it looks like points were moved around to fix mapping.... something that I thought was well established to be "the wrong way".
GLS
Well-known member
Thanks alot... I said I was going to edit the mesh myself.
GLS
Well-known member
A lot of the vertices are not simmetrical, but actually shifted 6.015mm to the port side... any reason?
BTW: not asking for changes.
BTW: not asking for changes.
GLS
Well-known member
Like the romans said divide and conquer!
DaveS, the windows have 2 issues: (1) they are not flat (they probably should be), and (2) the overhead windows make the Orbiter appear to have a sunroof, so they need to be corrected. This can be done just by editing the FUSELAGE and windows groups, so I'll not touch those for now, and you don't touch the rest, otherwise hours of work are easily lost.
Also, when you are done, please copy the edited groups into the original mesh file, so that only the edited groups change, thus making the merging of versions possible and also not requiring a new meshres.h file to be generated. Notepad++ works well in editing large text files like the mesh.
DaveS, the windows have 2 issues: (1) they are not flat (they probably should be), and (2) the overhead windows make the Orbiter appear to have a sunroof, so they need to be corrected. This can be done just by editing the FUSELAGE and windows groups, so I'll not touch those for now, and you don't touch the rest, otherwise hours of work are easily lost.
Also, when you are done, please copy the edited groups into the original mesh file, so that only the edited groups change, thus making the merging of versions possible and also not requiring a new meshres.h file to be generated. Notepad++ works well in editing large text files like the mesh.
GLS
Well-known member
Pretty much all PLBD latches collide with the radiators... which one is wrong: latches or radiator gaps?
Also, the curved surfaces at the radiators fwd and aft ends don't match the inner and outer surfaces, which looks bad and wastes triangles.
Also, the curved surfaces at the radiators fwd and aft ends don't match the inner and outer surfaces, which looks bad and wastes triangles.
GLS
Well-known member
Are the coordinates in the OrbiterCoordinates_SSU_Converter.xls file correct? Of so, then the aft compartment might not be in the correct place and/or have the correct size. I corrected the body flap (only missing data on the fwd end and vertical profile, so left those as is), and it is a bit aft from what it currently is, which leaves a gap, which means more work... :facepalm:
I'm beginning to entertain the idea of putting the current mesh in a branch for "repairs", and reverting to the SSU 4.2 version in the trunk, so we can release 5.0 in the foreseeable future.
---------- Post added 07-16-19 at 12:14 AM ---------- Previous post was 07-15-19 at 10:42 PM ----------
Scratch that... just compared them and the current mesh, even with its flaws, is much better than the 4.2 one. Looks like forward is the way.
I'm beginning to entertain the idea of putting the current mesh in a branch for "repairs", and reverting to the SSU 4.2 version in the trunk, so we can release 5.0 in the foreseeable future.
---------- Post added 07-16-19 at 12:14 AM ---------- Previous post was 07-15-19 at 10:42 PM ----------
Scratch that... just compared them and the current mesh, even with its flaws, is much better than the 4.2 one. Looks like forward is the way.
GLS
Well-known member
It's not needed on my end at the moment, as I'm still working == nothing to commit, but I can't access the SVN repo (and also the Orbiter Beta).
The zero values should be correct. What coordinates are you using for the aft compartment? Mine came from the latest Jenkins shuttle book, Vol II - Technical Description, page II-52. There it is listed as Xo1307 to Xo1463 at the top, Xo1307 to Xo1516 at the bottom. Height is listed as going to Zo500 at Xo1307 and Zo517 at Xo1463. The X-axis measurements does include the body flap hinge structure at the back as well as the Xo1307 bulkhead. The midbody only had the floor and sidewalls, the two bulkheads were part of the forward fuselage and aft compartment respectively.
Last edited:
kuddel
Donator
- Joined
- Apr 1, 2008
- Messages
- 2,064
- Reaction score
- 507
- Points
- 113
Did you notice the change for the repo URLs?
You might have to relocate your working copy.
https://www.orbiter-forum.com/showthread.php?p=595280&postcount=6
GLS
Well-known member
In both Aerodynamic Data books, the body flap hinge line is Xo1532, the TE is at Xo1613, and the width at the TE is 220in. The bottom end of the body flap, below the hinge line is Zo276.4.
The elevon hinge is at Xo1387, which indicates there is no "lateral angle" to it, just vertical.
Can anyone post what do we have to do exactly to reset SVN for SSU?
I've read this
https://www.orbiter-forum.com/showthread.php?t=40857
but could not figure out how to do that
Tks
I've read this
https://www.orbiter-forum.com/showthread.php?t=40857
but could not figure out how to do that
Tks
GLS
Well-known member
On the root folder of the repo, hold the shift key and right-click in it, TortoiseSVN menu >> Relocate... >> input new address.
GLS
Well-known member
In addition to working the meshes, I'm also slowly writing about a section on the Crawler for the manual, somewhat based on the original Crawler "manual", which has:
Should G CIRC just turn one end? (actually makes sense... "great circle")
And for tight turns the INDEP mode would be used with another driver in the read cab?
which makes me wonder if I implemented things wrong. I made the INDEP mode such that each cab controls it's end (even if not selected), and the G CIRC mode turns both ends to turn as sharply as possible, as opposed to just turning one end as indicated in the original text.
Should G CIRC just turn one end? (actually makes sense... "great circle")
And for tight turns the INDEP mode would be used with another driver in the read cab?
Based on the documentation I have, you have things correct in that in Great Circle and Crab modes, one driver controls the trucks on both ends. But in the Independent mode, each drive truck set is linked to the cab on that particular end. So in Independent, the End 1 trucks can set to -2.87°s while the End 3 trucks are at +4.35° for example.
But in Great Circle and Crab modes, they're going to be the same, except for positive and negative angles.
I've attached a document I received in 2015 on the Crawler steering modes.
Mission file question: Is the use of AftTAA not implemented or am I doing something wrong? I'm trying to set up an STS-95 mission file but I can't seem to get the TAA to show up. For STS-95 the forward payload bay configuration was airlock in bays 1/2, TAA in bays 3/4 and SpaceHAB in bays 5/6, so I need the TAA to be aft of the external airlock.
GLS
Well-known member
HasTAA=TRUE
Currently it CTDs, as you changed the name of the mesh used in the aft position (we only have one mesh so it was used for both positions, but now the aft position is targeted to a non-existing mesh).
BTW: if the extra-stuff in the aft TAA is "addon" to the fwd TAA, then it should all be in one mesh, and things hidden as needed.
- Status
Similar threads
