Is LobbyBeaconState replicated
I'm trying to use the Lobby system recently added in the version and I'm asking a question : Is LobbyBeaconState and LobbyBeaconPlayerState replicated when on a client when connected to a lobby ?
I succeeded to connect to a lobby created in another instance of my game (on the same computer). But it seems that i don't have any LobbyBeaconState neither LobbyBeaconPlayerState in my actor list in the world of my client. And the references to PlayerState and LobbyState are null in my LobbyBeaconClient client side.
I thought they must be replicated because they have the Replicated property.
The LobbyBeaconClient seems to work through replication so maybe the system is intended to only go through this actor ?
Thanks for any clarification and nice work for this system !
I was able to fix the replication of player and lobby state in my project by reordering some of the setup functions on the host.
Make sure you are calling them in the following order:
If you are calling SetupLobbyState prior to RegisterHost, the lobby state will be unable to set up replication because it can't find the net driver name. This then chains every time a playerstate is created, grabbing the same empty net driver name.
answered Sep 30 '16 at 10:57 PM
I just noticed this question, I'm sorry it wasn't brought to my attention sooner. The short answer is yes the lobby should replicate that data when you connect using this feature.
ALobbyBeaconHost is setup on the server, it is registered with the AOnlineBeaconHost class that is the main network listener for all beacons
ALobbyBeaconHost (similar to AGameMode as an analogy but not really same in function) will have a ALobbyBeaconState (similar to AGameState)
The client creates a ALobbyBeaconClient instance and connects to the server. The server will establish the connection and notify the user that they are connected.
The client will then call LoginLocalPlayers(), which should establish the necessary user id handshaking to properly create an entry on the server for the client players. At this point the server should make an ALobbyBeaconPlayerState for the client passing it and the ALobbyBeaconState to the client via replication.
Maybe the login step was missed? Maybe there was some error (possibly mine) that is preventing this from happening.
Can you put some breakpoints in your server and client code and see how far this handshaking is getting?
Additionally, these two more obscure functions may have a reason why they aren't replicating the data (assuming login was called). These are used on the server to determine whether or not the server should replicate data to the client.
I wrote this up a little while ago hoping to help people out about beacons, which might be informative as well.
The GUID question should be answered by the flow comment/diagram at the bottom of DataChannel.h. There is a handshaking that occurs that tells the server to make its own actor to duplicate the one the client has and to create a GUID that it shares with the client to connect the two actors to each other. The fact that you call RPCs and the client responds on the same pointer should prove that is working properly. There should be no dead actors as you describe.
I had a longer explanation for the following, but I lost it in this silly webform, hopefully this succint answer is just as clear.
Make sure that these variables are set on the beacon state actors, they should be in the base class, but just in case.
The server will call the following, you should only need one client connected during this (use -notimeouts so you can debug it easier)
For each client connection (stick with just one for now)
I'm ready to help further, but you'll have to debug this some for me so I can see what is going wrong. This code is well exercised in Fortnite.
Follow this question
Once you sign in you will be able to subscribe for any updates here