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

[DaveS]

Looking at a center segment, the part of the cable tray that is inside the segment could be deleted, which would gain 8 triangles. Another 96 could be gained with similar work in the cable tray "belts". This seems like pennies, but it would be about 10% of that mesh.
One thing I noticed is that the propellant top and bottom disks are not concentric (or mishaped) and are visible on the outside.
Do I work this?

Are you sure that the Orbitersimbeta branch uses the same RSRM meshes as the trunk? I just checked and everything is fine here, no misalignments or shapings here.

 

[GLS]

Are you sure that the Orbitersimbeta branch uses the same RSRM meshes as the trunk? I just checked and everything is fine here, no misalignments or shapings here.

Given that I merged the trunk to the Orbitersimbeta branch 9 days ago, I'd say that yes I'm using what is in the trunk. But I'll check anyway.

---------- Post added at 05:34 PM ---------- Previous post was at 05:26 PM ----------

Yep, the trunk matches the branch. The file is RSRM_LSRB_aft_center_segment.msh
It also has the inside faces of the field joints with flipped normals. I've fixed that, but I'm having trouble saving, as there is something wrong with them (also on the original mesh).

---------- Post added at 05:54 PM ---------- Previous post was at 05:34 PM ----------

All fixed now! Savings: ~17% vertices, ~11 triangles.
Shall I continue with the other segments?

 

[DaveS]

Given that I merged the trunk to the Orbitersimbeta branch 9 days ago, I'd say that yes I'm using what is in the trunk. But I'll check anyway.

---------- Post added at 05:34 PM ---------- Previous post was at 05:26 PM ----------

Yep, the trunk matches the branch. The file is RSRM_LSRB_aft_center_segment.msh
It also has the inside faces of the field joints with flipped normals. I've fixed that, but I'm having trouble saving, as there is something wrong with them (also on the original mesh).

---------- Post added at 05:54 PM ---------- Previous post was at 05:34 PM ----------

All fixed now! Savings: ~17% vertices, ~11 triangles.
Shall I continue with the other segments?

Negative. I almost got all the segments done. I just have the FWC motor segments left.

 

[GLS]

Negative. I almost got all the segments done. I just have the FWC motor segments left.

But the RSRM meshes were done, right?

 

[DaveS]

But the RSRM meshes were done, right?

I corrected some minor issues and dealt with the inverted normals of the field joints.

 

[GLS]

I corrected some minor issues and dealt with the inverted normals of the field joints.

OK, then it was a waste of time for me to look at meshes that have changed... :facepalm: This is why things should be committed as the get done.

Going back to the begining: are these meshes unchanged?
EDO_pallet.msh
DFI_pallet.msh
Centaur_Mission_Kit_plumbing.msh

 

[DaveS]

OK, then it was a waste of time for me to look at meshes that have changed... :facepalm: This is why things should be committed as the get done.

Going back to the begining: are these meshes unchanged?
EDO_pallet.msh
DFI_pallet.msh
Centaur_Mission_Kit_plumbing.msh

No. I'll handle the meshes, not many left. The Centaur stuff is done, only the IUS elements and the ETs remain.

 

[GLS]

No. I'll handle the meshes, not many left. The Centaur stuff is done, only the IUS elements and the ETs remain.

Why not commit them then? :shrug:
If there are no meshes for me then I think I'll take a vacation. :goodnight:

 

[DaveS]

Quick question: Does SLC-6 have malformed terrain for you too in the Orbiter beta? It's looks alright in the release version but it's all malformed in the beta version.

This is what I get: https://www.dropbox.com/s/jdbamh8ehkyru0k/SLC6_beta.jpg?dl=0
And this is how it is supposed to look: https://www.dropbox.com/s/d7s213au13yhf8i/SLC6_release.jpg?dl=0
(Exactly the same scenario and terrain files). It isn't an D3D9Client thing as the inline engine has it the same.

 

[Abdullah Radwan]

I've successfully implemented XRSound. OrbiterSound4 is no longer needed. But I have a question: What's the equivalent to 'Default' in XRSound? Currently, I have them set based on the machine (SSME is BothViewFar, APU is BothViewClose, etc). Is this correct?

 

[DaveS]

The mesh work is going a bit slower than I thought. Some of the meshes are pretty complex and needs pretty much a complete overhaul due to their age and methods of creation to get rid of hidden triangles. Currently, I'm working on the various payloads we include by default in SSU as per the ticket they are considered long-life items. Something that we might want to look into is how to handle SpaceHAB/SpaceLab missions as both modules were heavily integrated elements with the orbiter. Both had dedicated panels on both the flight deck and mid deck. SpaceHAB was also special in that it had the ability to carry the two X_O576 bulkhead CCTV cameras (A/D) on platforms on its aft bulkhead. At least two missions did this, STS-95 where both cameras were relocated to the SpaceHAB aft bulkhead and STS-107 where camera D was relocated to the SpaceHAB aft left bulkhead platform.

GLS, maybe you could go ahead and deal with the pad items?

 

[GLS]

The mesh work is going a bit slower than I thought. Some of the meshes are pretty complex and needs pretty much a complete overhaul due to their age and methods of creation to get rid of hidden triangles. Currently, I'm working on the various payloads we include by default in SSU as per the ticket they are considered long-life items. Something that we might want to look into is how to handle SpaceHAB/SpaceLab missions as both modules were heavily integrated elements with the orbiter. Both had dedicated panels on both the flight deck and mid deck. SpaceHAB was also special in that it had the ability to carry the two X_O576 bulkhead CCTV cameras (A/D) on platforms on its aft bulkhead. At least two missions did this, STS-95 where both cameras were relocated to the SpaceHAB aft bulkhead and STS-107 where camera D was relocated to the SpaceHAB aft left bulkhead platform.

GLS, maybe you could go ahead and deal with the pad items?

That ship has sailed last week and I don't know when it will be back.
Maybe the fat in the VAB, OTS, and other ground stuff isn't a priority as they aren't always in view, but the pad sure is, so that really has to be worked. Same for any OV related mesh (RMS, A/L, ET, etc...).


As for the SpaceLab/SpaceHAB thing, I'd prefer (at least for now) to consider those "payloads", thus not our problem, and maybe focus on something for "dynamic" like the PAMs of the SPDS... or finishing the Centaur and IUS. :shrug:

 

[Wolf]

Guys out of curiosity (please don't yell at me, this is not in any way a criticism) are you following a priority list in the SSU developement? I am asking since I have the impression that we proceed a bit randomly on different fronts (and god knows how many they are when it comes to such a complex addon) instead of focusing on one thing at a time.
Again this is my impression since I have been following the developement pretty much from the beginning BUT I might be totally wrong.
For example, why concentrating on payloads and/or very little details (like the payloadbay doors mechanism) when some major features/functionalities of the Orbiter are still missing or need fine tuning?
Sorry again if this sounds like a stupid question or even inappropriate, I am just trying to understand, no criticism at all here

 

[Urwumpe]

Guys out of curiosity (please don't yell at me, this is not in any way a criticism) are you following a priority list in the SSU development?

This project is not following just one priority list, but actually many.

Interpret this as a loudly yelled "Yes, you name it."

 

[GLS]

Guys out of curiosity (please don't yell at me, this is not in any way a criticism) are you following a priority list in the SSU developement? I am asking since I have the impression that we proceed a bit randomly on different fronts (and god knows how many they are when it comes to such a complex addon) instead of focusing on one thing at a time.
Again this is my impression since I have been following the developement pretty much from the beginning BUT I might be totally wrong.
For example, why concentrating on payloads and/or very little details (like the payloadbay doors mechanism) when some major features/functionalities of the Orbiter are still missing or need fine tuning?
Sorry again if this sounds like a stupid question or even inappropriate, I am just trying to understand, no criticism at all here

Well, I can only speak for myself: currently my number 1 priority is finishing the aero stuff so we can handle landings on runways at any elevation, thus making SSU compatible with Orbiter 2016, so we can finally release SSU 5.0. These changes make a GRTLS very possible to do, and I'd really like to see it happen, but currently that isn't a real pressing need, so I'm not working in that direction.
Other items on my list for SSU 5.0 are cleaning up the meshes (at least the most used ones), and fixing the Crawler.
After that I'd like to put the MEDS VC to rest and allow a MCDS VC in the future, get SSU Workbench working to manage missions, work the ascent guidance and DAP (which would pave the way for aborts, probably by SSU 19.0 :uhh, and also work the Orbit DAP to allow it to point the vehicle in ANY direction, as the real one did.

 

[Donamy]

Certain meshes need to be finalized, and "Hands Off !" IMO.

 

[Urwumpe]

Certain meshes need to be finalized, and "Hands Off !" IMO.

At least, they should be final for a long enough period of time. The project lacks something like an "approval process" for changes.



What about including only meshes, that are mostly done, at the start of a new version cycle? And then use the early work in the new version for fixing only bugs with the meshes, until they can be considered final? And then keep them fixed until the release is done.

 

[Wolf]

Certain meshes need to be finalized, and "Hands Off !" IMO.

I second this

 

[DaveS]

So as part of the mesh clean up, I decided to finish up the brand new ODS. There's just one problem, I can't get the ball screws to animate properly. I end up with this: https://www.dropbox.com/s/arje6s0pr4lh07x/New_ODS_2.jpg?dl=0

I checked the reference positions as well as the axes and everything is fine. There is two things I don't understand though and those are ACT_DIRs and the ODS_ROD_ROTATION. Could someone refresh my memory on these?

 

[GLS]

Added Smart Speed Brake logic to Autoland Guidance, so touchdowns should be a bit more precise, even with wind, although the Density Altitude effects aren't being calculated as I don't have enough info on how to calculate it... :shrug: