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

[GLS]

Hole in (at least) the right wing:

 

[DaveS]

That's been fixed on the new mesh along with a host of other issues.

 

[GLS]

Just committed new event timer logic, fixing some issues (0.5s errors, command issues and location of the event timer code). Also, the forward timer is now reset and started by the GPCs at T0 and MECO.

 

[Donamy]

The Canadarm2 does not have the rotation error that the Shuttle arm has. I think Siamesecat put a reset in the code. Since the code is available, might it be able to fix the RMS rotation problem ?

 

[GLS]

The Canadarm2 does not have the rotation error that the Shuttle arm has. I think Siamesecat put a reset in the code. Since the code is available, might it be able to fix the RMS rotation problem ?

Wasn't this determined to be an Orbiter issue, as the default Atlantis also suffers from it?

 

[Donamy]

Then how did Siamesecat overcome it, with the Canadarm2 ?

 

[Urwumpe]

Then how did Siamesecat overcome it, with the Canadarm2 ?

No idea - did somebody already replicate the test scenario with it?

 

[GLS]

It is mentioned on the Orbiter bug ticket that this also occurs with the Shuttle Fleet. The SSRMS is probably not showing this problem because it is of a different (physical) design, thus it might be "immune" or we might not be triggering the issue. :shrug:

 

[Urwumpe]

It is mentioned on the Orbiter bug ticket that this also occurs with the Shuttle Fleet. The SSRMS is probably not showing this problem because it is of a different (physical) design, thus it might be "immune" or we might not be triggering the issue. :shrug:

Or the math for the position and orientation of the attachment points is different. All affected add-ons rely on Orbiters Animation handling, using LOCALVERTEXLIST to calculate this value. Maybe the SSRMS is different there.

What about doing some forward kinematics to check?

 

[GLS]

Or the math for the position and orientation of the attachment points is different. All affected add-ons rely on Orbiters Animation handling, using LOCALVERTEXLIST to calculate this value. Maybe the SSRMS is different there.

What about doing some forward kinematics to check?

I did all the debugging I could at the time... I don't remember all the specifics, but it all seemed fine on "this side of the curtains". I think there was a disconnect between the VERTEXARRAY points (or whatever they are called) that we use to set the attachment orientation and the joints animation (from which those points originate), so IMO it seems like something is causing the drift on Martin's side. Numerical precision?


Any news on the DPS (GPCs, FCs)? BTW: do we need to compile a list of MIA addresses for the FC busses? I found the numbers for the MECs... not sure if there's a list somewhere, or if we need to make one.

 

[Donamy]

If you stop, then restart the scenario with the RMS, the attachment resets and corrects itself. Would the SSRMS code do this resetting somehow ? David413 uses the same code for the JEMRMS.

 

[GLS]

If you stop, then restart the scenario with the RMS, the attachment resets and corrects itself. Would the SSRMS code do this resetting somehow ? David413 uses the same code for the JEMRMS.

It "resets" because Orbiter starts calculating the attachment "from scratch" at the start of the scenario. The issue appears to be some imprecision that adds up during joint animation, inside Orbiter, slowly corrupting the vector we use to point the attachment. Maybe there's a way to avoid it (I don't know how), but that still wouldn't fix the root cause.

 

[Urwumpe]

Any news on the DPS (GPCs, FCs)? BTW: do we need to compile a list of MIA addresses for the FC busses? I found the numbers for the MECs... not sure if there's a list somewhere, or if we need to make one.

I think I also have a list there, including a table with the coarse MDM configuration. We could also use our own number scheme there, but then I would recommend using symbols there instead of numeric constants.

No news about any DPS commit yet. All I can say so far is: When I include it, I will prefer a branch by abstraction, allowing to switch between existing GPC code and new GPC code by configuration file. Should there be more bugs than tolerable, we can still use the old one as default and fix the bugs in the background.

 

[GLS]

No news about any DPS commit yet. All I can say so far is: When I include it, I will prefer a branch by abstraction, allowing to switch between existing GPC code and new GPC code by configuration file. Should there be more bugs than tolerable, we can still use the old one as default and fix the bugs in the background.

And why not use a "regular" branch? IMO it would be easier than dozens of "if (new cfg), else (old cfg)".

 

[Urwumpe]

And why not use a "regular" branch? IMO it would be easier than dozens of "if (new cfg), else (old cfg)".

Actually, its not dozens of this, its just one in the flow of clbkSetClassCaps, using inversion of control.

Could then be as simple as:

if( cfg == new ) {
    createNewDPSImplementation();
} 
else {
    createOldDPSImplementation();
}

Branch by abstraction works generally by hiding both implementations behind a common interface. In the least specific way, we can use the Orbiter Callbacks as template there.

And regular branch simply because it would require to maintain this branch longer until the DPS implementation can fully replace the old one. I don't think this makes it better. As long as only one of the implementations can be active at run-time, we should not get any issues.

 

[GLS]

Actually, its not dozens of this, its just one in the flow of clbkSetClassCaps, using inversion of control.

Could then be as simple as:

if( cfg == new ) {
    createNewDPSImplementation();
} 
else {
    createOldDPSImplementation();
}

Branch by abstraction works generally by hiding both implementations behind a common interface. In the least specific way, we can use the Orbiter Callbacks as template there.

And regular branch simply because it would require to maintain this branch longer until the DPS implementation can fully replace the old one. I don't think this makes it better. As long as only one of the implementations can be active at run-time, we should not get any issues.

Would that not involve having both old and new versions of pretty much everything (sw, subsystems, etc)? I see your point of view, and that would make sense in something that always has to work, e.g. the operation of some important machine. But for us, doing these changes in a branch, and in this process for some time the branch code might not compile or it wouldn't support launches or something else, that work for me. We would only merge to the trunk (and throw away the old stuff) when the new stuff works. :shrug:
Maybe my point of view is too drastic (demolish the old bridge and built a new one in its place, instead of keeping the old one and building the new one next to it), but in the end all it matters is that things get done.

 

[Urwumpe]

Maybe my point of view is too drastic (demolish the old bridge and built a new one in its place, instead of keeping the old one and building the new one next to it), but in the end all it matters is that things get done.

Well, I understand your point of view there, I am just used to server development, which means burning bridges is no option for me until the new bridge is ready. :lol: And by experience, the new bridge is not yet ready when we integrate a branch into trunk, it takes a little longer.

I know you itch to see the GPC code and trust me: I also can't wait to see a version that makes me happy.

And I think, we don't really need that much dual code actually. Right now, we talk to the subsystems directly and bypass the MDMs. Would we have MDMs, we could still allow directly setting values, instead of executing IO programs.

 

[GLS]

I know you itch to see the GPC code

True :lol:, but lately I'm salivating more at the idea of having our "information super-highway", a.k.a. FC busses.

 

[Urwumpe]

True :lol:, but lately I'm salivating more at the idea of having our "information super-highway", a.k.a. FC busses.

I can understand why... especially regarding polling the LDB...

 

[Gingin]

True :lol:, but lately I'm salivating more at the idea of having our "information super-highway", a.k.a. FC busses.

Are you implementing Electrical systems?:thumbup: