SSU V1.25 Release

[Donamy]

I'm fine with that, if that's what is wanted. Could even eliminate the group entirerly if mesh.c would handles that. How do you feel Dennis ?

 

[Urwumpe]

I'm fine with that, if that's what is wanted. Could even eliminate the group entirerly if mesh.c would handles that. How do you feel Dennis ?

I think this could work out, but we would then have a two stage animation on the same group. I feel better with having at least one group per animation component, instead of empty or applying two animation components on the same group. With just one group, we would need to create a dummy rotation for the switch as parent component of the translation for pulling.

 

[Donamy]

What ever you two decide, is fine by me.

 

[SiameseCat]

As things stand though, we only have one group to animate. Would having two groups per switch affect performance?

 

[Donamy]

wasn't there already talk of slow FPS ?

 

[Urwumpe]

wasn't there already talk of slow FPS ?

The launch sequence was a pretty slow down, but in orbit, we still have good FPS...

 

[Donamy]

AFIR, the bottom part of the switches were joined with the switch guard group. It would take awhile to seperate them to seperate groups. I don't know if there would be enough time to do that for the (cough) target release date. I'm still working on the ORUC payload, then I'll be doing the animation ini.s for the other payloads. Eliminating them would be easier, and I may not need to change any groups, but I can do either.

 

[SiameseCat]

The slow FPS was caused by a problem in the GPC code; it should be fixed now. We're still getting good performance, but I'm not too pleased about adding a lot of new groups to the VC mesh.

 

[Urwumpe]

OK, then we use the single group switches as compromise, the animation performance should not be less as if we animate an existing group.

 

[Donamy]

Should I eliminate the bottom of the switches ? If so, which panel(s) do you want me to start with?

 

[SiameseCat]

Donamy: The idea is to take the bottom segment of the switch, move it down 'under' the parel area, and add it to the main switch group. You should probably start with panels C3 and R2, since they're the only ones where these switches are animated. I'm also hoping to animate one of the A6 switches before release.

 

[Donamy]

I'm not sure I understand. Move the bottom part of the switch below the panel, then it is pulled up with the top part, and then the top part is flipped up or down alone, or together with the bottom part. perhaps a sketch might be better, for me to understand.

 

[SiameseCat]

Have a look at the attached picture (sorry for the bad drawing). The whole switch should be one group, with a small portion of the group being under the panel surface and invisible.

 

[SiameseCat]

The OMS/RCS fuel displays on Panel O3 should be working now (except for the LOWEST setting). For the RCS, only the fwd reading is valid (at the moment, the aft RCS thrusters are fed by the OMS tanks).

 

[Donamy]

Have a look at the attached picture (sorry for the bad drawing). The whole switch should be one group, with a small portion of the group being under the panel surface and invisible.

That's easy enough.

 

[DaveS]

So are we still going ahead with an Oct. 10 release date or should we postpone it until things are a bit more stable instead of rushing?

That way we could get a stable and feature-rich release in time for the STS-126 mission in mid-November.

 

[Donamy]

I don't see a real need to get it out by 10/10, but at least it put the pressure on, to get something done.

SC,

You have mail

 

[Urwumpe]

So are we still going ahead with an Oct. 10 release date or should we postpone it until things are a bit more stable instead of rushing?

That way we could get a stable and feature-rich release in time for the STS-126 mission in mid-November.

What would we loose if we release bananaware?

 

[SiameseCat]

What do we gain from releasing bananaware?
My vote would be to delay the release to Nov. 1. This would give us a bit more time for upgrades/fixes.

 

[Urwumpe]

What do we gain from releasing bananaware?
My vote would be to delay the release to Nov. 1. This would give us a bit more time for upgrades/fixes.

No, I would say we keep the date. But we release in release candidates, starting with RC1, and plan for a RC2 on the third October week. When no major bugs in the existing features appear in RC2, we release officially on November 1.

We should only ensure, the Release Candidate state is mentioned inside the orbiter log and on the screen during the first minutes, so nobody can claim that he has to use a RC longer than needed, because he did not know it was only a RC.