Server-side hit detection



  • Anyone knows why chivalry uses client-side hit detection? I’ve been making some tests and I think server-side hit detection would work just fine. And it would fix a lot of the desyncs/“instant hits”/speedhacks….

    The mod I’m working on that makes hit detection server-sided (for the melee attacks):
    http://steamcommunity.com/sharedfiles/filedetails/288698496

    Some issues so far (I only tested playing in an empty server against bots):
    -You lose stamina even when you hit the target (As a temporary fix I enabled infinite stamina)
    -You can’t hit the corpses’ ragdolls (the ragdolls don’t spawn in the server)
    -Some weapons still have client-side hit detection (such as the 1h versions of 2h weapons). You can use aoc_drawtracers to check if the weapon is drawing tracers.



  • So if your ping is more than 50 you’ll be lagging hard.

    Thats how counterstrike simulates bullet travel by having serverside hit detection with bad lag compensation.



  • Because server support for Chivalry is pretty poor and above 50 ping the game would be unplayable, now it’s unplayable only above 100.



  • Do you guys actually know what you are talking about or are you just speculating? Well… you could try the mod and see for yourself if you are right.



  • I would love to get some in depth analysis ,how the game behaves when you move hit detection to other places.

    Hit detection is like tug of war

    Attacker–----------Server----------Defender

    Imagine the defender detectecting if he’s gonne be hit. (Not talking about cheats here)
    From now on people cant drag stabs into you without you seeing them.
    Attacks will not hit you before the animation reaches you.
    This would be like heaven.



  • Well in the jedi knight series server side hit detection worked pretty well.



  • Chiv is really twitchy melee game, even 50ms input lag would be disastrous, goodbye punishing feints, you make decisions in 10ms here. I don’t know maybe it could be worked out through magic. Or everyone could gather in a LAN when they wish to play Chiv.

    And don’t forget rotational velodencity.



  • Server-side isn’t all bad. It could probably be done correctly. We’re already getting double latency when reading and parrying attacks due to client-side hit detection (attacker + defender pings).



  • @dudeface:

    Server-side isn’t all bad. It could probably be done correctly. We’re already getting double latency when reading and parrying attacks due to client-side hit detection (attacker + defender pings).

    Yeah, that’s what I think too.

    The way chivalry’s hit detection works now:

    -The attacking client begins an attack. The animation starts immediately on his side and he tells the server that he is attacking.
    -The server receives the message and tells the other clients to start the animation.
    -Only then the other clients know that they have to start the attacker’s animation (you have the latency of attacker->server->you).
    -The attacker’s client does the hit/parry detection and if it is positive it sends the results to the server.
    -The server checks if the parry is valid or if there was a hit, and then send the results to all clients, including the attacker’s.

    With server sided hit detection it would work like this:
    -The attacking client begins an attack. The animation starts immediately on his side and he tells the server that he is attacking.
    -The server receives the message and tells the other clients to start the animation (and also starts the animation on the server).
    -The other clients receive the message and start the attacker’s animation on their side (more synched with the animation that will actually be used for the hit detection).
    -The server does the hit/parry detection/validation and sends the results to all the players, including the attacker.

    So, if anything, server-side hit detection would actually make parrying more reliable and reading feints easier. The only downside I can think of is that the attacker will have less precision in his attacks if he is lagging (which IMO is better than having him ruin the game for everyone else)



  • there are some people out there that have good pings and still do unblockable riposes.
    And i beleave these people run on like 20fps giving them additional lag bonus.
    But so hard to prove



  • server side hit detection is good for everyone but the server because it makes the servers work harder which can cause them to lag (fixable by not hosting on a shit server lol)



  • Server-side hit detection would balance out the attack/defense aspect of the game I would think.

    Client side hit detection favours the attacker, hence overhead lookdowns that, if the attacker-defender ping discrepancy is high enough, makes that attack instant hit.

    A server side hit detection would mean that the attacker-defender ping discrepancy would only matter half as much.

    Of course the payment for this is that attacks have a slight delay on them, giving the defender a fairer chance to defend. The system should eliminate non-packetloss desyncs though.

    I could see also that before the attacking animation is displayed on the screen a confirmation packet has to be sent from the server saying it received the command to attack, now client play the animation, effectively doubling the latency time before animation is played.

    For example. at 60 ping. C = client, S = server.

    C. Attack.
    60ms
    S. receive attack
    60ms
    C. Attacker - Play Attack animation. Client - Defender Play animation

    So a delay of 120ms before attack animation is played, this is potentially too long. The defender though, to them they are only 60ms behind…

    Right now it is
    C-attack - play animation
    60ms
    S- receive attack command
    60ms
    Defender client - play animation. So the defender see’s the attack 120ms late.

    Then for arguments sake lets look at the process for the attack-defend scenario.

    Current
    C.Attacker - Attack - Play Animation
    60ms
    S.Receiver Attack command - send to other clients.
    60ms+ (depending on other clients)
    C.Defender - Play animation 120ms late. Does Unreal Engine/Chivalry skip the first 120ms of an animation to have it catch up to the attackers?
    C.Defender - respond to attack
    60ms.
    S. Accept command. Send to Attacker
    60ms.
    C.Attacker - Check to see if weapon hit person or defended. (Note, this check is done on the attackers computer according to the attackers timeline of events, so potentially if ping discrepancy is big enough the attacker has attacked, checked and hit the defender before the defender even receives the original attack command, very problematic for OH lookdowns for example)
    60ms
    S.Accept result. Send to defender
    60ms
    C.Defender WTF may parry didn’t work!!!111one.

    Consider this option instead, if the above is indeed how Chiv works.
    Why not implement a pseudo peer-to-peer system. Skip the middle man so to speak.
    So when Client attacker attacks- the client sends the attack command to the server as usual but also to the clients in a small radius directly. It would cut down the latency delay by half, allowing the defender a more accurate chance to defend, whilst the server reports to other players outside that radius and serves as a backup to those in the radius.

    This would give the attacker the instant feedback from attacking which we all want, whilst bridging the gap between attacker-server-defender to be attacker-defender.

    Is the mod able to do that OP?



  • there are some people out there that have good pings and still do unblockable riposes.
    And i beleave these people run on like 20fps giving them additional lag bonus.

    There is no such thing as an unblockable riposte.

    FPS has nothing to do with lag.

    You make me cringe consistently.



  • server side hitties is n0othing new tbpc, just some random code generated by the server in secret algorithms and permutation of APM don’t justify the server hosting its own actions, as we saw in Battlestar Galactica

    even if this idea was taken seriously, the risk of TB collateral damage is too great. its just not worth it, kind of like aids



  • With server sided hit detection it would work like this:
    -The attacking client begins an attack. The animation starts immediately on his side and he tells the server that he is attacking.
    -The server receives the message and tells the other clients to start the animation (and also starts the animation on the server).
    -The other clients receive the message and start the attacker’s animation on their side (more synched with the animation that will actually be used for the hit detection).
    -The server does the hit/parry detection/validation and sends the results to all the players, including the attacker.

    This is why I think it should go like this: (attacker and defender 60ms ping)

    –The attacking client begins an attack. The animation starts immediately on his side and he tells the server that he is attacking. He also DIRECTLY tells all players within 5 meters that he is attacking.
    – Clients within 5 meters start playing animation, 60ms late) . any response they do is also sent directly to the Attacker and server at the same time.
    – Sever receives the message and tells the other clients outside of the 5 meter radius to play animation.
    – The Other clients play the animation - 120ms late. These clients are unconcerned about the combat directly)
    – The Attacking client does the hit/parry detection as normal.

    This would effectively halve the time delay between attacker and client offering a more consistent game for the defender, whilst keeping the attackers game very similar to now.

    Since the Hit/parry detection is already client side, we are NOT utterly required to send the info to the sever over the defending client. so send that info directly to the client.
    The server in this instance on exists to tell the rest of the players what just happened in the combat, it isn’t authoritative.

    This option is the best of both worlds.
    So can the Chivalry Client communicate DIRECTLY with other clients, if the server provides a list of client ip’s upon connection?



  • NA haven’t discovered sub 15fps meta with unblockable ripostes, didn’t you know that your own fps directly affects to how fast you swing? LMAO



  • I would say there could be an argument made that at very low FPS, the delay in calculations on the attackers PC may have an impact on hit/parry detection, not sure as to which way that could go, intuition tells me it would be in the defenders favour. However yeah, that would be at like 15fps or less and, well good luck playing with that…



  • @Toll:

    This is why I think it should go like this: (attacker and defender 60ms ping)

    –The attacking client begins an attack. The animation starts immediately on his side and he tells the server that he is attacking. He also DIRECTLY tells all players within 5 meters that he is attacking.
    – Clients within 5 meters start playing animation, 60ms late) . any response they do is also sent directly to the Attacker and server at the same time.
    – Sever receives the message and tells the other clients outside of the 5 meter radius to play animation.
    – The Other clients play the animation - 120ms late. These clients are unconcerned about the combat directly)
    – The Attacking client does the hit/parry detection as normal.

    This would effectively halve the time delay between attacker and client offering a more consistent game for the defender, whilst keeping the attackers game very similar to now.

    Since the Hit/parry detection is already client side, we are NOT utterly required to send the info to the sever over the defending client. so send that info directly to the client.
    The server in this instance on exists to tell the rest of the players what just happened in the combat, it isn’t authoritative.

    This option is the best of both worlds.
    So can the Chivalry Client communicate DIRECTLY with other clients, if the server provides a list of client ip’s upon connection?

    That could work, but I don’t think udk supports peer-to-peer.



  • I also don’t think it does unfortunately, as that would be the best approach. Otherwise I think it should be Sever-side, in order to remove the inherent advantage of attacking over defending.



  • How does your server-side feel with a ping of about 80.

    You should make a developer option so that you can ‘simulate’ higher pings by adding an artificial delay to sending the command to the server. So you Attack + 80ms, to see how it feels for your ping+80ms (eg, instead of 60ms, you can test it for 140ms).

    You would have to test the mod with people not bots, so you can feel how drags, feints, OH lookdowns, etc ( all the stuff bots don’t do, which is a lot) feel.

    I was thinking about doing a mod like this myself, but I’m lazy. Glad someone else did.


Log in to reply