Space Shuttle - Bugfixes

[GinGin]

Alright, I will have a look at that and see if NaN appears then disappears

Back to Interconnect, it works nicely for the timing now
220 sec full dump with 24 RCS.

Also, I did a lot of RTLS lately ( doing a video on it), and using my ascent profil, it was even more in the envelop.
Pinpoint RTLS with your code and closer to real stage 1, how entertaining !

[eatdirt]

Ok, I did a save/resume from my clean Shuttle install and clean .fgfs/ directory.

1) My first try was to resume a state in which I was closing-in to Hubble, in the near-zone, and that failed. The resume state was -180km away from Hubble in the Rdv windows, and indeed outside nothing was visible.

2) Then I resumed from a state just before the T1 Lambert targeted burn I posted a few days ago, and everything worked fine, up to the NaN which is popping out for Rdot in SPEC33, it still there. I have also recomputed the Lambert burn and it came out with the same solution, cool!!

I have the save.xml files if necessary. Nothing bad in the console, just a "state resumed" without errors.

Edit:

A while after, when the RR starts working on the target, it also displays Nan for Rdot. When entering the near zone, I got some errors in the console too:

Code: Select all

Placing HST model!
 3813.10 [ALRT]:nasal      Coordinate differences proximity:
 3813.10 [ALRT]:nasal      3686.308783222773 -1734.831882907948 -2868.665108516812
 3813.10 [ALRT]:nasal      HST alt2 before: 531932.8807691223 prox_z: -2868.665108516812
 3813.10 [ALRT]:nasal      HST alt2 aft: 534801.5458776388
 3813.12 [ALRT]:nasal      Nasal runtime error: setprop() passed a NaN
 3813.12 [ALRT]:nasal        at /home/chris/.fgfs/Aircraft/SpaceShuttle/Nasal/rel_orbital.nas, line 392
 3813.12 [ALRT]:nasal        called from: /home/chris/.fgfs/Aircraft/SpaceShuttle/Nasal/rel_orbital.nas, line 1683
 3813.12 [ALRT]:nasal        called from: /home/chris/.fgfs/Aircraft/SpaceShuttle/Nasal/rel_orbital.nas, line 1702


Cheers,
Chris.

[Thorsten]

1) My first try was to resume a state in which I was closing-in to Hubble, in the near-zone, and that failed.

That's... really not supported. Though I am somewhat mystified as to why you should be so far away - it actually should resume to the position relative to the far zone target (which keeps being propagated, just not in J3 gravity) - so you should be off by the difference between approximated J3 and real J3.

Which is not 180 km.

up to the NaN which is popping out for Rdot in SPEC33, it still there.

Yeah, I've just not been able to trigger it myself which makes it hard to attack

when entering the near zone, I got some errors in the console too:

That seems to be the same I'm currently trying to investigate.

[Thorsten]

It turns out to be one of the most mysterious things I've ever seen.

I managed to reproduce a situation in which the NaN appears, but printing out all involved variables via the Nasal console reveals that none of them has the value NaN, they're all numbers, and there's only summation involved.

Moreover, for some reason the delta measure for time goes to zero, which *should* cause a NaN in the involved variables, but actually does not when I print them.

The 'rendezvous object disappears' bug likewise is a case of all coordinates print out sane right till the bug appears.

So it's not a simple algorithm problem... it has the flavour of something deeper.

[eatdirt]

Good you managed to reproduce. If that can help, for the Nan in Rdot, it appears when I resume from SpaceShuttle-mission, but, from the same save file, it is always absent if I resume from SpaceShuttle-launch!

[Thorsten]

Okay, it seems to be a combination of different issues. The root cause is that the proximity manager which provides the data for the handover to the detailed model as well as SPEC 33 is a child process of the main orbital loop - when the main orbital loop gets initialized a second time in exactly the same frame, it leads to variables being unset in a second pass while the first pass rolls and similar funky stuff.

Now, the danger of running the loop twice I have actually forseen in principle which is why there's an init routine which checks whether it already runs, but...

1) There were two old instances of code path which did not use the init but started the loop directly
2) The save/resume code was actually not meant to be able to resume a complicated scenario from anywhere but the ground, that idea appeared only later

-> so there was an unsafe and insufficiently tested code path allowing to double the loop

This opens three possibilities:

a) when resuming from the ground (or the orbit scenario) when the orbital main loop is not yet running, no problem occurs

b) when the resume causes a large frame delay (usually Earthview being forced to load new textures would do this), the two loop instances run in exactly the same frame, leading to a zero delta time and the rdot = NaN error because two distances divided by zero result in NaN - for probably the same reason, this causes the handover to fail because the same coordinate object is first prepared, then nulled again by the second instance while the init code of the first instance then grabs the nulled object

c) when the resume does not cause a large frame delay, the two loop instances run in different frames - this kind of works, but of course means that messages about the targeting code running another instance appear, because the first loop instance gets to run the targeting code, and when the second tries a few frames later, the targeting is already running of course.


This explains why the whole thing is not obvious to reproduce.

Anyway, it's a great day for logical reasoning, because I managed to work all of this out in my head by carefully considering all the evidence for half an hour... and lo and behold, the first test afterwards revealed the second loop instance.

Needless to say, should be fixed now.

[GinGin]

Wow, very nice catch.
Not easy at first sight indeed Well done !!

[legoboyvdlp]

Is this something to be concerned about?

Nasal runtime error: nil used in numeric context
124.59 [ALRT]:nasal at C:/Users/redpa/Documents/FlightGear/Custom Aircraft/SpaceShuttle/Nasal/rel_orbital.nas, line 2900
124.59 [ALRT]:nasal called from: C:/Users/redpa/Documents/FlightGear/Custom Aircraft/SpaceShuttle/Nasal/rel_orbital.nas, line 2226
124.59 [ALRT]:nasal called from: C:/Users/redpa/Documents/FlightGear/Custom Aircraft/SpaceShuttle/Nasal/rel_orbital.nas, line 3187

Or is it again a missing parameter in the mission file - I'm fairly sure it isn't (checked it a couple times) but I could have missed something obvious.

[Thorsten]

I see no reason why it should happen - how do you trigger it?

[legoboyvdlp]

It happens on initialization of the aircraft.

[eatdirt]

Congrats Thorsten, and it is a great day for the Shuttle. You nailed them, well done!

[Thorsten]

It happens on initialization of the aircraft.

Not for me unfortunately...

[eatdirt]

it actually should resume to the position relative to the far zone target

Just for information, even if not supported, I did another test at the end of my stationkeeping to HST. I saved the state while I was at a few meters from Hubble, and then I resumed it a few seconds after, still within the same fgfs session. HST ended up a few hundred kms away, so something big seems to be happening for a resume within the proximity zone.

PS: this is before your last fixes though.

[legoboyvdlp]

Is the left glare light working for everyone else?

[Thorsten]

Yes, working fine here.