Always ran away bug is fixed

[Prometheus]

So I have had three survivors run away in my Breakdown campaign so far. And as we know, that is problematic, because you cannot break them out of that state again, unless you ignore them the next time they run away, and then do the second leg of the recovery mission.

I have rescued all three of them immediately, so I have not done the old fix. I checked before I exited the game last time and saw two of them on History: Ran Away. I thought that was odd, as I have seen several reports that it was still bugged.

Lo and behold, I load the game up, and now only one of them is on History: Ran Away. And they have cleared in the same order that they ran away. I took notes on who had the status, so I know for sure that they cleared.

So... It's fixed as far as I can tell.

[Fried Noodles]

Nothing's changed since the last version of State of Decay.
Ran Away's always had a chance to fix itself ... in Breakdown.

There is, and always has been, a recovery condition as part of the 'Next Day' fatecards in Breakdown. But it had a low percent chance of success.

This recovery condition was absent in story mode State of Decay.




I increased the recovery chance in my game and also added evolve mechanics to the Ran Away mood so that normal things (like injury or sickness, or pride from completing missions / turning in supplies) could affect it.
The latter was especially useful in story mode, which had no recovery option at all by default.

[Prometheus]

I have not tested it in Story mode, but it was a short break like an hour or so. I doubt there was a "next day" in such a short timespan.

[Fried Noodles]

The Next Day thing can be buggy at times.
I've gone into the game for the first time in a day, saw all the next day stuff, logged out, then gone back in a few minutes later and had it all pop up again.

But as far as I know, from examining the game files (and trying to fix this very problem) myself, the only evolve action under MoodType.fled is NEXT_DAY.

However, I believe random fatecard events that affect MoodType can also overcome MoodType.fled.

If there's a random fatecard pop up (like a discord event where two survivors are reportedly at odds with one another, or food poisoning, or accidental friendly fire), if the survivor with Ran Away is involved in this fatecard, their moodtype might change to Trait.MoodType.Sick, or Trait.MoodType.Hurt or give them a random disapproval or depressed mood.

Check your journal entries to see which entry actually changed their mood, if it's still in your log.

[Prometheus]

No wound or sickness. They were in perfect health. I had at least one jealousy event with the one that cleared while in game, but that did not clear it. After booting up again, and seeing it had cleared, I logged off after about 20 minutes, so chances are low that it has been crowded out by other messages, so I will check the journal.

[Prometheus]

So, there is of course no date change in the journal, because it is all in the same real time day. I can see events that I have been the cause of, both before and after the reload, and thus the change, so the entire time line is there.

There are some supply finds, made by other characters. There is a food poisoning involving only Lily. And really nothing else. Under summary, there are two attitude changes. One involves Jacob going to numb, but he did not run away. Then there is Royelle Vincent and he went to uncertain. That is the one that cleared. No event explaining the attitude changes.

You will have to interpret that for me.

[Fried Noodles]

Originally posted by Prometheus:

So, there is of course no date change in the journal, because it is all in the same real time day. I can see events that I have been the cause of, both before and after the reload, and thus the change, so the entire time line is there.

There are some supply finds, made by other characters. There is a food poisoning involving only Lily. And really nothing else. Under summary, there are two attitude changes. One involves Jacob going to numb, but he did not run away. Then there is Royelle Vincent and he went to uncertain. That is the one that cleared. No event explaining the attitude changes.

You will have to interpret that for me.

Which journal entry is his mood change listed under?
"Survived Another Day" or w/e?

Because a Ran Away person going to Uncertain is consistent with what I've found.
Under the Trait.MoodType.Fled EVOLVE action, there's a 50% chance of becoming Uncertain (Trait.Mood.Neutral_Uncertain), which will switch them to Trait.MoodType.Neutral.

[Prometheus]

It is listed under "Summary: Survived Another Day". With a low chance of success, it is statistically unlikely I would get two in a row and then with success on both, but not impossible. If the mechanics are as you say, then Ockham's would dictate that it indeed is such a statistical fluke.

I won't be doing Storyline any time soon, so I won't be of any help in that mode. But I do still have the other guy. I'll see if I can break him out of it with me controlling him. If I do, I'll report back.

[Fried Noodles]

If you're interested, this is the entry that both defines the moodtype that is represented by History: Ran Away, and shows the Evolve Event that dictates if and how the moodtype can be fixed.

Other negative events have a lot of other Evolve Events in addition to a Next_Day condition, which makes them much more managable.
In my game, I copied these other conditions and appended them to this entry.


The entire Evolve Event is completely missing in the base game.

    <CharacterTrait BadgeName="" Flags="Hidden" Icon="" TraitId="Fled" Badge="" IconId="">
      <DescriptionText Flags="" Notes="Trait Description" Text="" />
      <ExpertiseBlock />
      <NameText Flags="" Notes="" Text="" />
      <CharacterBonuses />
      <CommunityBonuses />
      <Evolve Event="NEXT_DAY">
        <Action ActionFlags="" ActionId="Default" ActionType="Action.Passive" ExecuteTimeStandard="0.0" OutputDelayTime="0.0" PauseWhenOffline="">
          <RTSActionIcon Name="" Id="" />
          <NameText Flags="" Notes="" Text="" />
          <Actors />
          <Alts />
          <Effects />
          <Inputs />
          <Outputs>
            <Console_Command Command="LOG: Fled Recovery Chance" />
            <ExecuteAction ActionId="Switch" />
          </Outputs>
        </Action>
        <Action ActionFlags="Subaction" ActionId="Switch" ActionType="Action.Passive" ExecuteTimeStandard="0.0" OutputDelayTime="0.0" PauseWhenOffline="">
          <RTSActionIcon Name="" Id="" />
          <NameText Flags="" Notes="" Text="" />
          <Actors />
          <Alts>
            <Alt AltId="BecomeNeutral" AltOdds="50.0" />
          </Alts>
          <Effects />
          <Inputs />
          <Outputs />
        </Action>
        <Action ActionFlags="Alt" ActionId="BecomeNeutral" ActionType="Action.Passive" ExecuteTimeStandard="0.0" OutputDelayTime="0.0" PauseWhenOffline="">
          <RTSActionIcon Name="" Id="" />
          <NameText Flags="" Notes="" Text="" />
          <Actors />
          <Alts />
          <Effects />
          <Inputs />
          <Outputs>
            <Actor_GiveTrait ActorIndex="" DuringMission="" OutputDuration="" PauseWhenOffline="" Trait="Trait.Mood.Neutral_Uncertain" />
          </Outputs>
        </Action>
      </Evolve>
      <PlayerBonuses />
      <SubTraits />
    </CharacterTrait>

[Prometheus]

Very helpful.

I can't code if it was to save my life, but I do know various types of logic, so I can pretty much follow what is going on here, and improvise simple hacks when I need to. So in essence, what you did was to expand the portfolio of events that triggers "History: Ran Away" and upped the recovery chance to 50%. I could implement this if I get tired of the Vanilla design.

I gather I would need to wait for the decryption of pak files, right?

But with a design like the one you describe for unmodded recovery, and the structure of the Evolve events for other negative events, it could very well be that UL consider this to be WAD, despite the consequences.

[JTM]

This is NOT fixed.

For it to be fixed, the "History: Ran Away" should never show up in their mood slot in the first place as it is not a mood. It's been reported to UL's inumerable times in the past...it's just simply not on their priority list to fix.

As Harmonica Treks explains, nothing has changed and there is simply the random chance for it to clear in BD.

[Prometheus]

Originally posted by jtm2001:

For it to be fixed, the "History: Ran Away" should never show up in their mood slot in the first place as it is not a mood. It's been reported to UL's inumerable times in the past...it's just simply not on their priority list to fix.

I get that stictly speaking, History: Ran Away is not a mood, but that does not mean it cannot be informative for a player to have that information. But it would make a lot more sense, if say a countdown timer triggered it's clearance, and there was a mood concurrently attached to the character, while History: Ran Away was displayed.

[JTM]

Originally posted by Prometheus:

Originally posted by jtm2001:

For it to be fixed, the "History: Ran Away" should never show up in their mood slot in the first place as it is not a mood. It's been reported to UL's inumerable times in the past...it's just simply not on their priority list to fix.

I get that stictly speaking, History: Ran Away is not a mood, but that does not mean it cannot be informative for a player to have that information. But it would make a lot more sense, if say a countdown timer triggered it's clearance, and there was a mood concurrently attached to the character, while History: Ran Away was displayed.

The problem is that the survivors are subjected to far more traumatic events than simply running away and those events are not put up improperly in the mood slot where a deliberate positive morale event for the survivor fails to effect a change because it doesn't belong there in the first place. There is an event log for just about everything that happens to everyone already. That is the proper place for such events to be recorded. A mood change may or may not be derived from such an event, but if so, then it's proper place is in the mood slot and a reason for the mood change is usually recorded in the event log already.

Because there is not a seemingly great negative consequence to having the 'History: Ran Away' status....despite the unhappy face... is most likely the reason this has not been treated with any real priority and has yet to be fixed.

[Prometheus]

Okay, that makes sense. And theory on the no-fix ties neatly into that explanation.

I seem to recall that run aways tend to run away repeatedly after getting the status "history: run away". If it is not a mood, how does that make sense. I mean, then it wouldn't tie in as a trigger to other events, would it? Or how does it work?

[JTM]

Originally posted by Prometheus:

Okay, that makes sense. And theory on the no-fix ties neatly into that explanation.

I seem to recall that run aways tend to run away repeatedly after getting the status "history: run away". If it is not a mood, how does that make sense. I mean, then it wouldn't tie in as a trigger to other events, would it? Or how does it work?

Those are good questions and really require someone to analyze the code and/or script related to triggering a 'missing survivor' event.

However, my observations concerning behavior of survivors with the "History: Ran Away" tag has been that they are no more prone to running away than anyone else in camp. Number of infestations on the map, not just nearby home, and hordes all appear to contribute to the chance to trigger a 'missing' survivor event.

[Prometheus]

So I loaded up the game again, after the last observations. No play time in between, and the third survivor has now cleared his "History: Ran Away" status. It has happened in the same way as previously described, the change to uncertain noted in the "Summary: Survived another day" entry, no other events listed that involved him.

That is three in a row, all cleared up in the order in which they intitially got the status. It might be a continuation of the statistical fluke, but there certainly seems to be a pattern to this.