Space Shuttle - Bugfixes

[GinGin]

I looked of course to the pointed line
And I don't see the culprit.

[wlbragg]

@GinGin can you post your entire log. Sometimes a different nasal error can cause a faulty or misleading cascade type error.

[GinGin]

@wlbragg: Sure, I will ask to the concerned persons about their logs.

[Thorsten]

And I don't see the culprit.

Neither do I - though sometimes it's a missing tag which does not close something above, I've just had a quick look...

[eatdirt]

May 2020, do you remember how did you get rid of it ?

Yes, that's just in the post following my comment

Arf, my mistake, I was confused by a commit dated from the 7th of May 2020 and I've tested the "master" branch instead of the devel one.

That's why! I was just cloning fgspaceshuttle, which sets the default branch to master. So, you have to

Code: Select all

git checkout development


before doing anything else. I think I made that comment to Gomendio on the devel thread, it is very easy to make that mistake. Now, if this is happening with the --launcher, we may have a problem indeed. But again, it is very easy to have a version of the Shuttle installed in a directory that would take precedence over the one installed by the --launcher with some .fgfsrc settings?

[GinGin]

That's why! I was just cloning fgspaceshuttle, which sets the default branch to master

Thanks, though they installed the stable version from the FG launcher.

it is very easy to have a version of the Shuttle installed in a directory that would take precedence over the one installed by the --launcher

Interesting point.
I didn't have feedback from their logs yet, so nothing to investigate more for now.

[wlbragg]

Well here's a new one. I thought this might be Chris's new work but it is happening with my original before I merged the new RMS rotations and it only is happening with a relatively recent build of next. If I run a 2020.4 nightly I have from a couple months ago I don't get the error. So far it is only the Shuttle I am seeing this with.
I will probably have to take this to the dev list as I think it is something new or changed in the core but I thought I would post here first just in case someone has seen this.

The last logged lines are ...

Code: Select all

Trim Results:
       Angle of Attack:    7.5  wdot:  2.80e+01 Tolerance: 1.000000e-03  Failed
              Throttle:    0.5  udot: -2.06e-01 Tolerance: 1.000000e-03  Failed
            Pitch Trim:      0  qdot:  3.48e-10 Tolerance: 1.000000e-04  Passed
            Roll Angle:  0.023  vdot: -1.11e-02 Tolerance: 1.000000e-03  Failed
              Ailerons:      0  pdot:  6.75e-08 Tolerance: 1.000000e-04  Passed
                Rudder:      0  rdot: -1.26e-06 Tolerance: 1.000000e-04  Passed

  Trim Statistics:
    Total Iterations: 61
    Sub-iterations:
    wdot: 0 average: 0  successful:  0  stability: 2
    udot: 0 average: 0  successful:  0  stability: 2
    qdot: 0 average: 0  successful:  61  stability: 2
    vdot: 121 average: 1.9836  successful:  61  stability: 2
    pdot: 0 average: 0  successful:  61  stability: 2
    rdot: 0 average: 0  successful:  61  stability: 2
    Run Count: 2210

Anyone have any idea what this is, Thorsten?

[Thorsten]

No, sorry.

[jano]

same here, both Vostok and the shuttle are not starting:

[VA-41]

So I made this list of things I came across thinking that they were bugs/incorrect behavior and GinGin recommended sharing it here too.

• "ON" in "SERC ON" should be double overbright [DPS dict 3-6]
• SPEC 63 should not be able to be accessed in GNC OPS 2 [DPS dict 3-1]
• Some other item entries than PEG 7 are also supposed to "unload" the burn data [DPS dict 3-8]
• On ascent, selecting CSS on either axis should give CSS to both axes [SCOM 7.1-7]
• On entry, the yaw error needle should display estimated sideslip [DPS dict 6-20]
• PEG 7 Z axis is reversed [SCOM 2.13-3 & SCOM 2.18-2]

The square brackets have the "sources" I used as manual pages. Please correct me if I'm wrong about any of these.

[GinGin]

Thanks.
Working on some items.