Announcement

Collapse
No announcement yet.

Multiplayer Replication is a nightmare to learn, could use some help

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Multiplayer Replication is a nightmare to learn, could use some help

    Currently I am in the process of putting together a multiplayer combat (Host/Listen) third-person shooter, the only painful part I seem to be blocked on is Multiplayer Replication. So at the main menu there is a character options screen where a player can change hair, skin, clothing, shoes, etc. then the player can go back to the main menu->click play->and load into a start area, where they see their character with a menu that has maps and game modes. After selecting the map and mode the host clicks on Host, or the someone can click on Locate to find a hosted game. So after all that they load into a lobby with a list showing who is connected and they can see their own player character. Timer hits 0 then everyone servertravels to the map. So the character options menu has a save file, from that save file is where I'm grabbing all the options (clothing, hair, shoes, etc). Unfortunately I've seen a lot of weird combinations, but never the outcome I need, players see what they are wearing and can see what the other players are wearing in the game map. Any help would be appreciated, I just wish there was an easier way to see what get replicated and how during development. Please excuse the mess of the blueprints, I'll clean them up after I get through my Million and 1 changes. I think my main problem is with knowing what variables to set to replicate and when to set something as run on server or just have it run locally.
    Thank you for any assistance, please end my suffering

    #2
    Try this.

    Technically you should re-write the whole blueprint, but don't do that until you actually thoroughly understand what you're doing, where and why.

    I've just moved a few things using photoshop, unfortunately don't have time to duplicate it and make you a tidy version

    Follow the attached images (download them and open them if they're too small to read in browser).

    Also go and watch this thoroughly, if you don't understand something, watch it again and again. Most of what you need to know is in this video series in one form or another.

    Also read this.
    Attached Files
    Last edited by GrumpyNZ; 11-04-2018, 05:43 AM.

    Comment


      #3
      GrumpyNZ Thank you so much for the links and your response, I wired everything together based on the pics. When I run the game both players are wearing what the Host selected on the Host and the Client. I'll read up on what you posted and go through the video tutorials in the morning.

      Comment


        #4
        Ok, I see what the problem is, but at this point you'll need to understand why the change is necessary anyway so there's not much point in me correcting it.
        I've made a small project for you to dive into which attempts to demonstrate the functionality (I think) you're looking for. Take a look at the project, i've commented some stuff, and hopefully it will help you get a better understanding of how the whole process fits together. Any questions you have after that, just let me know.

        Link to dropbox.
        Attached Files
        Last edited by GrumpyNZ; 11-05-2018, 07:17 AM.

        Comment


          #5

          GrumpyNZ
          OK, so I read through the link and watched the tutorials, I think some of the mistakes I were making was::
          Not getting and using the controlled pawn of the player
          Using the character blueprint for most of the code I was wanting to use when I should have been using Instance, PlayerContorller, PlayerState
          Not knowing the difference between Multicast and Run on server

          Then I went through your blueprint and re-did a lot of what I was doing, I'm still getting the save file in the game instance. Now I'm putting everything from the save file in a struct and mirrored most of what you did in the example. minus the buttons. I'm almost there, On the host, replication is working correctly for the listening host and the clients, but on the client the Host and other client has nothing on (I haven't set any defaults yet) but the client is clothed and can see what the client is wearing.
          I understand how the Host is getting seeing everything, but it's like the clients don't have permission

          Comment


            #6
            GrumpyNZ
            Small update, In the PlayerState I set the Event that sets everything then calls the rep-notify event to MultiCast. Now, The clients are able to see what the other clients are wearing, replication is working on the host, but the clients cannot see what the host is wearing :P...I'm sooo close
            Also, is using multicast for this ideal, is there a better way to do it?

            Comment


              #7
              Hi Straggiz, nice to see you making such fast progress.
              Multicast and Repnotify are very similar but have one key difference, a multicast event will only fire the moment it is called and only on clients that are Net Relevant (net relevance is explained in detail in that tutorial series). The Repnotify variable is used to ensure anyone joining later, or coming from a part of a map where they were not net relevant at the time of the change can receive the update too. (I left the multicast out for you to discover, that's why there's a small delay in the project when you press submit and the changes occur (because Repnotify variables don't necessarily arrive immediately, where a Reliable Multicast will) nice work).

              Now when you say it's like the clients don't have permission, that's true. Clients do not have authority over their character copies (which exist on the server and each client), only the server does.
              Clients have authority only over their own instance/copy of their character and they can only request the server make changes to the server copy and client copies using a Run On Server event, the server sends out information the other clients about the change by replicated variable, repnotify, or multicast.

              The ideal way for you to do this will be to use a mix of repnotify (for players that may join a game in progress) and a multicast event. Rewatch that series again and again until you understand, there's way more info packed in there than is first apparent. Also it's worthwhile to follow along on the tutorial example project in the last 3 videos of the series as it goes over why we mix Repnotify, Replicated Variable and Multicast events and where it's appropriate etc.

              Keep it up, learning this stuff took me many many weeks of smashing my head against the screen trying to get the information in there.. There is light at the end of the tunnel, but the tunnel is long and nobody can go the whole way with you .

              Also, there is very detailed information in the documentation, which I also suggest reading and rereading as your understanding of replication deepens you will find information in the documentation that you didn't notice when reading it the time before.

              Also, one golden rule (because it took me so long to figure it out, was a facepalm moment to be sure). - Don't multicast from a PlayerController (I believe I explained the reason in the project BP's)

              After you've got that understood correctly, take a good look into ownership and how that affects how a client can call Run On Server events (hint, any class must be owned by a client otherwise the Run On Server (RPC/Remote Procedure Call) will be rejected.
              Last edited by GrumpyNZ; 11-06-2018, 05:46 AM.

              Comment


                #8
                Originally posted by Straggiz View Post
                GrumpyNZ
                Using the character blueprint for most of the code I was wanting to use when I should have been using Instance, PlayerContorller, PlayerState
                The Character blueprint is actually also an ideal place to do this, I just wanted to first get you to learn why you would use the others also, like with everything, there are many ways to reach the desired outcome.

                As for why the Character blueprint is also a good place, we'll call that homework :P

                Also, if after everything you're still seeing the wrong results, consider how each client is saving its file, and how it's retrieving it. Is it possible you're loading the same copy on multiple clients. etc.

                Cheers.
                Last edited by GrumpyNZ; 11-06-2018, 05:45 AM.

                Comment


                  #9
                  GrumpyNZ
                  Thank you SO MUCH for all of your help!
                  I'm still going back through the materials (work in RL as a QA, all the devs drop their projects on me the last day of the sprint), and it looks like my main problem maybe how the clients and host are loading their save files, and maybe network relevancy... but I was also wondering if I need to put the event that pulls the information from the save file in a rep-notify event as well...
                  I won't be able to dig back into the materials until WAY later today..
                  Last edited by Straggiz; 11-07-2018, 12:48 PM.

                  Comment


                    #10
                    You shouldn't have to load the information from the save file more than once (that was the reason for putting the loaded vars in a replicated struct, so they're stored for the life of the game and can be changed on the fly as needed).

                    A potential problem could be, assuming that you're running your tests in PIE is that it could be sharing the save files. Or depending on how you're writing the files the host could be overwriting something?

                    Have you implemented a way for each client to tell the server which save file belongs to them? i.e. playername or something associated with the save file?
                    Last edited by GrumpyNZ; 11-08-2018, 08:11 AM.

                    Comment


                      #11
                      Thank you for this thread... i`m corious following

                      Comment


                        #12
                        GrumpyNZ I copy the entire work directory to another folder an running a 2nd client from there, it may be the noob way to do it, but it was the only way I knew how to make sure there was a separate save file each player. So what you said about the save file, just answered a question in my head..for awhile I was concerned about how I was handling the save info...
                        It looks like I'm just stuck with getting the clients to replicate each other and ListeningHost/Server to replicate to the client, I have replication working fine on the host, so i just need to dig back into the video
                        MilliElektra I'll post images of my final resolution once I'm done, if you'd like to see it, but I've been at this for awhile, so it may take me a few.
                        Last edited by Straggiz; 11-08-2018, 11:20 PM.

                        Comment


                          #13
                          GrumpyNZ
                          I did it!
                          But I'm wondering if I'm doing it right.
                          So in order:
                          Pic1 I'm in the widget blueprint for my stats, I have a function that loads everything from the save file into the struct then runs the event that's in the PlayerController
                          Pic2 In the PlayerController I'm running an event on the server. I'm getting the player state and the main character blueprint and sending it to the next event that in the PlayerState blueprint
                          Pic3 I'm in the PlayerState, I'm setting the MainCharacterBlueprint Reference, the Clothing Options from the struct, the Set Notify bool (With the everything that applies the clothing to the character), and then I'm running everything again, but I'm switching the Auth to remote
                          Attached Files

                          Comment

                          Working...
                          X