Space Shuttle Ultra development thread

[SiameseCat]

Yes. I'm not sure if it matters, but they both rotate around the Z-axis.
EDIT: If I change the rotation axis for one of the animation components, this problem goes away.

 

[SiameseCat]

I managed to fix this by creating a separate animation with a rotation angle of 0. I'm still not sure why the original version failed, but this works.

 

[DaveS]

I have now checked the latest sources with the fixed animations for the KU band antenna and payload bay cameras.

Also checked in the new scaled down KU band antenna and RMS meshes. Also Donamy just sent me the new stuff for startracker and airdata probes.

 

[Urwumpe]

I managed to fix this by creating a separate animation with a rotation angle of 0. I'm still not sure why the original version failed, but this works.

Sounds like you maybe used the wrong parent for an child animation. I can peer-review your code soon, if you like. The correct parent should be a more elegant solution, if this is really the cause.

 

[SiameseCat]

You can look at the existing RMS code. This bug seems to have been around for a while. The easisest way to see what's happening is to check the 'Show Grapple Points' box, then rotate the wrist and whatch what happens to the arrow.

 

[Donamy]

Dave,

Did you get the VC meshes ?

 

[DaveS]

Dave,

Did you get the VC meshes ?

Yes I did. But it seems like you forgot to include the missing Fpanels.dds texture.

Edit:
New AtlantisVC.msh have been checked in.

 

[Donamy]

You should have it now.

 

[DaveS]

You should have it now.

Got and it works fine. Now there's another three missing textures:
-VC01.dds
-VC02.dds
-VC03.dds

Edit:
BTW, you might want to take this opportunity to correct the aft MDU. It's rotated 180°´s, so it's upside down.

 

[Donamy]

I sent you a fixed KU.msh, you had it slightly out of line. You may want to test the rotation point.

Also, what do you mean, MDU ?

 

[Urwumpe]

Also, what do you mean, MDU ?

It should mean "[FONT=Arial,helvetica][SIZE=-1]mission data unit" according to the Acronym file. But don't ask me what this is. :lol:

Maybe he means a "Multifunction Display Unit" - I just invented this meaning of MDU. Can we consider a MDU an AWGKM*?

*Acronym without generally known meaning.


[/SIZE][/FONT]

 

[DaveS]

I sent you a fixed KU.msh, you had it slightly out of line. You may want to test the rotation point.

Also, what do you mean, MDU ?

Multi-functional Display Unit, the MEDS LCDs. MFDs are the name for the various displays(ADI, HSI, AVVI, ADI/HSI etc.).

 

[Donamy]

too bad it's not really functional.

 

[DaveS]

too bad it's not really functional.

Not yet at least. I'm sure it's just overlooked and it should be made working in no time.

 

[Donamy]

Yea right !:lol:

 

[Urwumpe]

Not yet at least. I'm sure it's just overlooked and it should be made working in no time.

Well, we can maybe simply make an (Orbiter-) MFD out of it or experiment with painting it internally without using an MFD.

The first would be done quickly, the last would be better for realism (we can draw it without compromises needed for Orbiters MFD system)

 

[Donamy]

I think when we are ready to use the Ultra scaled version, it should be called v2.0. What do you think ?

 

[DaveS]

Well, we can maybe simply make an (Orbiter-) MFD out of it or experiment with painting it internally without using an MFD.

The first would be done quickly, the last would be better for realism (we can draw it without compromises needed for Orbiters MFD system)

Well, for now it can be made to work just like the forward MDUs. We are afterall right now dependant on CRTMFD to monitor APU/HYD and OMS/MPS performance.

 

[Urwumpe]

I think when we are ready to use the Ultra scaled version, it should be called v2.0. What do you think ?

I think its no major step in features yet, which would justify the jump. Its a lot of work behind it, thats true, but it did not hit a specific mile stone earlier.

What about we make a plan for now, which features we want to implement into 2.0, so we know when we should make the jump to the next major version (We have not even reached 1.10 yet! )

I would add finishing the MLP to the list from my side. DaveS's meshes look already very good, so I am optimistic we can get that done for 2.0.

The next feature I can finish for 2.0 are the indicators and dials on the O1, O2 and O3 panel, so they display useful values during flight.

I currently plan to work on the Communication subsystem, but I don't believe I can finish this large amount of operations before major version 3.0. I could not even imagine OrbiterSound support for voice communication before major version 4.0. The first task item I want to make for the communications is the GCIL logic and the connection to the existing panels.

 

[Donamy]

I just think we need something to distinguish between the 2 scales so someone (like me) doesn't mistakenly send someone the wrong one.