CWResetGarrisonScript - AKA the Garrison1 reset spam bug

[Arthmoor]

For awhile now there have been several lingering bugs involving the Civil War and various scripts filling up the Papyrus log with spam. One of them, as the title indicates, is CWResetGarrisonScript, filed as Bug #13860. There had never been much indication of what caused this until Pete pinned down one of the causes as being when Irileth sends the guards down to Riverwood. He provided a test save, which I advanced slightly to the point where I can load it, hit the wait menu for 4 hours, and then have the bug trigger on demand.

 

Stage 100 of MQ103 is where the mess begins. It calls the AddGarrisonBackToWar function for Riverwood. This is necessary because Bethesda runs the command to take Riverwood off the garrison list some time prior to completing Helgen.

 

I spent a bunch of time last night inserting debug tracers trying to find where the log spam begins. The complete log of the session is available here: http://pastebin.com/Rs9HgPji

 

The relevant portions up until things go south:

[06/08/2014 - 03:13:56AM] USKP - Fragment_0: Location = [Location < (00013163)>]
[06/08/2014 - 03:13:56AM] USKP - Fragment_0: Running kmyquest functions
[06/08/2014 - 03:13:56AM] USKP - ToggleEnableMarkers: Location = [Location < (00013163)>]
[06/08/2014 - 03:13:56AM] USKP - ToggleEnableMarkers: Owner = Imperials
[06/08/2014 - 03:13:56AM] USKP - ToggleEnableMarkers: Enabling Imperial marker
[06/08/2014 - 03:13:56AM] USKP - ToggleEnableMarkers: Disabling Sons marker
[06/08/2014 - 03:13:56AM] USKP - ProcessSoldierAliases: Begin processing aliases
[06/08/2014 - 03:13:56AM] USKP - ProcessSoldierAliases1: There should be six in total, all called through this function
[06/08/2014 - 03:13:56AM] USKP - ProcessSoldierAlias: Actor = [Actor < (0001B744)>]
[06/08/2014 - 03:13:56AM] USKP - ProcessSoldierAlias: Resetting [Actor < (0001B744)>]
[06/08/2014 - 03:13:56AM] USKP - SetCrimeFactionForSoldierAlias: Alias = [ReferenceAlias <alias Soldier1 on quest CWResetGarrison1 (000236A3)>]
[06/08/2014 - 03:13:56AM] USKP - SetCrimeFactionForSoldierAlias: Actor = [Actor < (0001B744)>]
[06/08/2014 - 03:13:56AM] USKP - CWs.DetermineAndSetCrimeFactionForSoldierActor: Actor = [Actor < (0001B744)>]
[06/08/2014 - 03:13:56AM] USKP - CWs.GetMyEditorLocationHoldLocation: RefToGetEditorLocHoldFor = [Actor < (0001B744)>]
[06/08/2014 - 03:13:56AM] USKP - CWs.GetMyEditorLocationHoldLocation: EditorLocation = None
[06/08/2014 - 03:13:56AM] Error: Cannot check location against a None location
stack:
    [ (00016770)].Location.IsChild() - "<native>" Line ?
    [CW (00019E53)].cwscript.GetMyEditorLocationHoldLocation() - "CWScript.psc" Line 1913
    [CW (00019E53)].cwscript.DetermineAndSetCrimeFactionForSoldierActor() - "CWScript.psc" Line 2047
    [CWResetGarrison1 (000236A3)].CWResetGarrisonScript.SetCrimeFactionForSoldierActor() - "CWResetGarrisonScript.psc" Line 467
    [CWResetGarrison1 (000236A3)].CWResetGarrisonScript.SetCrimeFactionForSoldierAlias() - "CWResetGarrisonScript.psc" Line 458
    [CWResetGarrison1 (000236A3)].CWResetGarrisonScript.ProcessSoldierAlias() - "CWResetGarrisonScript.psc" Line 255
    [CWResetGarrison1 (000236A3)].CWResetGarrisonScript.ProcessSoldierAliases1() - "CWResetGarrisonScript.psc" Line 289
    [CWResetGarrison1 (000236A3)].CWResetGarrisonScript.ProcessSoldierAliases() - "CWResetGarrisonScript.psc" Line 271
    
    <truncated stack>

Everything goes as planned until it hits CWScript, function GetMyEditorLocationHoldLocation, at which point for some unknown reason the GetEditorLocation call fails to pick up a location even though the Actor is valid.

 

Once this happens, the remainder of it all blows up. Just with Riverwood's 6 available guard refs, it generates nearly 700 lines of log. A larger city doing this sets off thousands - and yes, I've seen logs from the major capitols do exactly that. People have also reported that this log spam gets generated when any of the forts that are part of the war get reset to swap over control to one of the sides rather than bandits or whatever.

 

The end result being that whatever should be getting done to complete the swap can't happen because everything gets shredded by these NONEs.

 

I have checked the properties on MQ103, CW, and CWResetGarrison1. Nothing is missing.

 

My only guess at this point is that there's data on the Actor being lost when it's sent to CWScript as a parameter, but that would imply something very broken about Papyrus if that's the case.

 

Does anyone have any ideas?

[Arthmoor]

On the advice, and a bit of an extra hunch, I modified the tracers to gather data from the initial stage fragment.

 

That portion of the script results in this with the new tracers:

 

[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Dumping aliases to log
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Garrison Location = [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier01 Editor Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier02 Editor Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier03 Editor Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier04 Editor Location: None
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier05 Editor Location: None
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier06 Editor Location: None
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier01 Current Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier02 Current Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier03 Current Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier04 Current Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier05 Current Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Soldier06 Current Location: [Location < (00013163)>]
[06/08/2014 - 03:05:33PM] USKP - Fragment_0: Running kmyquest functions

 

The soldiers coming up as NONE for their editor locs are consistently always the Imperials, yet the current loc seems to do just fine, which defies logic. I don't know if this is something that is consistently reliable with other garrisons, but the Riverwood would be fixable by using GetCurrentLocation() instead.

 

Does this reveal a bug in GetEditorLocation() ? I can't come up with a good reason for these results without concluding that.