SSU V1.25 Release

[Donamy]

What ever you're comfortable with is OK with me.

 

[Urwumpe]

The MPM bug was occuring because the RMS subystem is only created after the 'RMS' line is found in the scenario file. Because of a change I had made to the code, the RMS subsystem wasn't created. This setup also means that the RMS line MUST appear above all other scn entries associated with the RMS, which may not be a good thing. Any comments?

What about making the RMS line overrule all other lines?

 

[DaveS]

Should be fixed soon; I messed up the initialization code with my earlier check-in.


-----Post Added-----


Should be fixed now. The only things that still don't work are the STOW button on the dialog and the MPM latches.

The MPM bug was occuring because the RMS subystem is only created after the 'RMS' line is found in the scenario file. Because of a change I had made to the code, the RMS subsystem wasn't created. This setup also means that the RMS line MUST appear above all other scn entries associated with the RMS, which may not be a good thing. Any comments?

Works nicely here now, IK without joint jumps included! The new saving method works for me. Maybe we should create an "PDRS" section and keep all the PDRS latch and RMS stuff in there for consistency?

 

[Urwumpe]

Works nicely here now, IK without joint jumps included! The new saving method works for me. Maybe we should create an "PDRS" section and keep all the PDRS latch and RMS stuff in there for consistency?

We could maybe attempt porting the system I use for the panels to subsystems, but from the bugs I had to solve in the panel code, I am not sure it is a good quick solution.

 

[Donamy]

Have the buttons been fixed yet on the A7A8 panel ?

 

[Urwumpe]

Have the buttons been fixed yet on the A7A8 panel ?

Will do it this evening. Also I will give it a try to fix the forward MDU buttons.

 

[SiameseCat]

What about making the RMS line overrule all other lines?

I'm not quite sure what you mean here, but the main problem is the the scenario file is parsed once, and the RMSSystem class (which reads all the other lines associated with the RMS) is only created when the 'RMS' line is found. The only way I can think of to avoid this problem is to always create the RMSSystem class, and then disable it if the RMS line is not found in the scenario.
Overall, I think the best thing to do is to leave the code the way it is. In any case, we're going to be using a separate file to define the components on the shuttle (RMS, ODS, panels, etc.), so whatever we do here will just be temporary.

 

[DaveS]

Once the RMS system is stable enough for release, here's another thing that should be implemented:
Saving/loading of PLB cam positions. You might wonder why this is such a beg deal?

For launch the cameras are rotated 90°s inboard around the pivot axis and the RMS elbow cam is also rotated 90°s around the tilt axis so it looks upward.

So in order to have this modelled correctly, a svaing/loading routine of the cam positions is necessary.

 

[Urwumpe]

Saving/loading of PLB cam positions. You might wonder why this is such a beg deal?

You are right, we should make sure this makes it into SSU 1.25.


Also, we should make sure SSU allows replay scenarios. It is a standard Orbiter feature and I don't want to have bugs then.

 

[Donamy]

The RMS still jumps for me in translation, after using rotation. After Jan 22 MGAtlatis.dll

 

[SiameseCat]

Donamy: Does it always jump, or only at certain angles/positions? Also, how much does it jump? I've noticed that a slight change in position sometimes occurs, but this is hardly noticeable.

 

[DaveS]

Donamy: Does it always jump, or only at certain angles/positions? Also, how much does it jump? I've noticed that a slight change in position sometimes occurs, but this is hardly noticeable.

Just to note I don't have any issues other than the ones you have already noted.

 

[Donamy]

With the RMS in the null position, if I try to do any translation, it jumps -x about 6", always to the aft about 6 scaled inches.

 

[DaveS]

Just noticed a problem with the EE cam view: It doesn't move with the actual EE. It's stuck in the deployed null position. And speaking of that, I highly recommend using Artlav's Intermod2 add-on: [ame="http://www.orbithangar.com/searchid.php?ID=3530"]Intermod_2[/ame] as this allows a view of the actual EE when using it's Closeview mode.

So whoever decides to take up this task, please optimize the view for use with Intermod2, thank you!

 

[SiameseCat]

With the RMS in the null position, if I try to do any translation, it jumps -x about 6", always to the aft about 6 scaled inches.

Doesn't happen for me. Does the translation work the rest of the time?

 

[Donamy]

The translation works good with some minor rotation imparted, but when a rotation is entered, the next translation has a bit of a jump before moving.


-----Post Added-----


My bad, I put the .dll in the wrong Orbiter file.:blush:

However, the joints are moving extremely slowly, can hardly tell they are moving at all.


-----Post Added-----


Seems to be working now, slightly jerkey and very tiny jump now, but not bad, sorry for the trouble.

 

[SiameseCat]

The joint rotation speed is currently set to 1.5 deg/sec. I can increase it to about 3 deg/dec.
DaveS: I'll work on the EE camera view.

 

[DaveS]

The joint rotation speed is currently set to 1.5 deg/sec. I can increase it to about 3 deg/dec.

What's the most realistic rate?

DaveS: I'll work on the EE camera view.

Will you optimize it for Intermod2?

 

[SiameseCat]

EE view will be optimized for Intermod2. I also plan to fix the elbow camera view (which is not moving at the moment).

 

[DaveS]

EE view will be optimized for Intermod2. I also plan to fix the elbow camera view (which is not moving at the moment).

Great, thanks!! That is :speakcool:!!