Bug Report - Possess Pawn has strange behaviour

Im experiencing issues with Possess, when trying to possess a pawn with a player controller.
I tried to replicate this issue in a fresh project, but had strange yet different results.

In the fresh project the player movement of the newly possessed pawn becomes very floaty, akward and strange.
Ive attached the sample project, its very basic, just a BP FPS template with a killzone and an actor ticking a respawn timer. Download: ue414project.rar

Let me know if this is expected behaviour, Ive never seen anything like it before.

Im still investigating the issue I am experiencing in my own project, it is different but still caused by the possess node.
When testing a session with a host, and 2 connected clients, client 2 will always get borked when possessing a new pawn if there is a 1sec delay node after the actor spawn, just before the possess node.
The player pawn looks like it is possessed from the clients view, but movement and jumping does not work. Other input can trigger events on the server from the pawn, but no rotations are replicated either. On the server and other clients no animations play on the borked pawn. Position of the pawn is not replicated to client 2, if the server moves or pushes the pawn, it does not move for client 2. (This is new behaviour in 4.14 since 4.13 and earlier builds)

Since I cant replicate this specific issue in the fresh project yet, Im going to investigate it further in my own project and see If I can figure out the cause. However the possess behaviour in the attached sample project acts really funky.

Thanks for any advice.

Hi MADHOUSE,

Thank you for the test project. The issue seems to be with the blueprint setup when the NewSpectator spawns in the player. You are getting the complete transform of the PlayerStart and passing that info in for the new player transfrom. If you look at your player start, it has an scale for the X-value of -0.25. This is getting passed into the new player and is causing the issue.

Instead of plugging the GetActorTransform in directly, break it and only use the Location. This seems to completely fix the issue.

I hope this helps. Have a good day.

TJ

Ah silly me, I just assumed the default player spawn had correct transforms.
I may have recreated the original issue I experienced in this build however:
[link text][1]

This is the case of client 2 getting desynced after possessing the new pawn, seeminly caused by adding a delay in front of the possess node thusly.

In my own project I used to have a 1sec delay before the pawn actually was possessed, deleting this delay fixed this issue however. The reason for having it in the first place was some other bug from an earlier engine version which made it required to delay the possession slightly to avoid problems in networked instances.

Thanks for your assistance!

What was the result/cause of this bug in sample project v2?
Note: Simulate 3 players when testing it

The workaround was to remove the delay on my end, but I cant see why it should be necessary as of 4.14

I tested the second project that you provided; with and without the delay I couldn’t see any ‘desyncing’ with 3 characters. If I’m missing a step please let me know. Feel free to post a step by step repro from opening that project.

Greetings. I just found a very specific step to take to replicate this.

  1. Open the project

  2. Open the blueprint editor for the respawner, and then the newspectator pawn

  3. Leave the blueprint editor window open in some corner of the screen without minimizing it.

  4. Simulate with 3 players

  5. As soon as it begins, run into the pawn killer with all 3 players so they will respawn simultaneously

  6. Bork

It does not seem to matter which order you run into the pawn killer, but the last client to run in will be the one which get stuck.

The affected client will be unable to move, and will no longer replicate its location. Key-press events from that client might however be executed on the server from that client.

To replicate this in the editor, step 3 is important… Don’t ask me why!
Thanks a lot for your assistance!
Best Regards

Okay, I see now.

I think due to the very specific nature of the issue, combined with that there are multiple workarounds, and it won’t effect your finished game; I’m not going to create a bug report for it at this time. With the holidays and upcoming events; our developers will likely not be able to allocate resource to investigate it. It will likely be kicked back as won’t fix.

If this does end up becoming a blocker later on, feel free to post back here to reopen the post and we can readdress it then.