Announcement

Collapse
No announcement yet.

More Replication options

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

    [FEATURE REQUEST] More Replication options

    We need more than just Server -> All; Server -> Owning Client and Owning Client ->Server.
    I would like to be able to do Client -> All, Client -> Server and Client -> Owning Client for my game, and I can't because of these limitations.
    I know this can induce some cheat, but if it's reverified by the server afterwards, I don't think so.

    #2
    Clients can't talk to each other directly, that would require P2P networking which Unreal doesn't support in any form (and it's never going to).

    As a Client, you can still ask the Server to do things to other Clients if you want to - but you have to use the PlayerState as a reference for that client.

    Comment


      #3
      Originally posted by TheJamsh View Post
      Clients can't talk to each other directly, that would require P2P networking which Unreal doesn't support in any form (and it's never going to).

      As a Client, you can still ask the Server to do things to other Clients if you want to - but you have to use the PlayerState as a reference for that client.
      Client-to-client connections could work by being routed by the server : Client ->All = Client -> Server -> All; Client -> Owning Client = Client -> Server -> Owning Client.
      What I want to do is to be able to access and send data to all client from any client on one blueprint.
      Because right now the only ones who can send data are the Owning Client and the Server.

      Comment


        #4
        You can solve some of your needs with RPCs and OnRep_ functions; Client to Server then Server to All.
        But Client to client would be a mess, I think you'd have to make your own Socket stuff...
        | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

        Comment


          #5
          Originally posted by BrUnO XaVIeR View Post
          You can solve some of your needs with RPCs and OnRep_ functions; Client to Server then Server to All.
          But Client to client would be a mess, I think you'd have to make your own Socket stuff...
          Client to server requires to be the owner of the object for whatever reason.

          Comment


            #6
            The reason is Epic made this network layer for shooter multiplayer games xD
            | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

            Comment


              #7
              Originally posted by BrUnO XaVIeR View Post
              The reason is Epic made this network layer for shooter multiplayer games xD
              Then I hope they can step it up.

              Comment


                #8
                Unreal is Server-Authoritative not just because of it's shooter game heritage but also because it's the safest way to do online networking. P2P sucks for games anyway, it's not really done anymore.

                You can do this now by routing an RPC to the Server, then telling it which client to send said RPC too (by passing a PlayerState for that client so the Server knows where to send it) - but you will still have to call that Server RPC in the local players Player Controller, Player State or Pawn.

                Clients don't know about other Clients, at all. As far as a Client is concerned, the only other 'player' is the Server. The Objects that represent other Clients are just empty shells as far as it's concerned. Basicaly like a Car with noone behind the wheel.

                Comment


                  #9
                  Originally posted by TheJamsh View Post
                  Unreal is Server-Authoritative not just because of it's shooter game heritage but also because it's the safest way to do online networking. P2P sucks for games anyway, it's not really done anymore.

                  You can do this now by routing an RPC to the Server, then telling it which client to send said RPC too (by passing a PlayerState for that client so the Server knows where to send it) - but you will still have to call that Server RPC in the local players Player Controller, Player State or Pawn.

                  Clients don't know about other Clients, at all. As far as a Client is concerned, the only other 'player' is the Server. The Objects that represent other Clients are just empty shells as far as it's concerned. Basicaly like a Car with noone behind the wheel.
                  The problem is that with that system, I have to forward everything through the player in order to contact the server for it to update the common actor that everyone wants to access. It could be simplified by allowing anyone to contact directly the server, regardless of if it's the owner or not.

                  Here's a little graph of what I mean.
                  Click image for larger version

Name:	Screenshot (39).png
Views:	1
Size:	103.7 KB
ID:	1126123

                  Comment


                    #10
                    Yeah but that's the problem - if the Client can call RPC's on objects it doesn't "own", that opens up the possibility of cheating all too easily. They could start calling RPC's on other players pawns for example, asking them to drop all their weapons or suchlike (just an example). The Golden Rule is that if you have an online game, someone will try to hack it - no matter how unpopular or popular it may be. Look at the issues faced by The Division when it launched, a very promising AAA title ultimately ruined by client-authoritative networking and silly choices.

                    If Epic ever were to implement something like this (spoiler alert: they probably won't), their system would more than likely follow the path of least resistance, which means still routing an RPC via the Server and needing some kind of replicated reference to the object.

                    IMO, network programming in UE4 is easier in C++ than Blueprint. BP tends to get way too messy for things like this.

                    Comment


                      #11
                      Originally posted by TheJamsh View Post
                      Yeah but that's the problem - if the Client can call RPC's on objects it doesn't "own", that opens up the possibility of cheating all too easily. They could start calling RPC's on other players pawns for example, asking them to drop all their weapons or suchlike (just an example). The Golden Rule is that if you have an online game, someone will try to hack it - no matter how unpopular or popular it may be. Look at the issues faced by The Division when it launched, a very promising AAA title ultimately ruined by client-authoritative networking and silly choices.

                      If Epic ever were to implement something like this (spoiler alert: they probably won't), their system would more than likely follow the path of least resistance, which means still routing an RPC via the Server and needing some kind of replicated reference to the object.

                      IMO, network programming in UE4 is easier in C++ than Blueprint. BP tends to get way too messy for things like this.
                      Then again, it could depend on which type of replication you choose. A Client to Server could be as secure as an Owner to Server.
                      Also, on the case of The Division, there was no server checks to allow them to use less resources. Unreal has checks, and runs the same code on server.

                      One solution could be to make it so that multiple players can own a same actor. That could be nice.

                      Comment


                        #12
                        Honestly, I think an engine should have features that cater for 90% of users requirement, but not 100%. The remaining 10% should be done by the users themselves, because replication as what it is is good enough for most people.

                        Comment


                          #13
                          Originally posted by Syed View Post
                          Honestly, I think an engine should have features that cater for 90% of users requirement, but not 100%. The remaining 10% should be done by the users themselves, because replication as what it is is good enough for most people.
                          Yeah, but if it's as simple as removing a restriction for one kind of replication, I don't see why we would have to go through so much hassles.

                          Comment


                            #14
                            Originally posted by Moddingear View Post
                            We need more than just Server -> All; Server -> Owning Client and Owning Client ->Server.
                            I would like to be able to do Client -> All, Client -> Server and Client -> Owning Client for my game, and I can't because of these limitations.
                            I know this can induce some cheat, but if it's reverified by the server afterwards, I don't think so.

                            I totally want this feature as well. Even though whatever [MENTION=155]TheJamsh[/MENTION] said, but he does not realise that not everyone's game care about security. Not everyone has the budget to pay for dedicated server or whatever hosting needs. There are several AAA title games still using P2P these days, like Destiny 2, Dark Soul 3, For Honor and so forth.
                            Epic, please.

                            Comment


                              #15
                              You can still make and sell online games in Unreal without paying for Dedicated Servers.

                              Unless the fundamental networking layer of the engine changes (which it likely won't), clients will never be able to talk to other clients without going via the server. If you want real Peer-To-Peer networking, you'll have to write it yourself or find some other API (there are a lot out there).
                              Last edited by TheJamsh; 05-23-2017, 12:07 PM.

                              Comment

                              Working...
                              X