Easy fix for Cheaters, this will solve everything.

@PRX_its3 

Glad you brought this up.

My friend and I thought we were playing a bot, like a fortnite bot, an actual AI.

I have seen some very SUS gameplay from opponents recently. People absolutley wiping and destroying my squad by themselves, then I got to spectate and they act like they have the IQ of a carrot. Absolute brain dead behavior. They always die, instantly after I specate them. The first fight they get into, after I start spectating, they get clapped.

The majority consensus here seems to be, stop giving Respawn suggestions because fixing the hacker problem is too hard. I have not seen any other suggestions offered. Only people saying, a kill cam system is too hard.

According to the folks in this thread, cheaters are fine because the issue is too hard to fix for a "AAA developer" who makes billions and has billions of dollars in funding. It is their job to fix things like this, is it easy? No. But they could do it. They had 7 seasons. And are apparently working on season 12 crap. Stop. How about fix they game first, then work on new content later.

@EA_LannaWhy do u guys keep this forum if you can t help the community?
This is the best ideea ever to stop people cheating.....just send this thread at respawn devs😉

To some of you saying it's possible to have a "perfect replay"... 

Yes and no,    you can have 1:1 replays within reason by upping the tickrate of the servers.... or having a client side replay being recorded for the suspected player,  which is never EVER going to be secure.

Someone else on here mentioned low tickrate (or specifically low amount of data points) and he is perfectly right about this..

Running 20 tick servers means you are essentially recording 20tick demos/replays as a result, even if you do client side replays on your end you are seeing opponents being sent at 20tick (and you have interpolation/antilag delay on top of this).. interpolation is used (and would be used for demos as well) to smooth this out or everyone would be stuttering across the screen.

Others have mentioned cs on here as well, which pretty much means they are talking about HLTV (or local demos as mentioned above)..  both are subject to the server tickrate as the clients are sending roughly 20tick anyway.

And even if you were using something like HLTV  (which is basically a proxy server, simulating a client)  you are going to end up with the exact same problems, on top of being massive resource hogs (unless you are limiting the proxy tickrate to counter this as you are ignoring PVS i.e the players you can see and sending all positions at all times which is intensive as hell...  and in the end ultimately defeats the point).

The only way you are going to effectively (or as effectively as you can) combat cheats is to go the way of valorant with a very invasive kernel level anticheat... which opens up a whole other discussion about trust and security.

@EA_Lanna 

So you're saying that you won't move a finger to help us combat cheaters, that Kamu website is a joke, meaning you don't and won't help us reporting cheaters other than putting in some buttons, and doing nothing about it.

Never seen anything like it, you couldn't care less about us, players... That's a shame...

@pitchsomfanFun fact, I've seen a bunch of people report cheaters in Valorant. I only played the game once for about an hour. Most players seemed legit, a few.. eh not so much.

Just because the anti-cheat is on a kernel level, doesn't mean a cheat can't act like an innocent app and get through it.

I have to use a special browser for school, that's suppose to "lockdown" the system and forces applications closed. It only bothers to make me close Discord, Xbox Toolbar (where Windows has access to Xbox stuff), and sometimes my calendar and email app. It's suppose to force my browser to close as well, but I've been using Opera. Which, it doesn't ask me to close.

The whole point of this browser is to prevent cheating in tests. If something like this can't detect a special kind of browser, what makes you think a kernel level anti-cheat won't make the same mistake?

I'd like to end this discussion if I could.

There are a few factors here:

1. For a kill-cam to work, Respawn would need to rework the spectating system.

2. Would I be correct to assume Shadowplay highlights reserve space in order to hold replays until they are compiled when the user hits save? Along that vein, wouldn't the same be true for kill cams, but require a considerably smaller amount of space? I imagine the replay information would be much smaller than a video, considering the kill cams wouldn't be videos, nor would they be over a minute.

3. Apex netcode is a big issue. For a replay to work well, the tickrate needs to be higher. Valve already had complaints about 32-tick CS replays (and Apex is even less). Given how frequently I experience very inconsistent server performance (SEA mostly), I imagine they have no plans to implement this, nor intend to improve their netcode. We know what's possible, but Apex isn't a passion project for Respawn, or many of the features we're asking for would have been implemented already.

Unfortunately, the devs and players don't the love Apex the same. EA use Apex for PR, or they'd have worked on the functional components of the game, and less about making Fuze a Pansexual (seriously? that's not very true-blue aussie).

Tangent aside. The track record says we won't get it (which is no excuse), I think we deserve better, we know it can happen, Respawn make it happen. The effort you put in now will reduce the effort required later (a good killcam system will mean less false reports, hence less effort).

1.

A whole lot of reworking is not needed,  at least not for a simple kill-cam.

The building blocks are already there as they use interpolation based on several data points (in this case 2-3 buffered snapshots). 

It's more a matter of saving those snapshots and then implementing a replay system of sorts on top of this, either by rendering the replayed information to a render target (google it), or rewriting large chunks of their client logic to force the entire view on the snapshots (this takes a lot more work in general to do).

2.

Yes, it would require to save data at some point, but these are so small that you could save them on ram without issues (until you decide to save them to disk, or just save them on disk and be done with it).. at 20hz and saving the entire entity table (position,angles,weapon etc) for a 10-20second period would be less than 2mb of ram usage.... even less on an empty server... and this is assuming you aren't compressing it, which would make it even smaller.

3.

Apex netcode is generally fine (at least in terms of implementation and concet), the overall issue is from tick rate fluctuations as these are going to affect everything from bullets, grenade etc travel to how information is sent to the clients themselves. (in short: fluctuations in tickrate/frametime will cause bullets/grenades etc with drop to land in different places..  if everything was flying completely straight this would be less of an issue though).

Causing hit reg issues, sounds being ignored etc (why would you ever need to send EVERY SINGLE SOUND around the map? JUST WHY?)...  from what i can see from inspecting packets and the overall bandwidth usage apex is just terrible at handling things in general as they are sending WAAAAY too much every tick...

Just as an example,  the general implementation of sending each individual footstep is completely unnecessary when you are already sending specific animation states (which you need to do without breaking hit reg completely)...  yet that is what they are doing,  they are most likely doing the same for gunshots.. which again is unnecessary as you are already sending animation states.

To be clear, this has less to do with netcode and more to do with what they are sending at any given time.. they can have the best netcode implementation in the world but it's still going to fail if you are trying to push too much at any given time.

So in short, they need to be more efficient with their overall code and get better servers..  at that point they can start thinking about 60hz servers (40hz would be enough imho, but whatever).

And again to be clear.. if the client is anything to go by they are most likely running into issues with their VPS being severely cpu bottlenecked (meaning it's not utilizing cores effeciently)..  

For example, having 35% cpu usage and 72% gpu usage on a 4 core 8 thread cpu (on a 1660ti) doesn't exactly inspire me with confidence on the server side of things.

"The track record says we won't get it (which is no excuse)"

This i completely agree with.. i have zero hopes of things getting better... they are already so far behind some of their competitors on the technical side of things, and there doesn't seem to be any improvement coming... that and the constant cheating issue is driving me to a point where i am getting fed up with playing apex as a whole.