How would I go about Networking Doors

[Irascible]

@DarkSynopsis;26942

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.

I’ve attached my current Door Blueprint.

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.