Why would "Player.moveto" sometimes fail?

[PJMail]

I find that for some users my Mod's teleporting of the player into the Commonwealth (at a fixed location) sometimes fails and after the blackout the Player has not moved.

Worse, if I check after the Moveto the player's worldspace is reported as Commonwealth - but they are not there (they are still in nukaworld).

Does anyone have an idea under what conditions the game decides not to complete the "moveto"?

Thanks.

[SKKmods]

I have seen this before in a condition where the MoveTo target object is persistent and the script/alias has a pointer but the game cant find/resolve the target object at that time. 

No idea why it happens. 

You can detect the error condition by either doing a dynamic conditional questfill on the object before the move, or grabbing player XYZ before and comparing after the move (round float to int to trim in place jitter).

[PJMail]

Well, that fits. Destination was a persistent marker, which I thought should always be resolvable. Never underestimate bugthesda.

Didn't think to check the xyz after the move, though - thought the Worldspace would be enough (silly me).

[SKKmods]

For pleasing platform consistency it also happens in Starfield  

Oh and since CE2 seems to decouple Papyrus execution from rendering/frames the player often falls through the world as MoveTo can complete BEFORE the landscape has rendered (maximum luls ... PreloadExteriorCell or WaitFor3dLoad do not help).

[LarannKiar]

I encountered this as well. Do you see anything in the Papyrus log?

I haven't investigated the cause of this issue but here are the error codes the native MoveTo and MoveToNode code dumps in the log if called from a script. I remember the one "does not have any 3d and cannot be moved"..

"cannot be moved to a None object\'s location";
"does not have any 3d and so cannot be moved to";
"does not have a node named \'%s\';
"cannot be moved";
"cannot be moved with a matching node because it has no 3D";
"cannot be moved with a matching node because its 3D has no node named \'%s\';

 

[PJMail]

On 1/13/2024 at 10:28 PM, SKK50 said:

For pleasing platform consistency it also happens in Starfield  

Oh and since CE2 seems to decouple Papyrus execution from rendering/frames the player often falls through the world as MoveTo can complete BEFORE the landscape has rendered (maximum luls ... PreloadExteriorCell or WaitFor3dLoad do not help).

Oh great! Preload was going to be my next attempt (once I could make it happen reliably again).

[PJMail]

4 hours ago, LarannKiar said:

I encountered this as well. Do you see anything in the Papyrus log?

I haven't investigated the cause of this issue but here are the error codes the native MoveTo and MoveToNode code dumps in the log if called from a script. I remember the one "does not have any 3d and cannot be moved"..

"cannot be moved to a None object\'s location";
"does not have any 3d and so cannot be moved to";
"does not have a node named \'%s\';
"cannot be moved";
"cannot be moved with a matching node because it has no 3D";
"cannot be moved with a matching node because its 3D has no node named \'%s\';

 

I did not see anything in the papyrus logs, but I have not been able to cause it to happen to me lately - only others. Since it is the player, only the first 2 errors seem likely. I am creating an Xmarker at the destination and moveto that, not sure how else I can do it - the player always teleports to an unloaded area by definition (so can't do a 'waitfor3dload' as 3d loading requires player presence - catch 22).

[PJMail]

Is there a way to immobilize the player (so they can't 'fall through the landscape') while waiting for everything to render? A bit like disabling physics until the ground renders?

[SKKmods]

To be clear the falling thru landscape is specifically for CE2 == Starfield (my workaround is to freeze player controls and test for - player Z change after moveto).

PreloadExteriorCell may work for the Fallout 4 issue.

[PJMail]

I understood that - I wanted the player not to fall to far at the end (as I was transporting them into the air so they didn't appear in terrain) so some way of freezing them would be useful...