Making Your Cheat P (MYCP) 1 – Resolvers and Antiaims

So I’ve seen that there’s a lot of misconception regarding anti-aims and resolvers, and there’s a lot of struggle making them even semi-decent. I’m here to rectify that by giving information on the logic behind anti-aims and resolvers in order to get everyone’s brains working toward a common goal, taking the next step to beating the current limiting cheat factor.

First, let me explain what anti-aims and resolvers are for the new people – skip this section if you know it/don’t care. Next, I’ll describe anti-aim and resolver functionality and one method to achieve successful functionality strictly regarding a cheat’s code logic. Then lastly, I’ll describe the same thing as before, but strictly regarding a cheat’s game play.

 It’s important to understand the concept of getting ahead in the cheating community. When the aimbot was made, the first thing people wanted to do against another cheater with aimbot (since the playing field was level) is to get another advantage – so the anti-aimbot was made. The logic in this layer is: “If my cheat is better, I can’t lose.”
 Originally, they were made in games with poor networking, where you could stutter your angle between two values and the enemy would only have a 50% chance of hitting your head if they were on you perfectly. The next step was to make an anti-anti-aim, which included finding the pattern of their angles and predicting where it would be. This is the limit to aimbots and anti-aims in other games, generally. In CSGO it’s a little different.
 In CSGO, there are exploits, where you can manipulate the engine to do your bidding and push the limits of it so long you understand it. The first exploit to get ahead of anti-anti-aims was the fake angle – which was accidentally created by some chick trying to recreate an air stuck/fake lag exploit. Long story short, the server displays incorrect information to the players about your hitbox location.
 After some people got a hold of the methodology to do this and it spread like wildfire, someone had to figure something out to stop this – luckily this doesn’t have to be through prediction. I think someone noticed the legs/lower body of the enemy is sliding/is really weird and decided to investigate that part of the engine, and found a way to read the orientation of the targets lower body to find the real hitbox location. This was the first real resolver.
 The next step in this arms race of cheats is to make something that breaks the resolver. Someone who knew a lot about how the engine worked and has created a resolver before found a delay/inconsistency with the lower body updating while jumping(?)/standing still. The server sends updated information about the enemies lower body every 1.1 seconds when standing, and the rest of the time their angle is a mystery.
 Now, we’re current; we’re at the point of trying to resolve this seemingly unresolvable anti-aim. We’ve gotta go back to the basics and predict where the hitbox is just like we originally did with the first anti-aims.

 As for actually making the anti-aim: I’ve kind of already explained it, but an LBY breaker is just something that sets your real to your fake for one tick every time your LBY updates, then moves the real head far away from the fake in order to stop from being hit. It’s important to draw a trace-ray from the enemies angle origin to your LBY to make sure that the ray doesn’t intersect with your real head – this stops people accidentally getting headshots [btw I’ve never seen any cheat, both private and P2C, aside from u~~~~, use this logic before – you people reading this will be the first].
 Okay – the resolver. Like I was saying, going back to the basics and predicting where their head is based on your knowledge of anti-aims. For the original anti-aims, this was just recording two angles and timing the shot to line up; for us, we’ll need to do some basic statistics. See this post for more info on making a resolver (this post is incomplete, but i explain everything else you need further down the thread). You can customize it as you please (such as making functionalities to brute force or to body-aim when not resolved, or to just wait entirely until resolved) once you get the basics down and a feel for what you need to be doing.

 This entire anti-aim vs resolver can be considered one layer – breaking the other’s cheat. The next layer is protection. The logic in this layer is: “Who cares what their cheat can and can’t do? Let’s just make sure I can kill them before they can kill me, the technology doesn’t matter.” There are two parts to this – stationary protection and mobile protection.
 What does “protection” mean in the context of anti-aims? The idea is to make the most lethal parts of your body unhittable, and focus on killing the enemy quickly.
 Stationary protection is the idea that you take whatever is in your surroundings and use it as cover (things like walls to stick your head in). If you can’t find cover through analytical means (such as wall detection), find it through contextual means (such as freestanding edge). To start you off with one of the more complex topics: free standing edge is just splitting your enemy into two parts – a spot that’s hittable and a spot that isn’t – and splitting yourself into two parts – a spot that’s hittable and a spot that isn’t. If the left side of your model is being shot at, but the right side isn’t, there’s cover to your right. If the enemies left body can be hit, but not the right body, there’s cover to your right.
 Mobile protection is the idea that you take contextual clues from the player’s movement manipulation. To start you off with the logic: if the player decides to run left, then the first place that will be visible to the enemy is the left part of the body, so stick your head to the right. Now merging these two logical ideas is how you reach perfection for mobile protection. If you are stationary, and the first part of an enemy to appear is the left side, and the player begins running to the right, it’s best to stick the head to the right and keep it there in order to stop the enemy from killing us – the key here is predicting what the player will do in order to stop yourself from killing yourself with poor hitbox placement; this isn’t too hard, and is actually less predicting than you think.

Alright, that’s it. You’re now a pCheatCoder.

If you want me to add something to this, clarify something, fix something I messed up, or if you want me to cover another topic for MYCP 2, let me know. These MYCP posts will strictly regard to cheats functionality and not tutorials with code.

credit to those p2c coders who have helped me progress at the same rate as them (you know who u are ). a big tip is find some decent coding friends in the community so u don’t get left out on pFeatures.