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

[Urwumpe]

Maybe not formally... :uhh: I'll start with function arguments, and go from there.

Don't be too formal there, we are developing "serious games" not life-support systems. :lol:

 

[GLS]

About the obsolete API calls: I would suggest fixing the query calls by adding abstract data sources and inject suitable Orbiter API data sources for them.

e.g. "AbstractAirDataSource" and "Orbiter2016AirDataSource". This way we can get a step closer to test our code by unit tests and are easier able to fix things for future releases.

Not sure if this would introduce a lot of overhead, but how about adding a class to libUltra containing functions with the same name as the ones in the oapi, i.e. wrappers where we can add checks (if needed)?
Each instance of this "WOAPI" (wrapper OAPI) class would be owned by a vessel, to handle the VESSEL class functions, and it would also contain the oapiXYZ functions. For example, the upgrade in a subsystem would be like:

STS()->SetAnimation( anim, pos );// old
STS()->woapi->SetAnimation( anim, pos );// new

It might not really make it easier when the oapi changes, but it probably won't make it harder.

 

[Urwumpe]

Not sure if this would introduce a lot of overhead, but how about adding a class to libUltra containing functions with the same name as the ones in the oapi, i.e. wrappers where we can add checks (if needed)?
Each instance of this "WOAPI" (wrapper OAPI) class would be owned by a vessel, to handle the VESSEL class functions, and it would also contain the oapiXYZ functions. For example, the upgrade in a subsystem would be like:

STS()->SetAnimation( anim, pos );// old
STS()->woapi->SetAnimation( anim, pos );// new

It might not really make it easier when the oapi changes, but it probably won't make it harder.

Well, this violates interface segregation principle.

It is a valid, working solution, as you describe, but it means technical debt adding to the lava cake we already have, which means development will slow down more in the end.

Just see the origin of the concept, why I am suggesting caring about it, because we already have it:

The ISP was first used and formulated by Robert C. Martin while consulting for Xerox. Xerox had created a new printer system that could perform a variety of tasks such as stapling and faxing. The software for this system was created from the ground up. As the software grew, making modifications became more and more difficult so that even the smallest change would take a redeployment cycle of an hour, which made development nearly impossible.

The design problem was that a single Job class was used by almost all of the tasks. Whenever a print job or a stapling job needed to be performed, a call was made to the Job class. This resulted in a 'fat' class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.

 

[GLS]

Well, this violates interface segregation principle.

It is a valid, working solution, as you describe, but it means technical debt adding to the lava cake we already have, which means development will slow down more in the end.

Just see the origin of the concept, why I am suggesting caring about it, because we already have it:

:facepalm:

I think I'll do something fun like write things in the manual....:dry:

 

[Urwumpe]

:facepalm:

I think I'll do something fun like write things in the manual....:dry:

Trust me... you would want to write a manual about maintaining the Atlantis class soon otherwise. :lol: And actually, I wanted to get rid of the VESSEL-interface from the components when possible, so we can finally use Unit tests without needing to link Orbiter at runtime.

 

[GLS]

It's fairly obvious....

Not so obvious is the orange material being visible between the PLBD and the side fuselage.

 

[DaveS]

It's fairly obvious....

Not so obvious is the orange material being visible between the PLBD and the side fuselage.

I'm working the issue. It's a tricky one.

 

[GLS]

I think there are still a few tiny details not right, aft of W1 and W6.
The PLBD issue still remains. It looks like they're placed inboard in relation to the sidewall fuselage.

 

[DaveS]

I think there are still a few tiny details not right, aft of W1 and W6.
The PLBD issue still remains. It looks like they're placed inboard in relation to the sidewall fuselage.

Those issues will remain until I have completed my new textures. They're going to be twice the current resolution (4096x4096 vs 2048x2048), this to enable a bit more detail. I'm currently working on the original Columbia/Challenger textures.

Could you show where the PLBDs are off? I can't see anything wrong with them in the mesh. There was a tiny (5 mm) gap in the vertical axis between the midbody and the doors but that has been addressed now. Lateral and longitudinal axes all line up nicely.

 

[GLS]

The PLBD issue is visible in the image I posted above (yes, it's not a BIG thing, but it's noticeable due to the contrast between orange and white). It looks like the PLBD don't line up with the side fuselage, as when seem from the angle of the image above, the orange is visible, but when looking from a bit below the nose, the orange is not visible.

 

[GLS]

How are we going to proceed in relation to VAFB? I think we should "shallow" the usonian's VAFB addon that we currently require, so we can adapt it to Orbiter 2016. Then there are a few more questions on how to proceed, given that SLC-6 is in a hilly area and currently the mesh also has terrain: Do we need to flatten the ground where the SLC-6 vessel sits? Dig holes for the flame trenches? If so, then we might need higher resolution elevation data, as at the current level 15 the pad area is maybe 3x2 pixels...

 

[DaveS]

How are we going to proceed in relation to VAFB? I think we should "shallow" the usonian's VAFB addon that we currently require, so we can adapt it to Orbiter 2016. Then there are a few more questions on how to proceed, given that SLC-6 is in a hilly area and currently the mesh also has terrain: Do we need to flatten the ground where the SLC-6 vessel sits? Dig holes for the flame trenches? If so, then we might need higher resolution elevation data, as at the current level 15 the pad area is maybe 3x2 pixels...

It certainly needs flattening in the areas where the SLC's are as well as the airfield and orbiter processing area. The problem is that I don't know how to do that. So for now, west coast launches/landings are out.

 

[GLS]

It certainly needs flattening in the areas where the SLC's are as well as the airfield and orbiter processing area. The problem is that I don't know how to do that. So for now, west coast launches/landings are out.

The last few days I've been learning about the elevation stuff and Face's OT3 tools, and I think I can move mountains now. :lol:
In my view, the problem is that if the elevation data is of too low resolution, the results might not be good when the runway is not N-S or E-W (which is always) and the sides of the runway will be "serrated" elevation-wise. But that should only be a problem if there are big elevation changes between the ends of the runway.
Looking at the SLC-6 mesh, maybe flattening the area there, and keeping the pad vessel terrain mesh (unchanged or modified) is the way to go.

---------- Post added at 06:52 PM ---------- Previous post was at 03:46 PM ----------

Currently there's a difference in how we treat VAFB files vs KSC files (Meshes and Textures). The KSC stuff is inside the SSU folders, but the VAFB stuff has its own folder outside our SSU folder. Any preferences on how to standardize this? I vote to put everything inside the SSU folders.

 

[DaveS]

The last few days I've been learning about the elevation stuff and Face's OT3 tools, and I think I can move mountains now. :lol:
In my view, the problem is that if the elevation data is of too low resolution, the results might not be good when the runway is not N-S or E-W (which is always) and the sides of the runway will be "serrated" elevation-wise. But that should only be a problem if there are big elevation changes between the ends of the runway.
Looking at the SLC-6 mesh, maybe flattening the area there, and keeping the pad vessel terrain mesh (unchanged or modified) is the way to go.

---------- Post added at 06:52 PM ---------- Previous post was at 03:46 PM ----------

Currently there's a difference in how we treat VAFB files vs KSC files (Meshes and Textures). The KSC stuff is inside the SSU folders, but the VAFB stuff has its own folder outside our SSU folder. Any preferences on how to standardize this? I vote to put everything inside the SSU folders.

This was to keep compatibility with the outside add-on (VandenbergAFB 2006). If we're going to include it anyway, I say we should move everything inside the main SSU folders.

 

[Donamy]

Which attachments correspond with the payload latch controls in the aft station ?

 

[GLS]

Which attachments correspond with the payload latch controls in the aft station ?

Those are the active payload attachments.

 

[Donamy]

I know that, but being attachments 5,6,7. are they latch locations, 1,2,3 on the aft station? I can't get them to release.

 

[GLS]

I don't think the VAFB tile conversion was done in the best way. Currently, the east part of the runway isn't covered by the tiles and looking at the original tiles it was. I don't know if this is due to missing files, or that area wasn't converted.
Anyway, the original tiles were level 3, 4 and 5, which nowadays is resolution 15, 16 and 17. But, as the original level 3 tiles are 512x512 (current tile size), the 4 tiles are 256x256 and the level 5 are 128x128, and they all the same visual quality, I think we should just convert directly the level 3 tiles (to level 15), and have the level 4 and 5 tiles assembled into 512x512 tiles to then convert those (to level 15 as well).

---------- Post added at 02:01 PM ---------- Previous post was at 01:57 PM ----------

I know that, but being attachments 5,6,7. are they latch locations, 1,2,3 on the aft station? I can't get them to release.

Is the Payload Bay Mech Power on (panel R13L) and the Payload Retention Logic Power on (panel A6U)?

---------- Post added at 03:46 PM ---------- Previous post was at 02:01 PM ----------

Just committed the "VAFB takeover". It should all work, but I haven't done a clean install check as I currently don't have enough disk space for another Orbiter installation. Anyway, the previous problems with missing files and wrong paths in the VAFB base were corrected, and I added the OLF, and the MDD at KSC, as we had the meshes and weren't using them.
I'll now tackle the surface tile issues above (which I noticed aren't included in the release file list :facepalm.

 

[DaveS]

What are we going to do about the elevation issues? Currently there's some clipping with the pad ground mesh with the native Orbiter terrain.

 

[GLS]

What are we going to do about the elevation issues? Currently there's some clipping with the pad ground mesh with the native Orbiter terrain.

Yes there is, as I still haven't started on the terrain... :shrug:
I just finished the tiles (they don't quite match the 2016 surface... not sure who's wrong) and I'm now updating the release file list, and then I will work the terrain. It will probably take a few days, so everyone can pull up a chair, sit back and relax, and watch the bulldozers. :lol: