This is driving me mad. I’m trying to have a character walk up to a vehicle and possess it via overlaps using a custom ‘Interaction zone’ child actor attached to the vehicle. But no matter what I try, the server-instance of the client’s controller will possess the vehicle while the client-instance is seemingly does nothing, therfore disregarding any of the client’s inputs.
Here’s a review of the logic:
Character sends interaction request (on the server)
Vehicle runs the possession (still on server), with the In Pawn as Self and gets the controller from the (server-instance) pawn that caused the interaction
I know ‘Get Player Controller (0)’ isn’t really meant for multiplayer but I figured it would fine if it’s only ever running clients.
I should also add that the listen-server can do this perfectly fine, and trying to possess the vehicle as a client completely disables input on the listen-server player.
What happens in Update Current Vehicle Reference ? Why is it in GameState ? Sounds like it should belong to PlayerState instead.
Aside from that, I’m thinking that maybe event Possessed is too early to call an RPC for the new owning client, and as such it triggers the RPC on the local machine (listen host) instead of the client. Can you try either adding a 1-frame delay, or use a Multicast RPC and pass the new pilot as parameter, and check pilot->IsLocallyControlled before remapping inputs ?
I must be cooked because it turns out if I print the pawn’s controller at any time after possession with a keyboard key, it does indeed show the correct client-instance controller, however printing the exact same thing after an RPC to the client shows nothing. I also tried using delays and a Multicast but they seemed to do nothing.
Also the GameState contains a struct array with server-instance references of all the characters, what vehicles they have, their current controller etc. It’s mainly so if you try and possess a character that is in a vehicle it will check that and possess the vehicle instead. It’s also used to prevent you from possessing another player’s character.
I actually found a solution the other day, not sure why the client RPC wouldn’t print a controller reference, but in the end it seemed to be an Input problem. I kept my ‘Input Context Manager’ component logic, but replaced the functions with Events that call a Multicast RPC. I also took the ‘Add / Remove Mapping Context’ nodes out of the component and called them via Interface to execute in the Player Controller directly, and this seemed to solve all problems.
