Unofficial Fallout 4 Patch

Unfortunately though, it doesn't.This check is unreliable because GetCurrentLocation() returns 'none' if the player is currently in workshop mode.

Is that what's causing the bogus location change events to fire? The engine forcibly sets the player's location to 'none' while in workshop mode? Man, Bethesda, what a bug that is.

Yes. WorkshopParentScript interpreted the bogus location changes as valid events and started a workshop reset whenever the player left the workshop menu or workshop mode. This in turn could cause the settler assignment issue to affect even workshops with very low resource object counts.

Hmm... I tried testing this myself with a function that would do this for a bit when I ran it

for int i = 0 to 20
	Debug.Trace("loc: " + PlayerRef.GetCurrentLocation())
	Debug.Trace(Game.GetPlayer().GetCurrentLocation())
	Utility.Wait(1)
endfor

(that's using Caprica language extensions for the for loop because I use it as my primary compiler anyway)
Anyway, I ran that function and went into workshop mode, and the printout always returned the correct location.

Additionally, I uncommented a bit of debug code I already had in an Actor.OnLocationChange event, where the only actor I had registered for remote events on was the player, so it would dump akNewLoc to the log every time that event fired. I tried entering/exiting workshop mode in a few different settlements, building/scrapping a few different things, and using some crafting stations, and my script never picked up any bogus location change events, only ever real ones when I actually did change locations.

Could it be that the bug was fixed in a newer version of the game? Or perhaps it's install-dependent somehow?

Now you beat me.

I honestly couldn't remember whether it ever was 'none' or just another inappropriate value, so I turned the traces in the OnLocationChange event of WorkshopParentScript back on. This is what I get on the log while staying INSIDE the boundaries of Oberland Station. I entered and left workshop mode a couple of times and also activated the workbench:

[03/25/2018 - 12:49:00PM] OnLocationChange: akOldLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:49:00PM] OnLocationChange: akNewLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:49:00PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:49:00PM] OnLocationChange: exited workshop location [Location < (0009B1C2)>]
[03/25/2018 - 12:49:19PM] OnLocationChange: akOldLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:49:19PM] OnLocationChange: akNewLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:49:19PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:49:19PM] OnLocationChange: entered workshop settlement location [Location < (0009B1C2)>]
[03/25/2018 - 12:49:19PM] OnLocationChange: New workshop location is the same as the last workshop location left by the player.
[03/25/2018 - 12:49:19PM] OnLocationChange: Game time since last reset = 0.339600
[03/25/2018 - 12:49:19PM] OnLocationChange: Skipping reset.
[03/25/2018 - 12:49:21PM] OnLocationChange: akOldLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:49:21PM] OnLocationChange: akNewLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:49:21PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:49:21PM] OnLocationChange: exited workshop location [Location < (0009B1C2)>]
[03/25/2018 - 12:49:29PM] OnLocationChange: akOldLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:49:29PM] OnLocationChange: akNewLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:49:29PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:49:29PM] OnLocationChange: entered workshop settlement location [Location < (0009B1C2)>]
[03/25/2018 - 12:49:29PM] OnLocationChange: New workshop location is the same as the last workshop location left by the player.
[03/25/2018 - 12:49:29PM] OnLocationChange: Game time since last reset = 0.341949
[03/25/2018 - 12:49:29PM] OnLocationChange: Skipping reset.
[03/25/2018 - 12:49:34PM] OnLocationChange: akOldLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:49:34PM] OnLocationChange: akNewLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:49:34PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:49:34PM] OnLocationChange: exited workshop location [Location < (0009B1C2)>]
[03/25/2018 - 12:49:35PM] OnLocationChange: akOldLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:49:35PM] OnLocationChange: akNewLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:49:35PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:49:35PM] OnLocationChange: entered workshop settlement location [Location < (0009B1C2)>]
[03/25/2018 - 12:49:35PM] OnLocationChange: New workshop location is the same as the last workshop location left by the player.
[03/25/2018 - 12:49:35PM] OnLocationChange: Game time since last reset = 0.343307
[03/25/2018 - 12:49:35PM] OnLocationChange: Skipping reset.
[03/25/2018 - 12:53:33PM] OnLocationChange: akOldLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:53:33PM] OnLocationChange: akNewLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:53:33PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:53:33PM] OnLocationChange: exited workshop location [Location < (0009B1C2)>]
[03/25/2018 - 12:53:38PM] OnLocationChange: akOldLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:53:38PM] OnLocationChange: akNewLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:53:38PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:53:38PM] OnLocationChange: entered workshop settlement location [Location < (0009B1C2)>]
[03/25/2018 - 12:53:38PM] OnLocationChange: New workshop location is the same as the last workshop location left by the player.
[03/25/2018 - 12:53:38PM] OnLocationChange: Game time since last reset = 0.387939
[03/25/2018 - 12:53:38PM] OnLocationChange: Skipping reset.
[03/25/2018 - 12:53:51PM] OnLocationChange: akOldLoc = [Location < (0009B1C2)>]
[03/25/2018 - 12:53:51PM] OnLocationChange: akNewLoc = [Location < (00002CF0)>]
[03/25/2018 - 12:53:51PM] OnLocationChange: UFO4P_PreviousWorkshopLocation = [Location < (0009B1C2)>]; IsLoaded = True
[03/25/2018 - 12:53:51PM] OnLocationChange: exited workshop location [Location < (0009B1C2)>]

Which means that the check for the player's current location being the same as the workshop location will definitely fail.

If that's really dependent on specific installs, trying to fix that stuff would actually be a big waste of time, since you cannot say whether a bug that affects you does affect others nor whether others may have bugs that don't affect you for myterious reasons.

Another explantion that may come to mind, namely that this behaviour is specific to workshop related scripts (for whatever reason) can be safely excluded, since the script on DIalogueBunkerHill quest was affected by the same issue.

Okay, that makes sense. 2CF0 is CommonwealthLocation; what's likely is that the workshop boundaries for Oberland Station don't actually properly correspond with the location data on its constituent cells. Me, I have a mod that increases the cell footprint of nearly every settlement to ~2x3 or 3x3, which would certainly make it less likely for me to accidentally stumble into such a cell since I believe the same mod fixes this problem in every settlement it edits too.

I've had related issues with workshop objects before, where it's possible to place objects near the boundaries of many (vanilla) settlements so that the cell they're in isn't actually part of the settlement's location anymore. If I want to get a workshop object's location, it's necessary to run GetLinkedRef(WorkshopItemKeyword) on it to find its parent workbench, then run GetCurrentLocation() on that, because just doing GetCurrentLocation() on the object itself isn't reliable. Obviously this approach doesn't work on the player, though.

Unfortunately the underlying problem here, that being settlement cells not having proper location data set, isn't something that UFO4P can really reliably fix, simply because UFO4P's location high in the load order makes it likely for mods to overwrite cell-level location data changes. Ignoring that, it would be a massive pain to go over every single settlement and check that every single cell inside a given workshop boundary has correct location data, and then to make sure that the cell location footprint of each corrected settlement doesn't exceed 3x3 (except in the ones where it already does, namely Sanctuary, Spectacle Island and Boston Airport). It might still not be a bad idea, though, in case anyone wants to volunteer for that task (ugh).

I don't think that this is related to improper location data. As you can see in the log posted above, exiting workshop mode results in the player location (= newLocation) being instantly registered as the correct workshop locatio, so it can't be a problem of the cell I was standing in while I left workshop mode. And you always get that bogus event, irrespective of whether you are close to or far from the workshop boundaries.

You can easily test this yourself by recompling UFO4Ps WorkshopParentScript in debug mode. Before you do, you'll have to re-enable the traces in the OnLocationChange event. I commented them out a long while ago, once we had made sure that the procedure works as intended.

Recording the player's location as Commonwealth location while in workshop mode is worse than recording it as 'none', because it makes valid leave events (where the player changes into a wilderness cell that has no other parent location than the commonwealth location) indiscernible from invalid ones. Fortunatley, the fix didn't require to record a valid leave event; we only had to make sure that the workshop reset call is skipped if the player "re-enters" within a sufficiently short period of time.

Before I fiddle with WorkshopParentScript, I took a look at Oberland Station in the CK:
http://idek.chir.uno/fo4/oberland-station.JPG
There are only two cells tagged with the correct location (Farm03Location) out of the four that make up the workshop's boundary, which I marked in the image. You should be able to confirm this in-game by walking across the cell boundaries and seeing if location change events fire. Assuming that the event only fires when crossing over in or out of the two untagged cells, the game engine is doing it's job, but Bethesda messed up the cell data. This is definitely looking like a case of "garbage in, garbage out" to me, and not a malfunction of the scripts or engine itself.

Edit: I have also had a go at disabling all of my mod plugins (except for one, mine), and enabling some debug printouts to show a message box any time the player gets an OnLocationChange event, and print some stuff to the log:
[03/26/2018 - 09:45:28AM] Loaded a new location: [Location < (00002CF0)>], [Location < (0009B1C2)>]
[03/26/2018 - 09:45:30AM] Loaded a new location: [Location < (0009B1C2)>], [Location < (00002CF0)>]
[03/26/2018 - 09:45:31AM] Loaded a new location: [Location < (00002CF0)>], [Location < (0009B1C2)>]
[03/26/2018 - 09:45:34AM] Loaded a new location: [Location < (0009B1C2)>], [Location < (00002CF0)>]
(etc), anyway I can confirm that I only ever got these events when passing over the cell boundary I highlighted in the above image. This behavior is correct, but as mentioned, garbage in, garbage out.

It appears that you still didn't get the point. I did not check for faulty cells (yet), i.e. I did not run around while I recorded the log I posted above. I was standing near the workbench and entered /exited workshop mode a couple of times. In the meantime, I swapped items with some settlers in and around the tato field, and I did certainly not move outside of the cells that are still properly tagged, according to the image.

Anyway, checking for workshop mode being active will improve things in either case. If there a faulty cells where the location check alone would fail, the check for workshop mode can make it that there's a 'true' returned. If you aren't in workshop mode either, nothing will help though.

I'm still trying to understand the nature of the alleged bogus OnLocationChange events, since this sort of thing is relevant to my interests. I've now tried both listening for location change events sent from the player via an external script, as well as uncommenting the bits in WorkshopParentScript and recompiling. I've even added additional debug to WorkshopParentScript so I'd get a message box any time the location change event fires, and yet the events are still exclusively limited to me actually passing over a cell boundary and into a different location. Long load order, or one with only official DLC and UFO4P... nothing, no bogus events.

Have you tried adding a message box (or some other real-time feedback mechanism) to WorkshopParentScript yourself, to confirm 100% for sure that you're really getting them while standing still? Given that there's no sanity checking for this, maybe try adding akSender to your debug printouts to be sure that WorkshopParentScript didn't somehow get registered for OnLocationChange events from other actors?

I suppose the OnWorkshopMode-based checks can't hurt in any case, but it's strange that I'm completely unable to reproduce an ostensibly well-documented bug such as this one myself.

I posted the image about Farm03Location etc, because in that particular settlement, it's possible to cross unto untagged cells after only walking, like, 10 feet away from the workbench. You don't even need to go near any of the edges of the workshop boundary to leave the location there. Perhaps it would be prudent to open a separate bug report about that issue, since there are definitely improvements to be made there. If that one, and only, settlement I've looked at is that bad about its boundaries, I wonder what other settlements are similar, or worse.