Announcement

Collapse
No announcement yet.

Accuracy of hit registration

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

    Accuracy of hit registration

    Hello,
    I am a regular and somewhat competitive player from CS:GO, and right now that game is suffering from hitreg issues. So I wonder does UT4/UE4 have this kind of problem? Since I am not that familiar with UE4 networking code yet, some pointers would be appreciated.

    #2
    To sum up the current state, you have one hitbox that is a capsule shape and there is no latency compensation. So hitreg issues are lag. Valve does a good job with this, I'm not sure what issues you're talking about. Keep in mind you can only predict so much.

    This is something I'll be looking into in a few days for a little side project. Latency compensation for a capsule should be somewhat simple to implement for hitscan. Let the client play its own firing effect and it will look tight.

    Projectiles are a different matter. What I would want is to just take away that lag feeling. First thing that comes to mind... Spawn the projectile on the client immediately, then when the server projectile is replicated, hide it and lerp the client proj to match the server one.

    I'm not sure how this will look and feel. I will post my findings here when I start tinkering with it.

    Comment


      #3
      Valve does indeed do it very well, but sometimes the hits just fail to register. It even happens when the target and shooter are standing still. You can go over the CSGO subreddit to find complains about it. Note that CSGO servers use high simulation rate, 64 times per second (tick) for normal server and 128 ticks for higher end servers, and it appears to happen more when the server is struggling to catch up with that simulation rate.

      Comment


        #4
        Yeah if the server can't keep up than things will break down. Granted I don't understand how 2 people standing still would fail to hit each other. Unless somehow the spread RNG gets out of sync somehow and the client/server bullet directions are different.

        Incase anyone is interested here's some links to read how valave tries to solve the problem
        https://developer.valvesoftware.com/...d_Optimization
        https://developer.valvesoftware.com/...yer_Networking

        Comment


          #5



          red wireframes represents a hit that is suppose to be registered from client's perspective. I'm not sure what is going on either, but this causes a very bad experience for players.

          Comment


            #6
            Strange. Unfortunately there's a myriad of things that could cause this.

            Comment


              #7
              Originally posted by Ethan Trinh View Post
              red wireframes represents a hit that is suppose to be registered from client's perspective. I'm not sure what is going on either, but this causes a very bad experience for players.
              Bad ping could be the case for them. That will always be a problem unless all IP service providers go to pings of 1ms worldwide.

              One thing UT never should do is the client-hosted (very non dedicated) servers like in CoD MW3. Maybe for duels, but I bet all the high-tier players would be very upset when that would be the case. The biggest problem with these CoD lobbies is the awful experience of being able to totally obliterate the opponents one game and the next game you are always one step behind because of lag.

              Comment


                #8
                It could be many things, and of course bad ping. However, as this video (about 148 seconds) http://www.twitch.tv/micronn/c/3228621, linked to in http://www.reddit.com/r/GlobalOffens...8_tick_server/ demonstrates, (local game, 1 bot, simple map, no weapon recoil/spread) there really is a good reason that cs:go has become notorious for its hit detection issues. Sorry to bump thread for it, but I just think it is too important issue to just say "it probably works fine and can be explained away by external factors" and then possibly look at the game as an example of good implementation of hit detection.

                Comment


                  #9
                  So I gave this a try today. It actually turned out quite well. Moved the hit-scan effects client side and tried the projectile smoothing I was talking about above.

                  These can be turned on/off in the console.

                  The following video is the extreme case of 300ms lag. It works alright. Lower ping feels real nice.


                  There's still a few more techniques to try out (and handling a lot of little edge cases). But so far this is looking promising.

                  Comment


                    #10
                    Pretty neat TimEh. Keep up the good work! It'll be nice if it works extremely well in most cases but experimenting will all possible solutions is smart. Cheers I'll be watching how this progresses.
                    irc.globalgamers.net | #2k4ctf |#ut4pugs | #unrealtournament | Ownedwell.com | UT2004 Grail

                    Comment


                      #11
                      That looks awesome TimEh. Good job!
                      Do you have it on Github for testing / is it ready for testing yet?

                      Comment


                        #12
                        Its not quite ready. I haven't hook up any weapons with custom fire modes. I'll put an hour or so into it tonight and put it up on github so everyone can break it

                        Comment


                          #13
                          I'm SO looking forward to that

                          Edit: TimEh could you also (maybe in a v2) collect some stats that are one for server and one for client for
                          - hit: yes/no
                          - hit coordinates
                          - fire/spawn coordinates
                          - if possible (some points on) the trajectory
                          - player and target movement from shot to hit / miss
                          - ping / lag / ?

                          so we can compare them and see where in the netcode the biggest issues arise?
                          Last edited by shox; 08-19-2014, 04:11 AM.

                          Comment


                            #14
                            Have you tried it under fluctuating ping? that is the ping jumping between 10 to 200. It might cause very bad rubber banding if client side prediction is used.

                            Comment


                              #15
                              Originally posted by Ethan Trinh View Post
                              Have you tried it under fluctuating ping? that is the ping jumping between 10 to 200. It might cause very bad rubber banding if client side prediction is used.
                              Yes I have and it works well. I've been playing around with a bunch of ways to do this. Before I was doing a lerp when the Server projectile was replicated on the client. The effect was Fast proj, then slow proj as the server catches up, then fast proj again. Very awkward rubber banding.

                              Now what I am doing is taking your average ping, and slowing the initial projectile by the amount needed to take the Server projectile to catch up within a certain distance. Then when the Server proj gets replicated, recalculate those distances by the actual network delay and ramp up the client projectile velocity over time so they line up smoothly. As long as everything is deterministic (with I need to mod the flak cannon to be) then it just works. Minus this problem...

                              When you turn really fast while shooting, sometimes the Player rotation that goes across the network doesn't match the rotation where you shot, which is bad.

                              My goal is to have an unnoticeable lag experience sub 100ms. Yes it works with higher pings, but if your ping is all over the place and you are dropping packets left and right then there's really no amount of smoke and mirrors that can make you think your connection doesn't suck

                              Comment

                              Working...
                              X