It sounds like it’s just an equalizer that’s drawn on screen, showing the direction the audio is coming from. I guess that’s easy enough to do with the information that gets output by the game.
The use of an on-screen overlay is probably something we can detect and flag or maybe even disable.
Well when we have separate volume sliders for hitsounds/weapons/music/ambient/footsteps/etc. then everyone can be on a level playing field.
EDIT: Oh it has an reactive overlay, meh, thought it was just boosting the volume on certain sounds. Although it’s not going to be much more info than a decent surround sound system, and good for deaf players, so perhaps not such a bad thing.
Yep ! This is an important point ! How is it possible to ban a hacker when you can have unlimited accounts ?
1rst good news
[QUOTE=strychzilla;482885]Never played on the UE3 engine huh? 
That’s the awesome part about the F2P model. Plenty of hackers with unlimited accounts hehe.[/QUOTE]
I think you’re missing the point. It’s an unfinished game. It’s not even in competition… it’s mind boggling why someone would go through the trouble of hacking a game that is in a closed beta with limited numbers of players. I’m not denying the ability to do it… I’m baffled at the mentality behind it.
[QUOTE=Smooth;482940]It sounds like it’s just an equalizer that’s drawn on screen, showing the direction the audio is coming from. I guess that’s easy enough to do with the information that gets output by the game.
The use of an on-screen overlay is probably something we can detect and flag or maybe even disable.[/QUOTE]
Except for overwolf (teamspeak overlay) right? right guys? 
That way he knows his hacks work and can get them prep’d up for sale?
If you only played SD games. You will be surprised by the amount of cheaters out there.
Wouldnt this add quite a bit of overhead / latency?
Next logical step would be to stream the entire game from the server 
[QUOTE=montheponies;483689]Wouldnt this add quite a bit of overhead / latency?
Next logical step would be to stream the entire game from the server ;)[/QUOTE]
Well it works for League of Legends, who has 12 MILLION (!!) daily active players online.
So why wouldn’t it work for Extraction.
It doesn’t have to be the same server that’s running the game, it could be a service that does it’s checks in parallel.
To be honest, i dont know much of anything about the netcode side of things, but the reference to LoL feels a bit disengenuous - 5v5 with some limited actions, to me feels a world away from an online FPS. when it comes to world updates.
Also not certain what would be gained by the server checking every bit of data, apart from the obvious checks mentioned by Anti, around ridiculous shots. It’s not as if the cheat is going to be flagged surely.
The occassional tit that turns up and runs amok I can live with - they’ll get kicked and banned and that will be the end of it. The one’s that concern me, are those that run a clever mix of cheats which just provide a boost in performance that leaves you just wondering…
I say don’t ban him and keep an eye on him. Develop anticheat measures around his behavior. If you ban this guy you won’t know what else he has to offer. He might have something up his sleeve you guys don’t even know about yet.
Odd. What was the idea to move alot of calculations to the client (like hit calculation)?
(I only know this from games with huge amounts of players and huge maps, to relieve server from the massive network traffic and stuff. In xT we have only 5v5 to 8v8 …).
Need a Tapir Carmack, software profiling, perfect performance in xT, for people with 2010 PCs.
Kinda reminds me of DayZ Arma, and Rocket with his “nätwörk bubble” 
It makes it WYSIWYG, no need to lead your target and equally important no need to lead your target by different amounts depending on server latency.
Ah, ok. Makes sense. Sorry for the (pseudo)smartass post below, but just wanna make sure i understand this.
Consider this
A) X shoots at Y, X calculates hit client side, if hit, then hit moves to server, from there to client Y.
B) X shoots at Y, shot info moves from X to server, server calculates, if hit, then hit moves to client Y.
A is WYSIWYG
B is old quake style
I assume packet travel times with ping 80 ms via each paths:
In situation A:
confirmation of hit (from time it was confirmed, namely at client) will reach client Y 160 ms ago (- (S + T)).
In situation B:
confirmation of hit (from time it was confirmed, namely at server) will reach client Y 80 ms ago (-T).
Is this true until here? Or does the client X directly communicates a hit to client Y, and the server is not important?
Clients do not communicate directly, so server is important.
Also hits are not confirmed at client, they are detected, this information is then sent to the server which confirms it based on what it knows (player position, client hit detection info, anti-lag compensation, could the player have made the shot i.e. they haven’t teleported across the map to take the shot then teleported back to their starting point, etc.)
At least that’s how it should work, I believe the server confirmation is pretty basic right now and needs to evolve to include more such “checks”.
waits for SRS-Kap to burst in and yell at me for being completely wrong