zp
faq
funny you should ask...

News
Telepunt
Download
Zeroping FAQ
Feedback

Introduction

About this FAQ

This document brings together the major objections that people have voiced against client-side hitscan, and my responses. If you're looking for information on installing and using Zeroping, see the readme.

In the weeks since I released the Alpha version of Zeroping, I've spent a truly embarrassing amount of time on the PlanetUnreal and GT forums -- answering questions, responding to criticism, and enduring flames. While it wasn't always fun, it was a good use of my time: when CliffyB and Greenmarine objected so publicly to Zeroping's approach, my answers to their arguments were well-rehearsed and ready to go.

The Zeroping Beta itself is the best response I can give to most complaints about the Alpha version. The Beta no longer bends the rules of physics, allows players to benefit from their own lag, or makes Unreal Tournament easier to hack. I hope this FAQ will answer any remaining objections to client-side hitscan.

While gameplay concerns were a major concern with the Zeroping Alpha, the new version's play is solid enough that I expect that section of the FAQ to fall into disuse. Security, likewise, is a problem that I feel I've solved in the Beta. Correctness and fairness are the real center of gravity here, and where I expect the dialogue to end up in the coming weeks. I'll probably be adding a lot to these sections as the conversation heats up.

Zeroping is an experiment, not a crusade. It may be that client-side hitscan has never been used because there's something horribly wrong with it; if so, I'll be happy to let it go -- you learn the most from the experiments that fail. But so far, I haven't heard any complaints that I don't feel I can answer. The most substantial criticisms are listed here; more will come.

Now that the Zeroping Beta puts most of my ideas into action, I'll be seeking out input from programmers in the industry and community. My goal is to get a reasonable, carefully-considered dialogue going -- on the forums, through email, or in plan files if necessary. This FAQ will always reflect the current state of the conversation. Despite the many hours I've invested in Zeroping, I expect to be the first to admit it if I'm stumped. Human nature makes it tricky though, and you should decide for yourself whether my arguments really are valid.

At the very least, Zeroping has proven that client-side hitscan can make games much more fun for modem players. If it turns out that the method can't be made secure, or fair when people's pings differ, then Zeroping will still be a mod that makes play an absolute blast for hpb's -- even if zp games aren't "serious" in some sense. Serious or not, Intercontinental Instagib is pretty magical, and will always be a venue for great exhibition games. But I contend that Zeroping is fair, and secure, and that client-side hitscan is appropriate for serious play.

First Reactions

Isn't lag just a fact of life?

Yes, but you can often hide lag with careful programming. Since QuakeWorld, games have used client-side motion prediction so that your own movement doesn't seem lagged. When you jump, modern games let you jump right away -- even though the server doesn't hear about it for some time.

We've all seen the odd side-effects of client-side movement: you seem to warp from one place to another when killed or nudged; lifts sometimes won't cooperate; and players with packet-loss appear to zoom around the level when their connections return to normal. Although these anomalies are disconcerting, it's much better to put up with them than to have a quarter-second delay on your "forward" key. With Zeroping, I'm arguing that the same is true of the fire button, and the few gameplay quirks that client-side hitscan introduces.



Why didn't you put all this work into optimizing UT's bandwidth use?

Bandwidth isn't the real problem -- latency is. Although a T1 can transfer more bits per second than a modem, its real advantage in online gaming is that those bits get to the server much faster. "Ping" measures the time it takes data to get from your computer to the server and back, and that's independent of the amount of data that you're sending. No amount of UnrealScript optimization will be able to lower your latency to the server.



Hasn't client-side hitscan been tried before?

Not to my knowledge. Old games like Doom and Duke Nukem were very different, because they didn't really use the client-server model. A lot of people have mentioned Diablo, which apparently had some disastrous client-side code. I only played Diablo briefly, but I suspect the problem was that it was allowing players to hit each other with melee weapons when they weren't really adjacent. If so, then the trouble was analogous to problems with the Zeroping Alpha: the rules of physics weren't always being observed. With the Zeroping Beta, physics is holy writ; all hits are physically possible, and you never suffer for other players' lag.

Another game people have cited is Forsaken, which may well have had some form of client-side hitscan. Can anyone refer me to documentation on this?



If client-side hitscan works, why hasn't it been used before?

Client-side hitscan sounds absolutely nuts the first time you hear about it. It opens up security and fairness issues, and just feels wrong. Game programmers with milestones to meet don't have time to spare for dead-end ideas, and are unlikely to think long about anything that sounds as kooky as Zeroping. I had client-side hitscan in the back of my mind for months before I started Zeroping. It took root: eventually, and without ever trying, I was waking up with solutions to all the obvious problems. It didn't take diligence or aptitude. It just took time.

I wrote Zeroping as an argument in favor of client-side hitscan, and am now looking for arguments against it. I've collected major objections and my responses in this FAQ, and expect to add more as the conversation continues. If anyone comes up a criticism I can't answer, I'll gladly post it here. If programmers in the industry have considered client-side hitscan and decided against it, I'd love to know why.



Is Zeroping a cheap hack?

That depends what you mean by "cheap" and "hack." If cheap means it's unfair, and hack means it's somehow incorrect, then no, Zeroping is not a cheap hack. See the sections on Fairness and Correctness for more. If cheap means inexpensive, and hack means awkwardly coded, then hell yes, zp is both (I bent over backwards to make the client-side code small).

Gameplay

Why did low- and high-ping players disagree so strongly about the Alpha's gameplay?

In the Alpha release of Zeroping, some noticeably screwy things happened when high-ping players hit people: Their shots appeared to be off-target, but registered anyway; It was possible for them to shoot people around corners; Most annoyingly, hpb's could sometimes kill you twice in a row by getting two quick headshots.

Modem players were, for the most part, glad to put up with the anomalies in return for lag-free firing. Low-ping players were understandably less happy. With hpb's getting so many bizarre-looking kills, low-pingers couldn't help feeling gipped.

The Beta version fixes the oddities of the Alpha release, and gameplay is now solid for everyone. Although very low-ping players still don't benefit much from client-side hitscan, they will notice that hpb's whine much less on Zeroping servers. That, I'm sure, will make T1 players happy.



What gameplay quirks are visible in the Beta?

Although the Beta version of Zeroping looks and feels very much like normal net play, you may notice two side effects of client-side hitscan. First, high-ping players will seem to be aiming at a spot behind you when they miss, but when they hit, their shots will be on-target. This makes hpb's look like they have worse aim than they really do, and their hits are sometimes surprising. The second side effect makes modem players' hits even more disconcerting: because your computer doesn't know about their shot for a little while, high pingers may seem to be hitting you at nearly impossible times -- in mid-dodge, for instance.

Although these side effects can be frustrating for low-ping players, it's important to understand that modem players are not having an easier time aiming than you are. On their screens, you're still jumping around like mad, and can be very hard to hit. See the section on Fairness for further explanation.



I tried a Zeroping server and it sucked. Why?

A lot of variables affect the quality of net play, and it's sometimes hard to figure out what makes a particular server perform well (or awfully) for you. Because everyone knows that Zeroping modifies UT's networking code -- but not always how -- zp often ends up taking the blame for bad connections or sick servers.

The easiest gameplay complaints to answer are the ones that have nothing to do with Zeroping. One player emailed me complaining that the Minigun is too powerful with zp; in fact, the current version doesn't affect rapid-fire weapons at all. One of the first times I played Zeroping on a public server, I was horrified to see ten-second waves of lag every minute or two; later the administrator told me that the server had been doing that before he ever installed Zeroping. On another server, a player mentioned that his ping had increased noticeably in the two days since the server started using Zeroping. A few minutes later he complained that his frame rate had dropped to 10 fps since he installed Windows 2000... two days earlier.

It happens both ways: one person emailed me to let me know that Zeroping is great, and the www.zeroping.com server is smooth as can be! But I have nothing to do with www.zeroping.com, and they don't use my mutator. He just had a good connection to a good server.

For the record, Zeroping does not affect rapid-fire weapons, projectile weapons, or movement. It doesn't change your ping (as reported on the scoreboard), make the bots harder, or cause skins to turn green. If you're seeing cows, that's the Bonus Pack.

The best way to see what Zeroping does is to join a zp Instagib game, and compare the primary and secondary fire modes. Primary uses Zeroping; altfire is the original UT code.



Does Zeroping skew Unreal Tournament's weapon balance?

Maybe. Which game has the "right" weapon balance: normal Internet play, or LAN play?

Zeroping does make the sniper rifle, shock rifle, and enforcer much more powerful than they were in the hands of a modem player. However, it doesn't make them any more powerful then they are in a LAN game. The only thing preventing CTF-Face from deteriorating into spawn-sniping in LAN play is the fear that your victim will cross the room and punch you.

I think Zeroping brings Unreal Tournament's weapon balance back to where it is on a LAN. Although projectile weapons still have lag, they're very effective anyway. Epic designed the projectile weapons so that they have strengths that compensate for the time it takes them to reach their targets: the flak cannon has shot spread, the rocket launcher has splash damage, razors bounce and the bio-rifle's all gooey. These strengths do a good job of balancing out lag, as well as travel time: modem players use the flak cannon and rocket launcher more than they would on a LAN, and often forget about the shock rifle completely.

Although the Zeroping sniper rifle may be too powerful in team games, that's not exactly my fault. The sniper rifle's just a very strong weapon, and modem players haven't been able to use it well until now.

Security

What does it mean to say that Zeroping is "secure enough?"

Zeroping is secure enough if it doesn't make cheating any easier than with normal UT, or let people cheat more for the same amount of work. Client-server games are never completely secure; a good hacker can reverse-engineer any game, and write a hack that automatically plays better than the best human. The only thing preventing people from hacking games is the time and work required (and the fact that playing with a hacked client is pretty boring). As long as Zeroping doesn't allow people to cheat more easily or effectively than they can with ordinary UT, it's secure enough. It will always be possible for people to write hacks that are specific to Zeroping, but anyone who does this is taking the long way around.



Isn't it easy to write an aim-bot proxy for Zeroping?

Not anymore. As I said earlier on my web site, the Alpha release had absolutely no protection against proxy attacks. A hacker could have written a simple program that sits between his client and the server, which would claim to have hit other players whenever he chooses. Surprisingly, no one ever did. With the Beta, this is no longer a problem.

The Zeroping Beta encrypts its network traffic so that hit packets can't be forged by proxies. Before distributing the Beta, I wiped all source code from the .u files, to make reverse-engineering difficult. Any attacker who wants to crack the encryption will have to figure out my algorithm using only the bytecode for Unreal Tournament's undocumented virtual machine, packed in a file format that's pretty confusing to begin with.

While it's not impossible to write a proxy, it's hard enough. My current encryption wouldn't stand up to serious cryptanalysis, and falling back on bytecode for obfuscation isn't exactly iron-clad. But writing a Zeroping proxy is now considerably harder than hacking Unreal Tournament's checksum enforcement, which would allow you to write an UnrealScript aim-bot anyway. Since the zp Beta only allows hits that are physically possible, you gain no more from a zp proxy than an UnrealScript aim-bot. Anyone who's attacking Zeroping's network traffic is wasting his time if his goal really is to cheat; UT is the weak link now.



Isn't Zeroping susceptible to client-side UnrealScript hacks?

If an attacker can run arbitrary UnrealScript routines on a client machine, he can easily cheat at Unreal Tournament -- with or without Zeroping.

It's possible to piggyback my encryption routines to manufacture hit packets, but there's a much simpler and cleaner way to cheat with UnrealScript: point the player at the nearest opponent, and call the weapon's Fire() routine. Once you've done that, you have an aim-bot that works with or without Zeroping. If an attacker can bypass Epic's checksum enforcement and run client-side hacks, Zeroping is just as susceptible as Unreal Tournament itself: completely.



Isn't it possible to cheat by unhooking your connection?

Not in the Beta. The Alpha version allowed you to run around killing people while you were lagged out. The Beta ignores old hit claims, and reverts to server-side hitscan. In cases of packet-loss or cable-pulling, the Zeroping Beta behaves exactly like ordinary Unreal Tournament.



Is the Zeroping Beta "secure enough?"

I believe so. Attacking Zeroping with a proxy is harder than hacking Epic's checksum enforcement. Zeroping's no more susceptible to UnrealScript hacks than UT itself is. The no-brainer plug-pulling cheat is history. Unless there's something I haven't thought of, Zeroping is now as every bit as secure as Unreal Tournament. I leave it up to the community to find anything that I've missed.

Correctness

Isn't it incorrect to let players aim at predicted targets?

We're already aiming at predicted targets -- but the prediction's normally done on the server. When you run around in Unreal Tournament, the server's idea of your location is delayed by your ping, and updated less frequently than it is on your computer. We don't usually think of the server's image of you as "predicted" because it's always the definitive version. But it is, in reality, a prediction between updates. The same thing is true of your image on other players' computers -- in fact, the same code is used to predict movement on both client and server. While the client's predicted targets are older, they're no less correct.



Does Zeroping violate the rules of physics?

The Alpha did; the Beta doesn't. The Alpha test sometimes allowed people to shoot you after you ducked behind a corner; made hits appear to miss and vice-versa; and made it possible to kill the same player twice in a row with double headshots. The Beta version puts a stop to these shenanigans. Zeroping's adherence to the laws of physics is now strict as a billiard ball's.



Isn't everyone on a Zeroping server playing a different game?

No. As always, all game state is kept on the server, and each client updates directly from there. The only change Zeroping introduces is that clients see their shots appear instantly on their own machines, and don't see exactly the trajectory that other clients will. As far as correctness is concerned, differing shot trajectories is much less of an issue than client-side movement's quirks.



Isn't this a misuse of Unreal Tournament's movement prediction?

Unreal Tournament's client-side motion predict wasn't meant to be used this way, but it works well for the purpose. In standard networking code, the client's image of another player is like a phantom: you can aim at it, but that's not what you're hitting; the real shot occurs on the server, and it's only a hit if it goes where the server says that player is. The server's idea of what's where is definitive, and the client's version of the world is just for show.

When programmers hear that Zeroping traces hits against this phantom world, they usually get a queasy feeling in their stomachs, because they've become accustomed to the idea that client-side proxies are less real. However, the server's image of a remote player is itself a shadow of where the player used to be; we only make it definitive by convention, because it keeps things very simple. We should, of course, continue to use the server image for all physics and collision detection. But the client image is the ideal (and, I believe, more "correct") target for hit tracing. It takes a little work to make the client version serve this purpose, but once done it's no less correct than tracing against server proxies.

The big hitch is packet-loss. If a player is lagged out, server-side hitscan automatically makes him pay for it. With a straightforward implementation of client-side hitscan (like the Zeroping Alpha) a lagged player can benefit, because UT's motion prediction makes everyone else an easy target. The Beta fixes this problem by having old hits timeout -- so that lagged players' hit claims are ignored, and server hitscans done instead. An ideal implementation of client-side hitscan would enforce constant refresh of proxies, but that appears to be beyond the power of a UT mutator. See the section on Fairness for more.

In practice, client-side hitscan works very well. Since Unreal Tournament uses the same code to interpolate position on both the server and the client, movement is qualitatively the same. Hit thresholding ensures that clients don't benefit from packet-loss, and that other players are valid targets only as long as they're able to keep moving. Although Zeroping has made some programmers queasy, it's made a lot of gamers happy, too. I hope this FAQ will please the queasy.

Fairness

What do you mean when you say that Zeroping is "fair?"

In Internet games like UT, players with faster computers and lower-latency net connections will always have an advantage; a truly "fair" match is impossible. My goal with Zeroping is to limit as much as possible the disadvantage of a lousy connection, without making people with good pings suffer for it.

More precisely, I'm defining "fair" in the following, very limited sense:

Zeroping is fair if it does not allow a high-ping player to win more often than he would have if he'd had a lower ping.
The phrase "more often" is in there to prevent contrived counter-examples. Whenever you change gameplay in any way, it's possible to construct pathological scenarios where a particular game's outcome differs -- even if the change is something as innocuous as lower gravity or faster lifts. I'm saying that Zeroping is fair as long as it does not allow a higher-ping player to win more often in general. An ideal test would be for two players to play a large number of matches against each other, with one player running a listen server, and alternating after each win. Unless the higher-ping player wins more often than the lower-ping player by a statistically significant margin, Zeroping is fair.

Note that my definition makes no assertion about hpbs' rights. Since I'm trying to raise modem players' gameplay above an already-low baseline, nobody's really arguing that Zeroping is unfair to high-pingers. A few people have said that Zeroping hurts modem players because it "makes them think they got skillz," or are insulted by the insinuation that hpb's need help -- but for the most part everyone agrees that client-side hitscan helps modem players. My goal in this section is to show that it does so without hurting anyone else.



Doesn't Zeroping make it harder to dodge other players' shots?

No, but other players may seem to be making some very difficult hits.

Dodging hitscan weapons is fairly steady-state: When you know someone's sniping at you, you juke and weave to stay out of the crosshairs, but you can't react to individual bullets the way that you would to rockets or plasma fire. Since you don't know in advance when and where an instant-hit shot is coming, you have no time to react to the other player's shots, and your movement pattern is what's important. If your attacker is running a listen server and has a ping of zero, her ability to hit you depends on whether or not she can click on your image while you jump around like a madman. With Zeroping, the same thing is true of all attackers, regardless of their pings. It's just as hard to click on a delayed image of a dodging player as it is a current one; you still have no idea which way he's going to jump next, even though each jump is 300 ms old. That means modem players and server ops alike find it equally hard (or easy) to hit you.

However, Zeroping can often make it seem like modem players are pulling off near-impossible shots, because other players don't see the hit until it comes through the server. Say, for example, you're double-strafe dodging repeatedly in an open area. In mid-dodge you're very hard to hit, but between dodges you're an easy target. If a modem player manages to click on you between dodges, the shot may not reach the server until you're in the middle of the next dodge. The modem player will seem to have nailed you in the middle of your slickest move, but in fact she put a bullet in your head while you were getting your footing. It's important to understand that you're getting hit because you were an easy target at some point in the past -- but you were only vulnerable to the modem player for the short amount of time that you were to everyone else. It's no easier for modem players to hit than it is for T1 players; modem players' hits just register at odd times.



What about packet-loss?

As long as opponents are getting steady updates of your position, Zeroping lets you dodge as well as before. If another player experiences heavy packet-loss, however, your image will be dead-reckoned until their client hears from the server again -- which would make you a very easy kill. The Zeroping Beta defends against this by putting a threshold on the age of hits allowed; if the server receives an out-of-date hit claim from a lagging client, it ignores it and reverts to server-side hitscan. Although the server-side shot is unlikely to hit anyone, you can't aim well when lagged out anyway, so you're suffering more than you normally would while lagged. Zeroping will display a message whenever a hit times out; if you see this message often, then you should find another server. A game with extreme packet-loss just isn't playable, with or without Zeroping.

A perfect implementation of client-side hitscan would enforce constant position refresh rates across all net connections. For example, the server would send out location updates at 20hz, and the game would not allow players to hit targets that are significantly older than 50ms. Although UnrealScript is very flexible, this kind of micro-management seems to be beyond the power of a UT mutator. If anyone knows a reasonable way to enforce constant refresh, please let me know.

In practice, Zeroping's current approach works very well. Players see each other moving fluidly except in cases of extreme packet-loss -- and in these situations the lagging player suffers, rather than his opponents. This ensures everyone's ability to dodge as long as their own connection is healthy, and prevents simple cheats like unplugging your ethernet or choking down your netspeed.



If dodging isn't steady-state, then Zeroping is unfair, right?

Nope. If dodging isn't (as I claim) a steady-state activity, then high- and low-ping players will find it equally hard to dodge each other's shots, since they both see positions that are as old as their combined lag.

Say Alice is a modem player with a one-way latency of Lag_A milliseconds (so that her "ping" is displayed in UT as 2*Lag_A). She's playing lpb Bob, with one-way latency Lag_B. If Alice strafes left at time T, her move reaches the server at time T + Lag_A, and Bob sees it at time T + Lag_A + Lag_B. If Bob strafes right at time T, the server gets word at time T + Lag_B, and Alice sees the move at time T + Lag_B + Lag_A. So each player sees an image of the other that's (Lag_A + Lag_B) ms old. If it is, in fact, easier to click on a delayed image of another player, then Zeroping is still fair (meaning high ping isn't an advantage), since players see equally old images of each other. Actually, the lower-ping player still has the advantage, since the server will hear about his shot first.



Does Zeroping make it harder for low-ping players to hit people?

Not at all -- in fact, Zeroping makes aiming more accurate for low-pingers too. But it's possible to grow accustomed to a 30-60ms lag on firing, and some hardcore low-ping players are thrown off by Zeroping. Others are afraid they'll get used to lag-free play, and lose their edge on standard servers. The Zeroping Beta allows you to disable client-side hitscan on your own weapons for just these reasons. Type "mutate zp_off" at the console, and you'll be able to play with the lag you know and love. This setting is saved in Zeroping.ini in your UnrealTournament/System directory, so you'll only need to do it once in your life (well, you'll have to do it again when the next version of zp comes out). You can use "mutate zp_on" to restore Zeroping later.

Hits:
Counter