May be the a small fire or electrical fire broke out in the airlock and there's no way to have it put out because they didn't bring a CO2 extinguisher.
Prior to that, it could be a rover's generator failure that stalls the expedition.
I'll look up the code to see if it allows a secondary cause.
Realistically speaking, we could intentionally allow MSP to simulate different modes of failure.
When the system reaches the tipping point, it lost the equilibrium and stability and escalate into the point of no return.
It could be a chain of events that happens. These events together may result a castatrophic failure.
There are also mishaps that are caused by a single point of failure, instead of multiple reasons.
So, in future MSP, there will be even more ways to die :) And suffocation can have multiple reasons.
Last edit: manny kung 2015-10-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's a good observation. I'm sorry for that omission. I'm double checking the codes to see if it will check for the status (alive/death) of the person when displaying the Task description.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When a person has died, the activity information (job, task, and mission) remains static as to what he/she was doing at the time of death. In this particular case Lena was running out of oxygen while in the embarking phase of an exploration mission. My guess is that it's related to some bug in the airlock code that we've fixed since then in the 3.08 development, but I can't say for certain. She was probably in a situation where she wasn't able to do anything useful as her oxygen ran out (due to the bug), and so was just sitting there eating some dessert at the end.
So is there a more clear way of presenting the last activities of a person before they died? Perhaps we could change the title text in the activity panel to say "Last Task" or "Task at Moment of Death" or something along those lines when a person has died. Alternatively we could set them to "None" and list the last job, task, task phase, mission, and mission phase on the Death panel.
Also, on the Death panel, the "Malfunction (if any)" field will show any local malfunctions that may have contributed to the person's death. It only shows the most serious non-repaired malfunction at the time of death. In this case it doesn't appear that there was a malfunction in the settlement at the time and I'm guessing this was due to a person getting stuck outside due to a bug in the airlock code (the bug isn't technically a malfunction in simulation terms). I'll have to look to see that when the person is outside at the time of death, if that checks for the nearby settlement or rover has a malfunction.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From line 112 to 126, we compute the String malfunction as follows:
Iterator<Malfunctionable> i = MalfunctionFactory.getMalfunctionables(person).iterator();
Malfunction mostSerious = null;
int severity = 0;
while (i.hasNext()) {
Malfunctionable entity = i.next();
MalfunctionManager malfunctionMgr = entity.getMalfunctionManager();
if (malfunctionMgr.hasEmergencyMalfunction()) {
Malfunction m = malfunctionMgr.getMostSeriousEmergencyMalfunction();
if (m.getSeverity() > severity) {
mostSerious = m;
severity = m.getSeverity();
}
}
}
if (mostSerious != null) malfunction = mostSerious.getName();
I suppose this is not as exhaustive as we want to include yet.
Other than calling the MalfunctionManager, may be we can look up the HistoricalEventManager to find out any record relating what happen to his rover,etc.
Ideally speaking, getting suffocated can have a number of reasons. The EVA suit may have an air leak and O2 was drained.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We've already submitted a few commit(s) that display a short phrase of "at the moment of death" in a few places in Person Window to improve how mars-sim presents this fact.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, also...
Malfunction isn't listed as lack of oxygen, or anything.
Should I just make a new ticket for this or keep them together?
Last edit: Kurai Kokoro 2015-08-17
May be the a small fire or electrical fire broke out in the airlock and there's no way to have it put out because they didn't bring a CO2 extinguisher.
Prior to that, it could be a rover's generator failure that stalls the expedition.
I'll look up the code to see if it allows a secondary cause.
Realistically speaking, we could intentionally allow MSP to simulate different modes of failure.
When the system reaches the tipping point, it lost the equilibrium and stability and escalate into the point of no return.
It could be a chain of events that happens. These events together may result a castatrophic failure.
There are also mishaps that are caused by a single point of failure, instead of multiple reasons.
So, in future MSP, there will be even more ways to die :) And suffocation can have multiple reasons.
Last edit: manny kung 2015-10-18
That's a good observation. I'm sorry for that omission. I'm double checking the codes to see if it will check for the status (alive/death) of the person when displaying the Task description.
When a person has died, the activity information (job, task, and mission) remains static as to what he/she was doing at the time of death. In this particular case Lena was running out of oxygen while in the embarking phase of an exploration mission. My guess is that it's related to some bug in the airlock code that we've fixed since then in the 3.08 development, but I can't say for certain. She was probably in a situation where she wasn't able to do anything useful as her oxygen ran out (due to the bug), and so was just sitting there eating some dessert at the end.
So is there a more clear way of presenting the last activities of a person before they died? Perhaps we could change the title text in the activity panel to say "Last Task" or "Task at Moment of Death" or something along those lines when a person has died. Alternatively we could set them to "None" and list the last job, task, task phase, mission, and mission phase on the Death panel.
Also, on the Death panel, the "Malfunction (if any)" field will show any local malfunctions that may have contributed to the person's death. It only shows the most serious non-repaired malfunction at the time of death. In this case it doesn't appear that there was a malfunction in the settlement at the time and I'm guessing this was due to a person getting stuck outside due to a bug in the airlock code (the bug isn't technically a malfunction in simulation terms). I'll have to look to see that when the person is outside at the time of death, if that checks for the nearby settlement or rover has a malfunction.
I just looked up DeathInfo.java
From line 112 to 126, we compute the String malfunction as follows:
Iterator<Malfunctionable> i = MalfunctionFactory.getMalfunctionables(person).iterator();
Malfunction mostSerious = null;
int severity = 0;
while (i.hasNext()) {
Malfunctionable entity = i.next();
MalfunctionManager malfunctionMgr = entity.getMalfunctionManager();
if (malfunctionMgr.hasEmergencyMalfunction()) {
Malfunction m = malfunctionMgr.getMostSeriousEmergencyMalfunction();
if (m.getSeverity() > severity) {
mostSerious = m;
severity = m.getSeverity();
}
}
}
if (mostSerious != null) malfunction = mostSerious.getName();
I suppose this is not as exhaustive as we want to include yet.
Other than calling the MalfunctionManager, may be we can look up the HistoricalEventManager to find out any record relating what happen to his rover,etc.
Ideally speaking, getting suffocated can have a number of reasons. The EVA suit may have an air leak and O2 was drained.
We've already submitted a few commit(s) that display a short phrase of "at the moment of death" in a few places in Person Window to improve how mars-sim presents this fact.