[BUG] NormalDoor does not replicate movement in multiplayer.
randopixel opened this issue · comments
Bug Description
NormalDoor Movement cannot be replicated.
Technical informations
- OS: Windows 11
- Unreal: 5.1
- Plugin Version: 2.1.0
I have a project using your dungeon generator and I have multiplayer working except for the doors. The door actuates on the server, but the client does not see it. The client can open it, and because it is open on the server, it can walk through, but not see it open.
I have created other doors in the project that work multiplayer, but I cannot reassign the door class in the generator to a door of my making and applying the same logic that makes other doors work in multiplayer does not work on the trigger doors. Can you tell me what modifications I can make to the source code to allow me to choose my own door class? Or help me understand why the NormalDoor movement doesn't seem to replicate?
Thanks much.
Hi @randopixel,
I don't know why you've closed your issue. But if you have found a solution, can you share it here in case someone else run in the same issue
Also, you should be able to put any of your door actor classes as long as they derive from the ADoor class.
The NormalDoor blueprint in my examples is deriving from the C++ class ATriggerDoor which derive itself from ADoor.
Moreover, I have some questions about your multiplayer issue: What does not work/is not replicated from your door logic from server to clients?
If you use a trigger to open your doors, then the trigger should trigger on both server and clients independently because the overlaps are checked on each of them locally (no network replication required).
However, if a player needs to do an action (eg. use a button to open a door) then you need to do more work. As said in the wiki, the actors loaded by room levels and doors are not replicated over network. I need to fix that for doors only so they are replicated and this should fix your issue (thank you to report this bug).
Until then, you can have a workaround where you make a door actor which is not the door itself, but actually spawns the actor on server at begin play which send a spawn command on each client resulting in replicated doors over network.
Though, I'll work on that fix soon for the next patch release.
Best.
I thought I had figured it out, but I have not.
What you describe is specifically my issue. I need the players to be able to use a key and interact with the doors and apparently the doors are not replicated.
I'm glad it's known, as this has been a very frustrating exercise in futility.
On your workaround, could you explain better? How would I spawn the doors where they need to go in between the rooms? Is there a class that I can get all actors of and get the location?
Thanks for your time.
I attempted to create a child blueprint of Door and leave it empty except for on begin play spawn a door that I actually want in it's place. It does this, except the doors are not visible.
If I check "always visible" on the doors that are to spawn, it makes them visible, except for a weird issue where it apparently double spawns for the client so there's 2 doors, one that works and one that doesn't, One that collides and one that doesn't. It doesn't matter if I use a server replicated event, or a combination of authority switch and server replicated event, no setup I've tried lets the door work properly for the client.
Hi @randopixel,
First, I think after some reflection that it will be very difficult to make a workaround in blueprint only...
How would I spawn the doors where they need to go in between the rooms?
You spawn like any other replicated actors you want to spawn. I think you make it work with what you say later.
Is there a class that I can get all actors of and get the location?
I don't understand this question... Why you would want to do that?
except for a weird issue where it apparently double spawns for the client so there's 2 doors, one that works and one that doesn't
Yes because the server's spawner spawns a door and replicate this spawn over the network to spawn the door in all clients. But the client's spawner spawns also a door but this one is not replicated.
Currently, what I would suggest to you is to wait for me doing a fix in the plugin code. I'll do it in a separate branch and if you want I'll come back to you for testing before I release a new version of the plugin.
Best.
Very good. I will wait for a testing branch and work on other things in the mean time.
Thank you for your efforts. Because of people like you, my game has come a very long way.
Hi @randopixel,
I have pushed some modifications on the dev branch, to make doors replicating over the network.
Can you try with the latest changes of the dev branch please?
Also, to do correctly players interaction with the doors in multiplayer, you should read this important document page 71, if you haven't already. I always come back to it when I need to do multiplayer game in Unreal. It is using UE4 but it is the same in UE5.
If you want, I could share with you my blueprint setup to make it right.
Best.
Thank you! I will test immediately. Your blueprint setup would be amazing. I know little to nothing about the multiplayer setup so something from someone with more knowledge is always helpful. Also, thank you for the information. I will report back with results unless I see you post your blueprint setup first.
Edit: It works out of the box! I am already doing the RPC call from a component on my controller, so as soon as the door was replicated, the blueprint door I made from the Door base class worked for multiplayer flawlessly.
If you want me to give it some time to see if anything pops up, I can report back so you don't push the update to the main branch prematurely.
Your blueprint setup would be amazing.
Okay, I will explain what I've done. 🙂
Door setup
First, I've created a blueprint interface called IInteractable (the first I is just a naming convention for interfaces).
I put 2 functions inside:
CanInteractwhich takes as param what you want (I've put anActornamedCallerso we can decide if a certain actor can interact with the interactable) and returns a boolean (truecan interact andfalsecan't).Interactwhich is the function called to do the interaction (in my case it takes also theCalleras input if needed)
This interface will be useful for any interaction the player will need to do in the game. It will be used for doors, of course, but also for chests, loots, levers, buttons, etc.
Then, in my InteractableDoor blueprint actor, which inherits from ADoor and implement the new interface IInteractable, I override the CanInteract (always returns true in my example) and Interact functions from the interface and do the logic I want (just a toggle between open/close for example).
All I've done until now is not specific for multiplayer, however it is a good practice for any game.
Character Setup (multiplayer part)
Then, my Character actor will do the multiplayer logic. I've put the interaction input on E key press, which sends an RPC to the server (see the doc in my previous comment page 61 for more info on RPC).
The server then handles the logic: I get any interactable in front of the player character and then if any I call the Interact function from the interface.
The GetInteractable function is a function I created for my example.
You can do what you want in your GetInteractable function, here is my implementation:
If you want me to give it some time to see if anything pops up, I can report back so you don't push the update to the main branch prematurely.
Yes, I would love to get feedback on it since it, is something I can't test thoroughly. 😄
Thank you for your feedbacks on the issues you find, it makes my plugin better!
Thank you!
The blueprint I have works, but this will give me obviously cleaner implementation.
I have been working with it for a few days now, probably 8 hours a day, and the changes have behaved well, no artifacts or strange behavior/ bugs. I consider this fixed!
Awesome plugin! Without you my game would just be a dream. Because of you, I can make it happen.
Cheers.