SSU Development Thread (2.0 to 3.0)
- Thread starter Urwumpe
- Start date
- Status
SiameseCat
Addon Developer
If we're going to be breaking scenarios because the mesh is changing, I think we should just have one release with the final version of the mesh.
I don't see how a mesh change would break a scenario. After all, the data for the thrusters and animations are all in the C++ source code which the scenario never sees. A scenario doesn't care if the rotation point for an animation is at 4.5,6,9 or -8,2,14. All a scenario care about is the status.
---------- Post added at 03:58 PM ---------- Previous post was at 03:57 PM ----------
Looks good enough for a release.
SiameseCat
Addon Developer
I though you said (in post #601) that changing meshes would affect scenarios, because attachment points on payloads, etc. would have to be tweaked. If the scenarios aren't affected by the mesh changes, then we can release a version using the Rev. 1462 mesh.
That is easy enough to include in any patch releases, still transparent to scenarios. Scenarios are all about status, not the actual tech stuff like offsets. That's where the config files/modules come into play.
Donamy
Addon Developer
Not even close ! Looks pretty, but right now looking at the side hatch. The texture has it in the wrong position. Also, the parts have been seperated from their mirrored images, now they need to be renamed.Then need to go over the payloadbay, and make sure everything fits right.
Question for DaveS: How are the OMS pods ?
They should be fine, maybe a bit of lengthening.
---------- Post added at 04:47 PM ---------- Previous post was at 04:33 PM ----------
Seems like I spoke too soon. They're going to need work.
---------- Post added at 05:25 PM ---------- Previous post was at 04:47 PM ----------
After some working, the OMS pods is mod-able to fit the new orbiter model with a a tiny bit of tweaking to the aft compartment shoulders.
SiameseCat
Addon Developer
The MPS dump locations need to be fixed in the Mesh-Rev1463 branch. Apart from that, I think we're ready for a release using the old (Rev. 1462) mesh.
I would also appreciate it if someone could look at the code changes in the Mesh-Rev1463 branch, and make sure that I haven't removed any other changes while reverting the animation code to match the old mesh.
I would also appreciate it if someone could look at the code changes in the Mesh-Rev1463 branch, and make sure that I haven't removed any other changes while reverting the animation code to match the old mesh.
Looks good. Do you think you could add movable ET umbilical plates? When I fixed the ET meshes to be accurate just like the orbiter, I noticed that the in order to make the umbilical plates on the ET and orbiter actually connect to each other, movable umbilical plates are needed.
This is how it works on the real orbiter/ET. Once hardmate between the orbiter and ET is accomplished, the mating of the umbilicals begin. And one step in that procedure is extension of the umbilical plates on orbiter so that they physically contact the umbilical plates on the ET which are fixed.
Once that is done, bolts are installed on three locations on the actual plates which secures the plates together. Then the actual installation of the so called "monoballs" which are the electrical/data connections between the orbiter and ET can begin. The monoballs are part of umbilical plates.
Once MECO has been confirmed, one step in the pre-ET-sep sequence is retraction of the orbiter umbilical plates. If this fails for any reason, automatic ET-sep is inhibited. What the procedures are such a case, I do not know. I don't even know if is physically possible to separate the ET under those circumstances.
Well, the problem is that the visually the the umbilical plates doesn't connect anymore due the fact that we do not have movable umbilical plates on the orbiter.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I agree there. It doesn't help us now to get a release. It would be more interesting for ground integration work... and right now, I feel like this is secondary to a flying STS, even if it is a very important strategical goal of SSU.
Are the OMS thrusters gimballed yet? I am not sure if we ever added animations to them... :blush:
Also, the SSME animations could see some more testing, I am very sure that not everything is working fine right now.
To anybody, who is not programming for SSU and not sharing the programmers perspective: Anybody interested in writing a [ame="http://en.wikipedia.org/wiki/Test_plan"]test plan[/ame] and the test procedures for verifying that everything in SSU works as planned?
The test plans describe how things should get tested in general, like by which tools, and which kind of test is used for which situation, and how the workflow around and for testing looks like. The test procedures then are short and simple checklists that anybody should be capable of using for making sure that a feature in SSU operates as intended. Like "For preparation of the test, load test scenario xyz, and prepare the orbiter by going through the following steps. Then pressing button X should result in indication Y, also in the test data, the following behavior should appear".
This way, we can also avoid annoying arguments about which behavior is wrong or not. The reference is then the test document, and if this test document is not like the real shuttle, we can discuss the intended behavior directly.
GLS
Well-known member
When I was working on the SSME gimballing I noticed the GOX vents have some sort of association with the nozzle animation, so the vent is always in the correct place. Could something like that be crafted for the SSME LOX dump?
Yes, vent doors would be way first on the list.
Don't think the OMS are gimballing ATM. OMS/RCS is something I'm planning to improve, this of coarse after the mission-planner-thing-that-I-keep-forgetting-the-name. :lol:
I think the SSME animations look good (at least in the old... new... errmm... whatever mesh was available in the summer). The only thing I can point out is that maybe they gimbal too much during the roll maneuver... could the SSME "gimbal gains" be too high during 1º stage?
SiameseCat
Addon Developer
The SSME animations (using the Rev. 1462 mesh) look fine to me.
GLS: Look at the UpdateSSMEGimbalAnimations functions in Atlantis.cpp. Every time the SSMEs gimbal, the GOX vent positions are updated.
---------- Post added at 02:51 PM ---------- Previous post was at 12:20 PM ----------
According to the SCOM, the shuttle is 122.2 ft (37.24656 m) long. The newest version of the mesh (Rev. 1819) is 37.021 m long. Is the SCOM wrong, or is the new mesh too small?
GLS: Look at the UpdateSSMEGimbalAnimations functions in Atlantis.cpp. Every time the SSMEs gimbal, the GOX vent positions are updated.
---------- Post added at 02:51 PM ---------- Previous post was at 12:20 PM ----------
According to the SCOM, the shuttle is 122.2 ft (37.24656 m) long. The newest version of the mesh (Rev. 1819) is 37.021 m long. Is the SCOM wrong, or is the new mesh too small?
The SCOM is wrong. The SODB has the aft tip of the vertical stabilizer (the aft-most element of the orbiter) at 1693 inches. Subtracting 236 from that number (236 inches is where the forward-most tip of the nosecap is) gives us 1457 inches of total length. Converting that to meters gives 37.0078.
So in fact it is too long by almost 1 inch.
- Status
