Would This Be Possible?

[Artificial]

I've been thinking about this idea for a while. And after I've seen everything you guys have done with OpenJK and also JA+/++, my curiosity has now peaked.

 

So what am I thinking about? Something very simple. A ZeroPing mod for sabers. Something that will unlag saber strikes. Now, from what I've observed, I believe that some of you are proficient in JKA's netcode. So can this can be done? I've seen it done over and over again with Unreal Tournament, UT2004, and Halo 3/Reach/4. But admittedly, saber combat is, I'm sure, definitely not like weapon combat, netcode wise.

 

But I don't know. I'm far from an expert on this sort of thing. So you guys tell me. Can this be done?

[Raz0r]

You can't predict the future, so this will only work to a degree.

You can make it so your own slashes will hit your target, but from their perspective you might have hit them from several meters away, and they would have had no time to prepare.

It would also screw over time with things like blocks.

It's definitely been thought about, but it would introduce too many visual inconsistencies and weird behaviour. It's best to just compensate manually for latency in this case.

[Xycaleth]

ZeroPing for guns works because their projectiles have a very predictable path through the world. They travel in a straight line or arc and cannot deviate from that path. With sabers, the player can change the path of the saber at any time and in any direction during the swing which isn't something that can be predicted. The only way this would work is if you were playing single player or in a LAN game where your ping is zero anyway

[Artificial]

You're all absolutely right. One cannot predict future. So let's not and have the client computer decide whether or not the saber hits.

 

Now I know what you're gonna say. It'll be very open to exploit. Well, yes it will. But then again, JKA in general is open to exploit as well. And besides, with this mod running, it would be rather easy to tell who is cheating. If someone keeps getting hits and from a distance, it's a dead giveaway. After you've established that, /amkick. And to be quite honest, I've never seen anyone cheat on JKA online at all anyway. Most of the bad eggs are focused on trolling and/or crashing servers, not winning duels in random FFA servers.

[Raz0r]

I've seen plenty of people using cheats/hacks, on almost every server.

Giving the client full control over dealing damage would present the exact same problem in my first post. Major visual inconsistencies and odd timing behaviour with blocks.

 

"Unlagged" effectively does the same thing.

Each client movement command, the server saves the client's position up to ~1000ms in the past.

When testing for a collision (e.g. when client A shoots the disruptor at client B) then client B is moved back to where their position was based on client A's ping, so they will be where client A was aiming when they sent the "fire" command.

Collision is performed, damage is (potentially) dealt, and client B is moved back to where they were before unlagged kicked in.

 

The end result is, that looks fine for client A...but let's look at it from client B's perspective.

Client B may have moved around a corner within the past x milliseconds, where x is client A's ping

Now there is a solid wall between them...yet client B gets hit and dies!

This is because unlagged was triggered by client A's input (i.e. shooting the weapon)

 

Another input to consider, is blocking with your saber - specifically client B parrying an attack from client A

From client A's perspective, client B is right next to them, and their sabers are touching. In order for client B to parry, they would have to predict that client A's saber would be colliding with theirs x milliseconds into the future, where x is again client A's ping.

 

Now going back to client B's perspective, pretend client A was standing still and swinging.

Client B runs forward, and from their perspective, their saber collides with client A's saber, and they initiate a parry.

Now client A was somehow parried by someone several meters away, with no way to predict that.

 

That's just a simple example of what crazy things would happen in both scenarios (Using "Unlagged" with sabers, or letting the client decide what happens in combat)

 

 

EDIT: Oh, hello, slight wall of text.

[Ping]

I confirm that JKA has had plenty of cheaters and still has a lot of people who would do everything to give themselves an unfair advantage over their opponents.

[Artificial]

I've seen plenty of people using cheats/hacks, on almost every server.

Recently? I've been playing on the KR server a lot. One of the most frequented servers in JKA ATM. To this day, I haven't found any cheating. Remember, however, that I'm not talking about attacks on the server to bring it down or to screw it up. Seen plenty of those.

 

Now, I KNOW this can be done and done adequately for all parties on a server. I've seen it work so well with Halo's multiplayer. I don't like to keep bringing a single game up over and over, but they really are a great example to look to. So, if they can do it, why can't we? The only reason I can think of is that the engine simply just can't allow it due to it being generally just too old.

 

If this helps, there was a very long GDC talk given by a senior Bungie network engineer in 2011 after the release of Reach. I have the written 3-page summary of it by David Rosen saved to my computer. Here's an excerpt from it.

 

 

... However, there's no optimization that can change the speed of light. If the round trip time from the client to the host is 100 ms, then everything will have a 1/10 second delay, and there's nothing anyone can do to change that. However, there are many techniques to hide this lag from the players, which are all based on prediction.

 

Prediction is the technique of changing client state before receiving authentication from the server. A simple example of prediction is shooting a gun. When the game receives input that the player has pulled the trigger, it immediately plays the muzzle flash effect and the gunshot sound. The client still has to wait for host authentication to actually damage anything, but the immediate cosmetic feedback makes it feel responsive. All direct player control is predicted in this way, including aiming and movement.

 

A more complicated example is the grenade throw. In early versions of the game, when the player pressed the "throw grenade" button, the client would wait for host permission before playing the throw animation, making the throw feel unresponsive. To address this, they made the button press immediately predict the throw animation. However, the client still had to wait for host authentication before actually displaying the grenade object itself. Fortunately, the throw animation was distracting enough that players did not actually perceive the lag there.

 

Another common lag hotspot is aiming at enemies. In Quake 3, if you aim the crosshair directly at someone running across the screen, and then pull the trigger, you will usually miss. By the time your "shoot" command gets to the server, the player is already somewhere else. Mr. Aldridge said that the way they handled this in Halo could fill up another entire talk, but the short version is that it sends target-relative gunshot information rather than world-relative. For example, if your crosshair is over someone's head, the game tells the server "I shot directly at the head of this player", and the server just checks if there is a clean shot from your gun to the player's head...

Now, having said all that, is Halo's netcode perfect? lolno. I've seen some weird stuff happen. Nevertheless, in my ignorant opinion, it is far and away better than what we currently have. Yes though, saber combat is still different from gunplay so if we were going to use this guys' advice, we'd have to adapt it appropriately of course.

 

If I'm being annoyingly persistent with this, it's only because I love the saber combat in this game so much and I die a little each time I see some BS lag kills. If there's any possibility of improving this, we should take it all the way.

[Raz0r]

Yeah, we're talking aimbots, wallhacks, ESPs, exploiting bugs through code modification, input automation (auto-kick, scripting attacks)

[Ping]

Yes, very recently. For example, there has been quite a lot of drama on the ESL as of late because some pretty widely known player has been found using a third party hack that unlocks cvars and was banned for that. Just one instance of many.

[Raz0r]

JKA uses prediction heavily, that's why your saber swinging animation plays instantly instead of waiting for the server to acknowledge it.

The problems I presented still stand.

 

The technique they describe (target-relative shot information) will achieve the same result as the existing Unlagged.

[Artificial]

JKA uses prediction heavily, that's why your saber swinging animation plays instantly instead of waiting for the server to acknowledge it.

The problems I presented still stand.

 

The technique they describe (target-relative shot information) will achieve the same result as the existing Unlagged.

OK then. Perhaps it would be best if I just gave you the link to the whole GDC talk. You can view it later at your leisure. If you find anything that you haven't already thought of, let me know. Actually let me know either way way so I know if this discussion is truly finished.

 

Heck, if anything else, you may find it entertaining to watch, even if you don't get anything new out of it. I'm currently watching it now and find the whole talk very interesting.

 

http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking

[h643]

Anti-warp would be good too. I have seen people 'lagging' through mines

[Raz0r]

JA++ and OJK force a client update with falsified inputs every g_forceClientUpdateRate milliseconds to avoid those exploits/issues.

Could also interpolate their path between frames and touch triggers.

[Xycaleth]

While the talk does present some interesting ways of hiding latency, the previously mentioned problems still stand. All the examples shown in the talk all have a fully predictable component to them. The grenade has a fixed animation length before the grenade is thrown. The armour lock is the same. The synchronized animation for assassinations works more by coincidence than by design as you can adjust the player's perception of what's happening. Compare that to two sabers colliding. What part of the collision, or the few milliseconds leading up to the collision, are predictable? There are none. If the client predicts it wrong, because the other player has suddenly turned violently or a weapon projectile caused you to deflect it, then you get horrible visual feedback.

[Artificial]

While the talk does present some interesting ways of hiding latency, the previously mentioned problems still stand. All the examples shown in the talk all have a fully predictable component to them. The grenade has a fixed animation length before the grenade is thrown. The armour lock is the same. The synchronized animation for assassinations works more by coincidence than by design as you can adjust the player's perception of what's happening. Compare that to two sabers colliding. What part of the collision, or the few milliseconds leading up to the collision, are predictable? There are none. If the client predicts it wrong, because the other player has suddenly turned violently or a weapon projectile caused you to deflect it, then you get horrible visual feedback.

 

FFS, this is INCREDIBLY tricky.

 

Hm... Well, there was one method in the talk that you might have forgotten. Shortening the times it takes for the saber to strike all on the host server when you're preparing to strike and striking.

 

For example, The player would be doing a simple right strong swing. It would look to him like the swing is going at normal speed, but behind the scenes on the host server, the swing is being carried out about, oh, twice as fast as normal. Maybe more, maybe less depending on the swing and ping.

[Xycaleth]

But that would require knowing when the collision was going to happen. And then you'd have to predict and... yeah, back to square one.

[Artificial]

Right, I'm out of ideas now. So, unless Raz0r has some, I think we're all screwed.

 

I couldn't think of anything but I don't know, I just can't help but think also that we're missing something that could work. The answer must be out there somewhere.

[Raz0r]

Yep. Playing on LAN. Or time travel. Or quantum entanglement.

I can only do 1 of those 3 =[

[Artificial]

Looking at the OpenJK source on GitHub. Where exactly can you find the netcode? Specifically for sabers?