SSU Development Thread (2.0 to 3.0)

[GLS]

Can anyone check that there are no problems with the fix for ticket 83 on r2200? MPS related that is, as the fix for the twitching during launch was removing a call to update the vehicle mass from the MPS/ET code. I did a bunch of launches (most with all kinds of dangerous stuff you shouldn't do in real life), and didn't find any problems. I'll leave the ticket open for a few days and if no one complaints I'll close it.

 

[Urwumpe]

Fixed the animation, now there is only one big and a small problem left:

The ODS Rods are too short for 45 cm extension.

And the petal 2 actuator drive units are not rotation symmetric it seems.

 

[DaveS]

Fixed the animation, now there is only one big and a small problem left:
The ODS Rods are too short for 45 cm extension.

How many cm are missing? I could add those.

 

[Urwumpe]

How many cm are missing? I could add those.

Compile and see for yourself... I would say not more than 10 cm.

 

[GLS]

Please be aware that if the initial position of the ring is extended (as in the "STS-126 docking with ISS Nov 16" scenario) the rods and motors initially are not in the correct position.

 

[DaveS]

Compile and see for yourself... I would say not more than 10 cm.

I have checked in ODS mesh which has those 10 cm added. Everything looks good except for that when exit and reload a scenario which as the ODS docking ring in the Forward Position, the rods become decoupled from the bases.

 

[Urwumpe]

Please be aware that if the initial position of the ring is extended (as in the "STS-126 docking with ISS Nov 16" scenario) the rods and motors initially are not in the correct position.

I know, will fix that.

---------- Post added at 10:22 PM ---------- Previous post was at 10:18 PM ----------

Uploaded a "small" nightly test distribution to sourceforge (188 MB), will be available soon.

---------- Post added at 10:30 PM ---------- Previous post was at 10:22 PM ----------

Fixed the ODS animation state after loading a scenario.

 

[DaveS]

I checked in a fix for the petal 2 rods where they got decoupled from the bases aswell as the docking ring itself. Turns out that the references for them were wrong. This has now been corrected and everything is well.

 

[Urwumpe]

Did some research this morning on the ET separation motion issue in the Orbiter Data Book:

The orbiter does not rotate, it stays in attitude hold mode from MECO command on, the drawings in it show a slowly pitching ET. The attitude hold is also described in text form there, with attitude rates and dead bands.

So, even the corrections of using a "real RCS" implementation will not change this, it will only make the translation more accurate.

---------- Post added at 10:06 AM ---------- Previous post was at 09:33 AM ----------

The nightly build can be found here:

http://sourceforge.net/projects/shu...eultra/2.1/SSU_v2.1r2201-nightly.zip/download

 

[GLS]

On ticket 99: "Confirmed to be an Orbiter bug, waiting for bugfix in Orbiter to test the behavior again."
Is this confirmed as not our problem? The only bugs confirmed to be caused Orbiter are the mouse events showing at different panels and the initial camera position direction. The issue with panel A8 seems to be offsets changing with the c.g.. And it only happens on that panel (which has a separate mesh). But other than that I can't say what is at fault here.

What about this? Looks to me as it has been closed in error. If so then we should re-open the ticket.

 

[Urwumpe]

What about this? Looks to me as it has been closed in error. If so then we should re-open the ticket.

Isn't that the bug with the misbehaving panel click areas? if not - which one was it?

 

[DaveS]

Isn't that the bug with the misbehaving panel click areas? if not - which one was it?

This is the ticket in question: https://sourceforge.net/p/shuttleultra/tickets/99/

 

[Urwumpe]

This is the ticket in question: https://sourceforge.net/p/shuttleultra/tickets/99/

I know - but was there another one about a different bug regarding the click areas? I only know of that one #99.

 

[DaveS]

I know - but was there another one about a different bug regarding the click areas? I only know of that one #99.

I don't think a ticket was ever created for that. We just discussed it as part of ticket 99.

 

[Urwumpe]

I don't think a ticket was ever created for that. We just discussed it as part of ticket 99.

I'll test this this evening (ETA 5 hours), if GLS test scenario is really the same bug that we are talking about here. If not, we should make a new ticket about the bug.

 

[GLS]

Let me clear up the confusion. AFAIK there are 3 vc bugs:
1) panel O6 gets its click area in front of panel C3 (there's other cases as well) -> thru testing in the Delta Glider determined to be caused by Orbiter and bug report posted;
2) initial external camera orientation is "perturbed" by SetCamerawhatever() -> also determined to be caused by Orbiter -> SiameseCat had a bug report posted some years ago, and I added new info;
3) panel A8 doesn't get mouse events when the payload is attached in a certain position (only at start of sim) -> seems to be related to the initial position of the cg, but I can't find the cause. It could be another Orbiter issue, as it could be our fault, because this only happens on that separate panel A8, but again, I can't find any answers.

---------- Post added at 01:00 PM ---------- Previous post was at 12:59 PM ----------

I know - but was there another one about a different bug regarding the click areas? I only know of that one #99.

On the O6/C3 issue I never created a ticket as I was searching the issue. My fault here.

 

[Urwumpe]

It could be another Orbiter issue, as it could be our fault, because this only happens on that separate panel A8, but again, I can't find any answers.

Does it only happen if the panel A8 is used directly after loading a scenario in VC view? And does no longer happen, if panel A8 is used after switching VC position a few times?

 

[GLS]

Does it only happen if the panel A8 is used directly after loading a scenario in VC view? And does no longer happen, if panel A8 is used after switching VC position a few times?

The particular scenario where I found this problem starts in external view, and there's no VC_POS entry in the scenario file, so when going into the VC it is in the CDR position. I move to the aft positions (I think I've tried all the possible paths) and start clicking on the panel and nothing happens. If the payload is unlatched -> it start working again. If the payload is immediately re-latched -> it still works. Only panel A8, all the others seem to work (I think the IUS panel L10 was also showing the same problem but didn't test anything). Playing with the PayloadZPos parameter near the point where it stops working doesn't show the panel click area to be shifting position, it's like it doesn't exist...
IMO it doesn't seem to be related to the other 2 issues.

 

[Urwumpe]

Did you try it in panel debug mode?

 

[GLS]

Did you try it in panel debug mode?

Yep, nothing shows up.