A server side anticheat experiment

Here are a few results from an anticheat experiment I've decided to run. It's a purely server side modification -- absolutely no change to the client is necessary for this functionality.

The server computes a player visibility mask on a per client basis. This visibility mask is used to de-scope (i.e. stop transmitting data about) player objects that the client cannot see. Players obscured by hills, or walls, or the visible distance fog are no longer transmitted.

This effectively neutralizes no-fog, per-IFF, and any related hacks.

I should emphasize that this still needs tuning, and it's just a proof of concept test. At the moment the visibility calculation is too aggressive about hiding things than it should be, but the concept holds pretty well. I also don't know how this will perform on a server the size of Goon Haven, or exactly how it will interact with objective type waypoints generated by the control circuit.

I've attached a few screenshots:
#1 shows the glut of data that the server sends to the client normally.
#2 is a zoomed in portion of the enemy base on Katabatic from the allied base. Positions of players that should definitely not be visible are being transmitted.
#3 shows what happens when this visibility masker is activated. I can only see the ally on the offensive.
#4 and #5 show how the hill obscures an enemy mortar heavy.
#6 and #7 show how flag carriers are placed into scope by nature of carrying a flag (which was specifically programmed).

If all goes well in the scale-up, this could be running on the public servers soon.
  • tmi.png
  • tmi_zoom.png
  • restricted.png
  • hill_obscured.png
  • hill_obscured2.png
  • alliedcapper.png
  • enemycapper.png


  • Looks pretty awesome so far. One thing, though (I'm sure this would be possible, if it doesn't do it already, since you coded in the flag carrier stuff) - does it show enemy IFFs when they should be shown (without cheats), such as when they are standing next to a friendly pulse sensor, without any objects (other than fog) in between the observer and the enemy?
  • great stuff. keep it comin.
  • I just tested the objective marker code with these changes active. Behavior is correct and expected, which is as I had hoped.

    Sensor net support needs to be added, I wasn't going to try until after the initial tests worked out (which they have). The sensor manager in the game (which draws the circles in the control circuit, and controls the red/yellow/green indicator on the HUD), unfortunately, does not expose a way to see if an object is covered by the sensor net to the script system.

    This means that I need to implement a new sensor manager. It won't be quite as drop-in usable as it is right now (since the sensor deploy code and destroy code will need to be modified), but there's no reason it can't be done. It's just an implementation of a standard point location algorithm, which is a well solved problem [persistent red-black trees guarantee O(log n) lookup time for n sensors].

    Regarding the aggressive nature of the hiding, I plan to make visibility "sticky" -- only players that have been out of visibility for about 5 (maybe 10) cycles will be hidden. I also have a couple of math tricks that should improve accuracy when players are partially occluded by the terrain.

    It all seems very doable. The only unanswered question is performance on a large server like Goons. Once the sensor net code and scope tuning code is in, I'm sure the Goon Haven staff would be happy to give it a spin.
  • This is exactly the way it needs and must be done. This also has a benefit in bandwidth reduction from the server to the client.. As much as I love autopoints so as to send harrassing fire 1000 meters thru the fog merely to piss people off, I truly welcome an anticheat. As a footnote, there is a dll that does much the same for T1 servers, and it also is almost too aggressive in restricting data, but the beauty is there is no cheat that will overcome it.
  • It all seems very doable. The only unanswered question is performance on a large server like Goons. Once the sensor net code and scope tuning code is in, I'm sure the Goon Haven staff would be happy to give it a spin.
    We'd be happy to. Just PM Eolk and me once you're ready.
  • I believe you mentioned this in IRC - but a quick confirmation: This server-side anti-cheat system does not function as intended on a server with bots, correct?
  • The scope commands crash the server when executed on AIConnection objects. If the visibility mask calculation is skipped on bots, it works correctly. Since I was testing with bots, I added the relevant checks.

    So, bots are no problem.
  • Very cool. Is there any news on the status of the browser coming back? :>
  • Very cool. Is there any news on the status of the browser coming back? :>

    More pressing matters are at hand. But apparently there are people working it, last i heard. :D
  • I have finished implementing a shiny new sensor manager in script. It supports detection of jamming fields, as well as player coverage by the team sensor networks. The script detects the addition of new sensor objects in a very generic way, so it is drop-in suitable for just about any mod. This script was pretty annoying to implement, so I don't plan on making any significant revisions to it in the future.

    I need to implement the last handful of tricks to reduce the aggressiveness of the de-scoping code, but an alpha version should be suitable for testing tomorrow.
  • Don't forget to check visibility from several meters behind the player (third person view).
  • very cool, keep it up!
  • I finished implementing terrain partial occlusion detection, so players that are partly exposed, or close to being exposed from behind the terrain (i.e. coming up over a hill, or halfway covered by a hill) are kept scoped.

    I also added 3rd person support. The server doesn't seem to get notification of 3rd person view so I'm forced to compute both first and third person visibility.

    I had a little bit of difficulty in indoor battles, with enemies suddenly appearing, so I loosened LOS requirement for that case. With the less strict LOS, everything is normal.

    I have one problem remaining with the sensor manager that still need to be resolved. It seems to do with the way I use a dummy object and datablock to calculate jamming fields -- after a map cycle players are randomly disconnected. I have a couple of ideas for resolving it; worst case, I remove the jam detection code from the first version while I figure it out.

    There's still one minor feature left to add regarding control circuit access.

    Other than the two above issues, the only big question left if performance will be acceptable on a large server.
  • Eolk was kind enough to test an initial version on Goon Haven. With the initial settings and parameters, this script maxed out the server CPU (3 Ghz v-serv CPU) at around 12 players. The raycast operation was the most expensive computation, as I expected.

    After a bit of analysis, I discovered that the frequency of visibility mask computation was actually recomputing the same results two to three times, due to the fuzzy nature of the task scheduler.

    Further, the update rate need not be so frequent. I specifically encoded partial "transparency" to the terrain and interior types knowing that updates are not run on a frame by frame basis. By tweaking these "transparency" parameters, it may be possible to reduce the number of computations to twice per second without affecting perceived quality of the mask.

    At two visibility updates per second, I estimate the CPU max-out would occur at around 50 players. A handful of early-out visibility tricks could address another 20-30% of the raycasts, and perhaps bring 64 players into reach with acceptable mask quality.

    Too bad T2 doesn't thread the script system.
  • Could you have a modular frequency based on the number of players?
  • You can try to reverse the energy degradation of the isolinear data chips to detect localised harmonic interference in the warp core!
  • Certainly could. I just need to know if mask quality is acceptable at around 500 millisecond update schedules.
  • Would setting it to some multiple of the system timer have any benefit?
Sign In or Register to comment.