I’ve been messing about with Networking in Blueprint and I can’t seem to get a Sliding Door working how I want, I followed along with the Creating a Level - Blueprint Doorway tutorials on YouTube and the door works fine, next up I was watching Blueprint Networking - Part III: Function Replication which shows a button being pressed and the event gets replicated with a Multicast.
I setup a Multicast on my Door and when the server opens it the client sees it, but if the client interacts with the door the server is not seeing it, I notice in the Networking Tutorial the Client is never shown pushing the button, how would I go about replicating what the client does to the server? The door needs to be in sync for all players regardless of who opens it.
This is just one example, I’ve tried setting up some various other features and I always seem to run into a similar problem where the Client is not sending any Data back to the server.
Multicast may or may not work. The blueprint networking tutorials have a very detail explanation on how multicast works and when/how to use it. Also, Switch Has Authority is your friend.
The difference with your example and the one with the button in the networking tutorial is where the input is originating from. In the tutorial button example, whether the client or the server character presses the button, the server itself is getting a notification of an overlap with a trigger in that map and then calling a multicast function (multicast need to be called from the server).
In your example, I assume you’re opening the door with the player performing some local input, like pressing a keyboard key. In that case, you actually need the client to tell the server that he pressed the key and attempted to interact with the door, which usually entails using a different replicated function type: server. Part V of the tutorial series has an example of usage for spawning bombs when the user right-clicks his mouse, around 23-25 minutes in or so. Caveat of using the server type replicated functions is that they only work in actors that are owned by player controllers or are a player controller themselves (i.e. it won’t work if fired by your door, but would work in a character blueprint).
In Fortnite, our doors follow roughly this kind of networking flow:
Client presses interaction button
Client checks if it thinks it is allowed to interact with the door
If so, client uses a server function to tell the server that it would like to attempt to perform an interaction
Server receives request from client
Server verifies client is allowed to interact with the door
If allowed, server performs whatever is necessary to open the door and replicate it to other users
In your case, the server function could then presumably turn around and multicast out playing your timeline like you’re trying to do already, which should work. Depending on how your door is supposed to behave and how your game is set up, this kind of strategy does leave it possibly afflicted by relevancy issues (part IV of the tutorial). If your door takes a long time to open, or stays open for a while, etc., you may need to also handle some replicated variables that preserve whether it is open or closed to handle clients joining late or missing the multicast. If the door opens/closes quickly and a client potentially being out of range and missing the multicast isn’t a big deal, then that’s probably fine.
Looks like I’m getting stuck at the whole replicated functions can only be fired by a client if they are a player controller, since I had tried to setup the door the same way the Bombs work in the Networking Tutorials, I setup the default “Gun” that comes with the FPS Blueprint Game to work over the Network but the Door did not prove to work the same way, Since the Blueprint posted I do have some variables attached to the door like weather its open or closed.
Seems I need to wrap my head around how to go about doing something similar to how Fortnite is working.
The Fortnite ones are mostly in C++, but the concept should be similar in blueprints. The way we get around having all kinds of object-specific stuff (like doors) in our character or player controller is through the use of interfaces, which blueprints have as well. I’ve not personally fiddled around with the blueprint interfaces yet, but the documentation is here: Blueprint Interface | Unreal Engine Documentation
What we basically do is have an interface that all interactable actors (again, like doors) implement, with functions that check if an interaction is possible and handle what the interaction should do. So maybe something like CanInteract and DoInteract (I’m not at the office atm, so I totally don’t remember what we actually call them). That way the individual actors still implement all their specific logic, like what should happen when the door is interacted with, and the player doesn’t need to know anything about it. All the player code does is have a simple server function with a parameter of any interactable actor that the client can call, which verifies it can interact and then tells the actor it’s been interacted with.
