Moving inactive player to new scene causes that player to continue old path
I've found a weird behaviour of which I am unsure whether it's caused by a hack from me or not.
What happens is if I run a MovePlayerInactive action in OnStart, the inactive player start walking on his own. It looks like his old path (from the previous scene) gets carried over to the new scene.
I tried fixing that with a line in SaveSystem.cs:1411:
playerData.playerPathData = string.Empty;
which helps, but instead, the inactive player now moves a lot faster when assigned to a new path (via action:moveOnPath).
To be clear, when the bug occurs the inactive player does not follow the player in either scene.
Regarding my hack, I wanted to enable inactive player follow (action: NPC follow) across differenct scenes for which I changed a true to false in SceneChanges.cs:688:
KickStarter.saveSystem.SaveNonPlayerData (false);
which now doesn't disable NPC following anymore when the scene data is saved. Is there perhaps a more elegant solution to this?
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
It may not be more elegant, but the safest way to allow an inactive Player to continue following the active Player across a scene is to manually move them to the new scene (Player: Teleport inactive) and then issue a new follow command (Character: NPC follow).
Does the issue itself cease if you undo both changes? So that I can attempt a recreation, what is his old path from the other scene? Was he following the player, or moving to some other point?
I reverted both hacks and the result is the same.
The inactive player was moving to a point in the middle of scene switch. What is weird is that yesterday the bug also happened if the inactive player reached the point prior to scene switch. But I think this might have been because of testing this with save games, where the inactive player had a path saved?
Now, the bug occurs only in the scenario as described above. (going to point)
I think that the parameter stopFollowCommands in SaveNonPlayerData shouldn't change here anything since the inactive player is not following but moving to point, so the EndPath() won't even be called. Maybe it should be?
NPC.cs:737
.
Would perhaps be a better solution to move the following inactive player into DontDestroyOnLoad during the scene change? That way his data shouldn't be saved in the previous scene and his follow data should remain intact. This is how multi-scene follow worked for me prior to the latest patch (before the inactive player workflow). I tried to keep this logic but it didn't work quiet well anymore.
All right - I'll attempt a recreation. Thanks for the info.
Inactive Players aren't stored as data specific to the scene they're in, exactly, but the recommended workflow does at least give you control over transition behaviour - i.e. how long before a character appears in the next scene, and where.
I'd be interested in hearing feedback about it though - both this workflow, and how you were managing things before.
Before the update I was using a custom NPC follow action which extended the base one. It also put the object in DontDestroyOnLoad so that destroy&re-instantiation wasn't, which was more performant.
I had a ManageNPCFollow script attached to the PersistentEngine, that managed different events like before and after saving, before loading and occupy player start.
The load and save ones would simply put the object back into the scene hierarchy so it would be saved with the scene. It would also prevent it from being carried into a new loaded savegame / scene that way. The latter (occupy player start) was used to teleport the following npc to the player. Afterwards it would continue following the player.
Now I don't use the custom action anymore. I did add 2 hacks however. Both call a function in the ManageNPCFollow where we simply set and unset a following character. With that, the manager script only listens to the OnOccupyPlayerStart and calls UpdatePresenceInScene and UpdatePosition. But as discussed, this solution is quiet buggy at the moment.
I'll be playing with this a bit more and hopefully find a better solution without too many hacks.