SSU Development Thread (2.0 to 3.0)

[Donamy]

Should I place the bridgerails into the orbiter.msh, and have them activated like the tails ?

 

[SiameseCat]

No CTDs using D3D9Client RC15 Beta 2 here. Only issue is that the MET clocks (fwd and aft) isn't working anymore. Win7 here.

The OMS/RCS gauges on Panel O3 don't work either.

 

[DaveS]

The OMS/RCS gauges on Panel O3 don't work either.

The LEDs on A8U are however working.

 

[jarmonik]

I'll take a look in the MET clocks. Are there any details how they are made ? Blitting graphics from surface to surface ? With GDI via oapiGetDC() ? Or with a sketchpad ?

As for the future reference: Using Sketchpad::GetDC() method is very bad idea and should be avoided since the implementation of ::GetDC() relays on hacks those do not always work in every situation.

 

[SiameseCat]

If you zoom in on the broken displays, they start working. I've posted some screenshots on the D3D9 thread (http://www.orbiter-forum.com/showthread.php?p=491763&postcount=2962). I'm not sure what's happening here, but I think it might be related to some of the D3D9 changes.

---------- Post added at 04:23 PM ---------- Previous post was at 04:20 PM ----------

I'll take a look in the MET clocks. Are there any details how they are made ? Blitting graphics from surface to surface ? With GDI via oapiGetDC() ? Or with a sketchpad ?

As for the future reference: Using Sketchpad::GetDC() method is very bad idea and should be avoided since the implementation of ::GetDC() relays on hacks those do not always work in every situation.

They use oapiBlt. The digits are created using oapiCreateSurface (from a DLL resource), and blitted onto one of the VC textures.

---------- Post added 01-01-15 at 01:51 PM ---------- Previous post was 12-31-14 at 04:23 PM ----------

From the D3D9 thread:

That's a mipmap issue. The top-layer change isn't copied into a mipmap chain. Should be pretty easy to fix.

 

[Urwumpe]

They use oapiBlt. The digits are created using oapiCreateSurface (from a DLL resource), and blitted onto one of the VC textures.

I would still prefer to get rid of this, because using oapiBlt is extremely slow in relation to the better options... but I also don't want to delay the release for it.

Committed some fixes for the over 100 warnings because of sloppy code, please pay a bit attention to not use implicit conversions (double to float) or deprecated functions in the future.

also, I added some files I had there for refactoring the simple DPS after the release... they are mostly reminders of the static structure.

 

[GLS]

A small heads up to the "graphics department": could anyone check my (possible) fix for ticket 60?

 

[DaveS]

A small heads up to the "graphics department": could anyone check my (possible) fix for ticket 60?

Looks good to me.

 

[GLS]

YEY!!! It works!!!

I'll commit it then.

---------- Post added at 05:50 PM ---------- Previous post was at 02:20 PM ----------

So I've been looking at the tickets and the few I'd like to see resolved before a release are:
49 (Orbiter dry mass)
62 (Reentry plasma mesh/texture in wrong position)
63 (Switch covers (and their appearance in D3D9))
67 (Aft MDU is distorted)
77 (All MPS vents/dumps are in wrong position)

Only after the 15th can I look seriously at ticket 49 (I have exams before that). If anyone wants to take it, please be my guest.
I could probably fix ticket 62 by changing the offset in line 2294 of Atlantis.cpp, but as it currently is (0, 0, 0) it probably should be done via mesh "trickery".
In ticket 63, I can live with the wrong-looking covers for now. The main problem here is that they don't show at all in D3D9 only (just installed R14 and it's the same).
Don't know enough to deal with ticket 67.
And in ticket 77, I could do it but I need help in the form of coordinates (trial and error is just way too slow :compbash2.

There's also ticket 33 (SSME exhausts not aligned with nozzles) for which I just posted an image showing the results of the change I did to the texture. If there are no objections I'll commit the updated texture.

A couple more issues I noticed playing around today: (1) none of the 3 Discovery textures has "Discovery" on the right side of the upper fuselage and (2) the orbiter in the texture "Endeavour_3rdmod" is not Endeavour but Atlantis.

 

[Urwumpe]

Only after the 15th can I look seriously at ticket 49 (I have exams before that).

I could take a look at 49 if somebody does the research for the function. It does not look like it takes too much effort.

I still have to finish a six page university homework until the 22nd, but some small work should be possible. My exams start on the 30th... but honestly, only one of the three exams is really requiring effort.

 

[DaveS]

The OV-103, 104 and 105 textures have been updated to address the issues posted by GLS.

 

[GLS]

I could take a look at 49 if somebody does the research for the function. It does not look like it takes too much effort.

Can the subsystems add mass? I remember a function somewhere, but I'm not sure it's "plugged in" to the vehicle mass. Assuming that is working (or can work), we could have a baseline mass (maybe from OV-104 or 105 that being the lightest would not be very limiting) that already has the masses of the OMS/RCS/MPS/PRSD/etc, and those systems would have mass 0 for now. The current optional components (ODS/RMS/OBSS) would define their own masses.
For the next release we could revamp this arrangement by having more systems with their own mass and the ability to differentiate the masses of different vehicles.

 

[Urwumpe]

Can the subsystems add mass? I remember a function somewhere, but I'm not sure it's "plugged in" to the vehicle mass. Assuming that is working (or can work), we could have a baseline mass (maybe from OV-104 or 105 that being the lightest would not be very limiting) that already has the masses of the OMS/RCS/MPS/PRSD/etc, and those systems would have mass 0 for now. The current optional components (ODS/RMS/OBSS) would define their own masses.
For the next release we could revamp this arrangement by having more systems with their own mass and the ability to differentiate the masses of different vehicles.

Yes, we would just need to include the different structural weights to get proper results. Also, the function would need some events to reconfigure the spacecraft successfully between missions

 

[GLS]

Yes, we would just need to include the different structural weights to get proper results. Also, the function would need some events to reconfigure the spacecraft successfully between missions

We're going to do orbiter turnaround? Luckly I have the necessary logic in the SSME controller for that :lol:, just need the LCC to send the commands.

 

[Urwumpe]

We're going to do orbiter turnaround? Luckly I have the necessary logic in the SSME controller for that :lol:, just need the LCC to send the commands.

Well, not now... but because we plan it as major goal, we should never forget it in our architecture. Maybe we should use the next release then for already including "cheated/magical" turn around steps, where we can test if the subsystems are all correctly brought into launch configuration again.

 

[SiameseCat]

Can the subsystems add mass? I remember a function somewhere, but I'm not sure it's "plugged in" to the vehicle mass. Assuming that is working (or can work), we could have a baseline mass (maybe from OV-104 or 105 that being the lightest would not be very limiting) that already has the masses of the OMS/RCS/MPS/PRSD/etc, and those systems would have mass 0 for now. The current optional components (ODS/RMS/OBSS) would define their own masses.
For the next release we could revamp this arrangement by having more systems with their own mass and the ability to differentiate the masses of different vehicles.

I can fix ticket 49. For the moment, we can just iterate over all subsystems and add their mass to the shuttle mass. I'll also take a look at ticket 77 if I have the time.

 

[DaveS]

Where do we stand on getting the meshes done prior to release? There's some small issues with the orbiter and the External Airlock/ODS needs to be rescaled.

 

[Donamy]

I just sent SC a new Orbiter mesh, that should have the known issues fixed, and all the bridgerails. I'll take a look at the AL.

 

[DaveS]

I just sent SC a new Orbiter mesh, that should have the known issues fixed, and all the bridgerails. I'll take a look at the AL.

Thanks. Were there any texture mapping changes? I so, an updated master texture file (Orbiter_blank.psd) would be nice to have available. One thing that is needed for the early/mid versions of OV102,103,104,105 is a midbody/aft that is covered entirely with AFRSI blankets. Currently they're of the late AFRSI/FRSI mix that was implemented for the ISS missions.

 

[Capt_hensley]

I've been monitoring this thread since pre ver1.0, and one thing rings out in my mind, the team is chasing faults that are circular in nature... i.e. a mesh is faulty, that leads to a code segment change, that leads to more mesh faults, and so on.

For SSU to continue to work and improve, IMO, a functional code base, beta tested and released twice a year, would lead to a more full featured model.

Then SSU can get it's needed visual version enhancements, and unfold into the beautiful butterfly from the cocoon of conflict it's currently experiencing. I would rather have a highly accurately working model, than a buggy-pretty model.

With so many great add-on builders working on the project, and patience from the beta testers, this project has only one direction, constant improvement, and that's 24-7 from what I read here.

Finally, great things are being achieved here, don't lose sight of the fact that this project is already leaps and bounds a far better product day by day, than all the add-ons for the program put together. And there are some great add-ons out there. Remember the roots of this feature, the program itself. All hail the probe, and high gratitude to Martin for making this all possible.

Keep up the great work. I'm a button pushing, switch flipping fool for SSU!