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 http://afkmods.iguanadons.net/index.php?/tracdown/issue/13860-cwresetgarrisonscript-cannot-check-location-against-a-none-location/. 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:

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?

My best bet would be to first check if for GetCurrentLocation() in both scripts and see if data is missing from the CWScript...

Good call. Took it to the logical end and checked the aliases immediately in Fragment_0, which is before any of the extra stuff gets done. That portion of the script results in this with the new tracers:

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.

If other functions are buggy / quirky then there's no good reason why GetEditorLocation() can't be among them. I'm only guessing but could there be a difference in the casting when it's called causing it???

Don't know about that.

I do know that changing two calls for GetEditorLocation() into GetCurrentLocation() has eliminated the problem in Riverwood - which will carry over into several other locations reported to have caused the exact same errors.

Then it seems like the GetEditorLocation() function seems to react odd in this case...

But good that GetCurrentLocation() seems to be a good alternative and fixes the problems