So basically I want to make a kind of a VR simulator game in which there will be a player who acts as the server and all the others are clients. So for example, client is flying a jet, server decides to cause a malfunction and he can do so, and then the client can perform whatever has to be done to rectify the malfunction. What I need to know is that is it possible for the server to have a separate screen with a whole UI and a little viewport of the player and a myraid of options WHICH IS ALL CONTROLLED USING A KEYBOARD AND MOUSE, while the client side ONLY HAS A VR CONTROLLER AND ONLY WORKS IN VR. Long story short, I want to know if one player can have a completely different play experience, ie: a UI and a keyboard mouse for input and the other have a VR only play experience.
Also, I’m fairly experienced with Unreal but not so much in the multiplayer aspect and some heads up on multiplayer would be nice.
What does multi-player have anything to do with base engine functionality?
You are confusing yourself.
You can have as many controllers as you want (class, not necessarily physical controller).
They are also commonly used for AI, so you can definitely use multiple.
Usually the player has one controller.
Nothing prevents you from giving any player super-powers by swapping controller class at runtime.
It just depends on where you want to store the different setups and how hard you want it to be to be able to cheat.
Possessing a different character can be an immediate easy cheat.
Swapping controller is not necessarily as easy to achieve for a cheater
To change player controller at runtime you just tell whatever other controller to posses whatever pawn.
It’s done pretty commonly with AI and Player for instance.
I think the problem is in how to create and hook up that other controller. The new controller needs to take up the input for the player on the client side, and the new controller needs to own the player state on the server side. When using the “one playercontroller class” default approach, all this happens automatically. What’s the mechanism to do this switcharoo manually?
This is similar to how spectator controllers versus actual-playing controllers can be switched in sample games, so perhaps looking there would be helpful.
Actually, looking there, I can’t find a good example of changing the runtime class used for the PlayerController for a particular player other than as part of loading a new level. The examples I can find just spawn a spectator pawn, still controlled by the same PlayerController instance/class.
You’re right, after reading up more thoroughly on Controllers and what they do, I realized I didn’t need to change controller, only the pawn, the other pawn would simply use different input events and a widget. I’ve already implemented it. Forgot to update this.
Then nothing? The player controller simply adds movement input. or calls interfaces.
That’s true, to some extent.
Break out the “basics” and the individual behavior.
Putting movement in the player controller allows me to code 100 moving characters in 100 minutes (with pre-existing meshes). without having to waste the 20sec needed to copy and paste the movement nodes into it.
If your question is “why would you do that and not just create children” then the answer is “because it’s a stupid example :P”
literally just unposses, and order the AI controller to posses. or order AI to posses and the other controller gets discarded.
IF you wanted to break out the process and isolate it to just swapping class at runtime - you’d have to start looking into the possess c++, which does do it, and break it out into a new function.
At the same time there’s also a "SwapPlayerControllers " function in there (not in BP).
The game mode has this as an event.
SwapPlayerControllers
You can do crazy stuff From game mode when this event occurs. (no idea what, maybe destroy the old one manually?)
For my liking, that makes it way too simple to cheat. I would probably lock a UMG behind specific account access that only allows a specific controller and cannot swap to a regular player.
That’s not what I asked about. I asked about how to re-wire the controller-input to a new playercontroller instance on the client, and how to re-wire the new player-controller to own/be associated with the Player and PlayerState on the server.
SwapPlayerControllers() looks good, though – that’s in the direction of what I was asking about! It seems it makes it possible to do this, without having to literally re-join a new player …
I don’t like putting all input in pawns. Define what kinds of signals your game controller / mouse / keyboard send at an abstract level, decode them in the PlayerController, forward “movement/action input” to the currently possessed pawn, using some well-defined interface. This has the additional benefit that the AI controllers can use the same interface to drive the same pawns.
If you have a lot of variation in movement modes (glider vs truck vs running vs transportation tube) then your AI controller does need to know what to do with each of them, if you want the pawn to use them, but generally, that’s necessary no matter what. Input subsystem translates from physical input to input events; player controller translates from input events to player desire; player pawn translates from player desire to actions/animations/movement.
