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

Status
Not open for further replies.

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
Decided to go down to the middeck and noticed a few things: 2 escape poles and 6 seats (both appear to be in the stowed and deployed positions), only one vc position that doesn't show much and no internal airlock.

I think we could add a "Crew" parameter to the mission file and based on that decide how many seats there should be (and in the future the mass of consumables). Stowing or deploying them could be done with a middeck-only dialog. For now I don't even want to consider long-duration-crew-seats on the floor or extra seats for rescue missions, just the "standard" 7 seats (or less).
The escape pole would probably need a mission parameter to have it installed or no, and that would also add its extra mass to the vehicle. Stowing/deploy it would also be in the dialog.
Parameters to decide whether the airlock is there or not already exist, so that's a mesh to load as needed.
To control this, a new Middeck subsystem should be created, and it would handle the seats config and maybe even stow/deploy animations.

It seems a nice thing to work in a branch and then release in one of the 5.x releases. :thumbup:
Meanwhile I think one of the two sets of pole+seats should be deleted from the mesh, as that is loaded when the user is in the vc, so that is another thing competing for FPS... :shrug:
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
Just deleted the duplicate seats and escape pole from the middeck mesh in the trunk (that's 25% of that mesh gone, so better performance in the vc) and created a middeck branch for the work outlined in the post above (and ticket #201).

Another idea I'm considering is a hack to allow the SM displays. It would be a similar hack to the BFS display switches that would show, e.g., GNC 201 display or the SM 201 display based on the Major Function switch position.
This would only work in-orbit (OPS 2), so that already limits the amount of screw-ups that can happen. :shifty: In terms of code, I think most of it is "reusable" for a future multi-thread GPC implementation, the major difference is that now it is all combined in our single GPC implementation. :shrug:
With a bit more thinking, this could be another intermediate 5.x release.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I've been working on the new RCS for SSU 98.0 :)shifty:), and I'm not sure the positions of the FRCS nozzles are correct (the shapes aren't). I found very useful info on the nozzle positions and orientations on the SODB, page 4.3.2-71. For the graphics department, only the "Thruster mount attach" columns and the data at the bottom of the table are needed (that's position and orientation), and the rest of the table is for me... :dry:
I'm somewhat surprised that most of the nozzle orientations are so "well behaved", i.e., aligned with a plane.
So, as the basic RCS nozzle shape is the same for all of them, it's a question of creating a cone (the nozzle) with the correct aperture, put a disk on the small end (the injector), and then replicating that, rotating to the correct orientation and placing the center of the disk at the coordinates. Finally the hard part: figuring out where is the vehicle OML to then cut the nozzle so it doesn't stick out of the OML. The table has some info of where the nozzle ends, but that seems more oriented towards the physical effects than to the actual shape, as it simplifies the radial component. Still those are probably good ball park numbers as to where the cut is.

I'm mentioning this now, because it would be a shame to have to re-work, again, the OV mesh in the future to fix the nozzle positions and orientations, and then have to fix the textures, again.
This has been dealt with in r3228, for now only in the omsrcs branch. The trunk mesh is unaffected by these changes.

---------- Post added at 03:07 AM ---------- Previous post was at 03:04 AM ----------

Another idea I'm considering is a hack to allow the SM displays. It would be a similar hack to the BFS display switches that would show, e.g., GNC 201 display or the SM 201 display based on the Major Function switch position.
This would only work in-orbit (OPS 2), so that already limits the amount of screw-ups that can happen. :shifty: In terms of code, I think most of it is "reusable" for a future multi-thread GPC implementation, the major difference is that now it is all combined in our single GPC implementation. :shrug:
With a bit more thinking, this could be another intermediate 5.x release.
This is something I would be happy to see implemented, especially for STS-1 where the PLBD ops were done in the manual mode rather than the auto mode.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
This has been dealt with in r3228, for now only in the omsrcs branch. The trunk mesh is unaffected by these changes.
Well... it's not right... :facepalm:
You should read the table/figure 4.3.2-39 again. For example, R1R has the thruster mount in the correct place, but the "cut plane" is too much inboard.
Also, the FxD nozzles don't have the correct shape, and they are not angled correctly (just 37º outboard, nothing fwd or aft). Others are probably tilted when they shouldn't... the table is quite explicit in indicating the few that are not aligned with the XYZ axis, and what angles they have. :shrug:
The ARCS and FRCS nozzles for some reason have different sizes, and there are no VRCS nozzles

Another thing: do we really need over 29K vertices and 50K triangles for this??? A simple cone with a cap on top wasn't enough??? This change alone increased the total mesh size by over 20%!!!!


This is something I would be happy to see implemented, especially for STS-1 where the PLBD ops were done in the manual mode rather than the auto mode.
The word is not implemented, but hacked. Implementation would require more than 1 GPC (and 2, 5 or 50 GPCs is the same), with all the logic to handle FC bus commanding, NBATs, MCs and all the inter-GPC interactions... and IMO it's not SUPER hard to do, but it would take quite some time, especially in isolating the GPCs from Orbiter, as they would have to be executing in their own threads. Everything I do in the GPCs now, I try to maximize the use of the busses (only one for now) to at least not add more external dependencies so that in the future that separation is as easy as possible.
Plus, one thing is "allowing" the displays, another is wiring the MDMs to the subsystem and then adding logic in the GPCs to do things.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Well... it's not right... :facepalm:
You should read the table/figure 4.3.2-39 again. For example, R1R has the thruster mount in the correct place, but the "cut plane" is too much inboard.
Also, the FxD nozzles don't have the correct shape, and they are not angled correctly (just 37º outboard, nothing fwd or aft). Others are probably tilted when they shouldn't... the table is quite explicit in indicating the few that are not aligned with the XYZ axis, and what angles they have. :shrug:
The ARCS and FRCS nozzles for some reason have different sizes, and there are no VRCS nozzles

Another thing: do we really need over 29K vertices and 50K triangles for this??? A simple cone with a cap on top wasn't enough??? This change alone increased the total mesh size by over 20%!!!!
Simplified and made the primary nozzle sizes uniform between the FRCS and ARCS. Also corrected the angles on the four FRCS downward firing jets. And as far as shape is concerned, I made them from an actual photo of the F3D nozzle on Atlantis. Verified the shape with the Discovery Recordation Package drawings.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
It took all night but the SILTS pod have been fixed. No more gaps between it and the vertical stabilizer. I also fixed few more issues that involved some of the vertices/normals of the main SILTS pod mesh.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
It took all night but the SILTS pod have been fixed. No more gaps between it and the vertical stabilizer. I also fixed few more issues that involved some of the vertices/normals of the main SILTS pod mesh.

The front looks very good, but the rear end is missing faces or not lined up with the tail. Also, the material should match the rest of the vehicle.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
The front looks very good, but the rear end is missing faces or not lined up with the tail. Also, the material should match the rest of the vehicle.
Thanks for letting me know, I was a bit too worn out to check the rear of the SILTS pod. I've redone this part as well as made some changes to the vertical stabilizer for a better fit between the two. I also added the quarter-circle transition between the actual pod and the vertical stabilizer.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
Thanks for letting me know, I was a bit too worn out to check the rear of the SILTS pod. I've redone this part as well as made some changes to the vertical stabilizer for a better fit between the two. I also added the quarter-circle transition between the actual pod and the vertical stabilizer.

Half-step backwards:
- the new flanges are duplicated (one of them +/- hovering above the other);
- there are also 2 triangles when only one is needed, below the center of the fwd dome;
- the 2 tails are different;
- looking at photos, I think the first slope down from the top aft end of the tail should be more vertical with the pod, than without it;
- and hidden triangles at the bottom of the fwd dome.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Half-step backwards:
- the new flanges are duplicated (one of them +/- hovering above the other);
- there are also 2 triangles when only one is needed, below the center of the fwd dome;
- the 2 tails are different;
- looking at photos, I think the first slope down from the top aft end of the tail should be more vertical with the pod, than without it;
- and hidden triangles at the bottom of the fwd dome.
Could you provide images of points 3 and 4?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
Could you provide images of points 3 and 4?
I was going to post these, where it's visible the difference in the top aft area (round and then flat downward, instead of 2 sharp transitions)....
atlantis-fin1.jpg

H3TQM.jpg

... but then decided to look at what Columbia looked before the SILTS pod...
STS-1_Approach.jpg

... and it was already like that. :facepalm:
KSC delivery photos (when it didn't had the "black tip") also have the same design. The next OV built had the "modern" tail:
61a-s-0139.jpg


So, Columbia had a different tail end, which would probably require a specific tail (and code to handle 3 tails), which IMO is not a priority, so this info should be dumped in a ticket and for now lets leave the aft end of the tail as we have it, as it's correct for 80% of the fleet. :shrug:

On the tails being different, in the last rev. mesh changes where made to one tail but not the other. This would be (also) in the top aft end: the sides are wider in one of them... don't know which one was changed, or which one is correct. The only differences between those 2 tails should be at the bottom: drag chute vs no drag chute.
If this is related to the topic above, then go for the 80% now and leave the Columbia-specifics for a later version.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
GLS: Are you sure about the differences in the two vertical stabilizer meshes? I just checked and other than the drag chute mods, they're identical. So I don't know what's going on here. I've attached a screenshot showing what I modified, it was the encircled vertex and it's counterpart on the other side and nothing else. All I did was thicken the area that those controls for a better fit with the SILTS pod.
 

Attachments

  • VertStab_modified_vertex.jpg
    VertStab_modified_vertex.jpg
    148.9 KB · Views: 243

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
GLS: Are you sure about the differences in the two vertical stabilizer meshes? I just checked and other than the drag chute mods, they're identical. So I don't know what's going on here. I've attached a screenshot showing what I modified, it was the encircled vertex and it's counterpart on the other side and nothing else. All I did was thicken the area that those controls for a better fit with the SILTS pod.

If you walk aft from the marked vertex to the next one, and then up to the one in the HRSI, that is the one that is "sunk in" in the original tail (x=0.028217m) and "raised" in the drag chute tail (x=0.06485m). Don't know which one is correct.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Is is the vertex encircled in yellow?
 

Attachments

  • VertStab_faulty_vertex.jpg
    VertStab_faulty_vertex.jpg
    124 KB · Views: 242

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Fixes for the original vertical stabilizer (it was the incorrect one) and the SILTS pod have been checked in.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
Tails are now OK. :thumbup:
A few small SILTS pod issues:
- one extra triangle on each side, inside the fwd dome, where it meets the bottom end;
- another set of extra triangles on each side, in aft end of the side faces of the pod;
- also, that area has a gap to the tail on both sides.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Tails are now OK. :thumbup:
A few small SILTS pod issues:
- one extra triangle on each side, inside the fwd dome, where it meets the bottom end;
- another set of extra triangles on each side, in aft end of the side faces of the pod;
- also, that area has a gap to the tail on both sides.
R3236 should take care of these last issues.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I've been having a bit of thinking here, running a real-time scenario of STS-107. I've noticed that sometimes the MET is off from what it should be. Currently it is set as an absolute variable when it really should be a relative variable in this case, relative to a specific T0. Could this be done for 5.0? It would very much be like what we have implemented for the LCC right now. And it would be more realistic as proven by STS-1, the MET was reset to exactly 0 when the boosters lit. (remember, STS-1 lifted off 4 seconds after the actual T0 and was in positive T count when lift-off happened)
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,871
Reaction score
2,868
Points
188
Website
github.com
I've been having a bit of thinking here, running a real-time scenario of STS-107. I've noticed that sometimes the MET is off from what it should be. Currently it is set as an absolute variable when it really should be a relative variable in this case, relative to a specific T0. Could this be done for 5.0? It would very much be like what we have implemented for the LCC right now. And it would be more realistic as proven by STS-1, the MET was reset to exactly 0 when the boosters lit. (remember, STS-1 lifted off 4 seconds after the actual T0 and was in positive T count when lift-off happened)

Actually, MET is a counter (well, several) that gets started at T0. I'm not sure of the RSLS specifics, but I'm pretty sure the STS-1 countdown was targeted to the "first T0", that's the GMTLO variable, but they had an extra delay inserted for SRB ignition (2.77s I think), and only when that happens does MET start counting (similarly the Event Timer gets a signal to reset). GMTLO is not used after that (it is not used after ME-3 ignition actually) and the MET is just a counter that gets incremented (so is GMT).
Now, NASA wasn't thinking about us when they did that. :lol: Plus, our current MET counter is "out in the open", being used by everybody, which is not very correct. I'm sure realtime scenarios also "break" other things, as most if not all timers in subsystems and GPC sw, plus animations, are absolute. Another issue with those scenarios is that consumables don't go down. So all things considered, I'm not sure how much sense it makes to fully support those scenarios...? :shrug:

Anyway, the code is frozen for SSU 5.0, except for minor changes and bug fixes.
 
Status
Not open for further replies.
Top