Just like the question, Multicasting caused the client to be fake ejected from its possession (player controller returned to its starting spawn position), and its pawn would still exist, and if destroyed, the game crashed. It was called in the same Exec path (through a custom event) after the Server spawned and possessed a new pawn.
I got around it by changing the event to be Owning Client.
Thanks for the report! Can you post some images of your BP setup for the relevant events so I can try to reproduce it here? I believe this is related to a known crash, but I’d like to be certain.
Please also copy the information from the Crash Reporter window after this crash occurs, including the Machine ID, and paste it here. Your log from the project’s Saved\Logs folder would also be useful. Thanks!
Hm, I still can’t reproduce this. In your image, the Custom Event isn’t Reliable… does it not crash if it’s not set to Reliable?
Can you reproduce this in a new project, or does it only happen in your current project? If you can make a small test project and upload it somewhere, I can take a look at it. Otherwise I’ll keep looking into it here and see what I can figure out.
I thought I reported this already. I guess I didn’t.
This is totally true and super annoying, although its true you shouldn’t be using multicast in player controllers anyway.
The cause of this is because only the local Player Controller exists on clients, the networking layer is somehow interpreting the multicast call as I believe a pc/playerstate swap, which is normally done when you log into a server and the server wants to swap your local player controller with one it’ll provide for you (or something to that effect). Because the payload data is fubar, best case you’ll unpossess and be in a bad state. Average case is a hard crash with debug info that makes no sense.
“I got around it by changing the event to be Owning Client.”
This is infact the correct and only solution. Clients only are aware of their own PlayerController and don’t have PlayerController objects for other players. Running a Multicast on a PlayerController causes bad things to happen because you’re telling all clients to run a function on something that technically doesn’t exist. Only the Server is aware of all PlayerControllers.
Run on Owning Client will ensure clients don’t recieve function calls for PlayerControllers that don’t exist locally.
If you need a multicast, do it in Character or PlayerState or really any other object that will exist for everyone on everyone’s client.
Really glad to bump into your post as I was just having this problem in 4.10.1.
The only reason I’m calling multicast in playercharacter is because I need both the Server and Client to be able to move an object with mouse drag (despite Client not owning the object). Does this mean I can (and should?) move all these logic into PlayerState and it would work?
Edit: Okay it does work better =p I’m just not sure if it’s the right place to do so.
My client’s Player Controller got destroyed and recreated (On destroyed and On Begin Play Events both fired) whenever a multicast reached that Player Controller. (from a Client to a run on Server event to a multicast event - all on a player controller class).
This is super annoying and should be explained better. Or at least give a proper error message. Instead it simply destroys and creates a new Player Controller, which doesn’t make sense and breaks the whole functionality along the way.
I don’t use any pawns because it’s only a lobby level with UI only. Instead of creating pawns just to use multicast events, I chose to iterate over all player controller (on server → get all actor of type xyzPlayerController) and for each of them, I called a run on owning Client.
Still… It would be nice to see a error message or anything. Or maybe disallow multicast Events from Player Controller completely?
How can I check whether this Bug/Problem already got reported?
Again. Thanks for your comment. Would have annoyed me for a quite a few hours if it wasn’t for your comment.