[Mars-sim-developers] walking bug/stuck in an airlock

[manny k. <man...@gm...>]

Hi Scott,

I'm revisiting an old issue regarding someone who get stuck in an airlock
of an observatory. The sim did not crash but my stack trace is flooded with
repeated logging statement and a stackoverflow.

Looking at the schedule tasks from a few sols ago, Ms Backman was first
requesting medical assistance on Sol 10 and being treated for a panic
attack and is recovering.

Since then she's been requesting medical help numerous time, up to today
the Sol 16. Sol 14 and Sol 15 tasks are missing and does not show up on the
Schedule Tab in Personal Window. Probably due to stackoverflow.

As an astronomer, her visit to do EVA is frequent an has to leave the
lander hab to get to the observatory daily.

Then a major fire occurs in the observatory in sol 12 and her fatigue is at
Bedbound level at 1540. Her performance is crippling (at zero). But she's
totally relaxed (stress is at 0).

This creates excessive logging about getting out of the airlock and
possibly because of that, it creates StackOverflowError in eclipse from
repetitive log statement

So, I'll going to:

a. Change from walkToBed(accommodations, person, false) to
walkToBed(accommodations, person, true) in Sleep.  This allows walkToBed()
to fail.

b. Annotate that calling getNewAction() enclosed inside a try-catch is
still considered "experimental" in canExitAirlock() in ExistAirlock.

c. Add setPerformanceFactor() in within the try-catch phrase in part b
above to "boost" a person's moral back to a sufficient level of confidence.

Note that I'm liberally assuming that in real life, a person would call
intercomm to request help from someone in imminent danger/trouble,

In this trivial case of getting stuck in an airlock of an observatory,
after speaking to someone, he may receive some morale support and his
performance level should GO BACK UP sufficiently to get himself out of
trouble :)

In future, I suggest we create a brand new "Desire" class (similar in scope
to Preference class) for modifying which near term Task(s) will have an
added bonus of probability to be chosen to performance.

May be we should also tune up the relationship between fatigue, stress and
performance. The 3 are interrelated.

I actually made a note inside canExitAirlock() in ExistAirlock.back in Feb
this year that I added getNewAction() inside a try-catch. For a while, it
seems to resolve one of those "walking bugs" that we encounter.

What else should we pay attention to and what other intervention should we
take ?

Regards,
Manny