Game seems to move NPC's position on 3D load for some unknown reason

[PJMail]

I have seen this before but don't know why the game is doing it. My NPC (Vertibird) lands on a perfectly good Navmesh in a settlement and stays there. If I save and restart the game it is still in that spot. If however I go away (fast travel) then fast travel back it sort of 'shakes' and ends up nearby. As if the game is doing some sort of correction. I have seen something similar if an NPC somehow is imbedded in the ground/building when you fast travel back they sort of 'rise' out of it until they are on top.

 

Anyone know what this game mechanic is and what triggers it?

 

The reason is I can totally freeze the game by placing my Vertibird on top of a certain building, leave and then fast travel back. The game slows to 1fps (or less) until the vertibird 'shakes' itself down to ground level. I had to let the game run for 30min before it got past 0fps so I could see that much.

 

It is rare condition, but once you have a location like this it is 100% repeatable.

 

(And google failed me)

Edited February 7, 2021 by PJMail

[SKKmods]

I dont know the actual answer, but it sounds similar to the why actors end up on the roofs of sanctuary houses if the player fast travel returns.

 

This affacts my solutons which use MoveToNearestNavmeshLocation() for arbitrary markerless spawning. There are huge chunks of Sanctuary that function will not recognise as valid navmesh even though actors happily path across, like the Sanctuary playground area and they end up on the roofs. Similar issue downtown around Haymarket mall. Detrecting and handling that needs several Z height tests.

 

So I would infer that fast travel kicks the engine level function that MoveToNearestNavmeshLocation() calls and you get these behaviors where the navmesh is not good. By good I dont mean what we can see as good in CK or xEdit but what the MoveToNearestNavmeshLocation sees as good. Different things. Also affects the Vertibord landing function GetSafePosition.

[PJMail]

You could be right there as the landing location is not what the vertibird would choose if you stuck a fast travel mat on it and used the pipboy to 'go to that settlement' - so it is not 'good' as far as GetSafePosition is concerned. Strangely other 'equally ungood' locations have no issues - just ones 'above the ground' (on top of structures build with Workshop) are a problem.

And even then, it would be tolerable if it didn't grind the system down to <1fps (Clearly Havok going wild).

 

P.S. Thanks for the info on NPC.Additem(weapon) causing the outfit reset bug, and your solution of container.removeallitems(NPC).

Just to add to your knowledge of Game quirks, Container.removeitem(weapon,,NPC) also sidesteps the outfit reset bug, as does AnotherNPC.removeitem(weapon,,NPC) BUT playerref.removeitem(weapon,,NPC) DOES cause the reset bug on NPC. Coincidentally (?) the player one also causes the weapon to be 'auto equipped' on NPC, yet the first 2 don't. Strange as NPC.equipitem(weapon) does not seem to cause a reset. Illogical.

[PJMail]

Looking closer at it confirms your idea - the 'on load' Z position was ground level (totally ignoring the Workshop construction it was parked on). Saving the Z pos OnUnload and restoring it OnLoad (if it had dropped) fixed the 1fps bug etc. Just another day fighting Bethesda bugs.

[niston]

Something's definitely wonky with the game's Z axis placement of Actors.

I made a mod to fix the problem re settlement turrets; They would occasionally fall onto the ground or even below ground (a bug that reportedly still exists in FO76).

Also noticed the problem with mannequins later on, so I suspect all Actors are randomly affected but for normal NPCs it's less noticeable because they move around.

 

Oh, and it gets much, much worse with refattached stuff (not just Actors). Suppose you have object A (think elevator button) refattached to object B (say, elevator platform), so that when you move object B, object A moves with it. Now, OnLoad, the engine randomly loses track of object A's relative Z position to object B, and reverts Object A to editor coordinate Z-Level. BUT object A is nonetheless still refattached to object B, and thus when object B moves, so does object A. In effect, the elevator button might end up at ground level OnLoad, while the platform really is 5 floors above. And if the platform then moves to ground level, the button moves 5 floors below ground. This problem is compounding, the offset gets worse every time the onLoad blunder happens. Yet, the biggest difficulty in providing remedy is that, if you try to read X/Y/Z from Object A, the engine will always return editor coordinates because this Object is refattached to something else - Making it very tricky to even detect from script that Object A got "misplaced" by the engine.

[PJMail]

I agree, Whatever that 'onload' logic is it is seriously borked (and why does it just pick on the Z axis?).

 

Also I am also starting to suspect this Papyrus compiler is buggy. I have a save point that I have been using for testing this Z axis stuff. I load the save, run to where the Vertibird is (it Onload's at some point of my run) eventually find it imbedded in the building. ok. change code, recompile one script, rerun. Suddenly (after just added one if statement inside a function) after my run I find the Vertibird NOT imbedded in the building! And the function I edited was therefore NOT called! How is that possible! I mean the first line of the onload has always been a trace line printing out the X,Y,Z coordinates of the Vertibird, and suddenly the first onload is reporting a different Z coordinate from all the other times I have run the same save!

 

One line in a piece of code not called has made the onload state of an actor change (and I know that line is not called as there is a debug line before it). That should not be possible.

 

The code I am talking about is on the Vertibird (not a quest or other independent process), and is the OnLoad code after the debug.trace I mentioned above - so called AFTER the debug line. It can't effect the Vertibirds x,y,z location BEFORE it is even called. But it did. Somehow.

 

Time for a holiday.

Edited February 9, 2021 by PJMail

[SKKmods]

I would suspect the Vertibird actor is unpredictable OnLoad and/or OnPlayerLoadGame rather than inconsitencies in the papyrus runtime.

 

But, I do suffer an inexplicable respect for the elegance of the Papyrus script system (most frustration stems from incomprehension).

[PJMail]

I would agree with both your statements, and certainly some outcomes change with each run from the same save (encounters for instance), but they are designed to be random - whereas what I am seeing is not normally random. The onplayergameload (coordinates) of the Vertibird is the same on every start (the same place as when the game save occured) but the later onload as different (but consistant - until now) coordinates. I am struggling to understand what has influenced this change. It make debugging a whole lot harder as well.