Source Correcting fakelag after fake angle patch

Quendi

User
User

Quendi

User
User
Status
Offline
Joined
Jun 4, 2019
Messages
54
Reaction score
487
Most of the explanation for this is in the code itself. Please note that this only works with the current state of cs go packet handling and networking, refer to how players are simulated on the server now vs before the fake angle patch (Now all commands get simulated). Now that we know this fact, we can use it to our advantage. PS. This also allows us to lag compensate players who are "breaking" it, which was not possible pre-fake angle patch (again, each commands gets simulated and you simply cannot move that much in a given tick as to break it, if the other player is using a fix like shown). Basically everything related to the simulation is left out, and only a primitive example is given. This is because everyone having perfect simulation wouldln't be fun in hvh. The ones who are smart enough to build their simulation accurately will get rewarded. On the topic of resolving these ticks, it is largely like pre fake angle patch, as you do not have their eye angles for these ticks. If you cannot reliably correct them, body-aiming these ticks would be smart. Result of near perfect prediction below.
C++:
void animation_system_rebuilt::process_predicted_animations(c_entity* entity_to_predict) {

    /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/
    // This is very basic and should only be used as guidance when constructing your own player simulation logic.
    // Full paste will not be given. I believe that with this info given and no more, the gap between good and bad cheats will widen, which is good.
    // No validity checks performed here since all are done beforehand. Of course you can add those if wanted.

    // Use latest predicted data to predict next tick too.
    c_animation_system_data resontructed_data = animation_system_rebuilt::stored::data.at(0);

    // If in air we can just use our latest up velocity to predict the next since how it decreases is very simple.
    // velocity_decrease you will have to figure out yourself, though a tip for you is server_anim_state->base_entity + 388.
    // Of course adding something like bhop detection would be nice but once again, that will be up to you.
    if (!(reconstructed_data.flags & flags::player::fl_onground))
        reconstructed_data.animation_instance.velocity.z = std::max(0.f, reconstructed_data.animation_instance.velocity.z - velocity_decrease);
    else
        reconstructed_data.animation_instance.velocity.z = calculate_ground_velocity_z(bsp_scan::movement_dir_ground_level(reconstructed_data.animation_instance));

    reconstructed_data.animation_instance.velocity.x = ; // Calculate these yourself. I'm not going to spoonfeed everything, and since this is basically the most important part especially on moving players, no.
    reconstructed_data.animation_instance.velocity.y = ; // A couple hints i can give you is that you need to account for stamina, acceleration/deceleration, current and old movement direction.

 
    // The point of this is to correct the direction of the player and determine the player's new origin.
    reconstructed_data.animation_instance.origin = extrapolate_origin(reconstructed_data.animation_instance.origin, reconstructed_data.animation_instance.velocity)

    // Source will not be posted, though looking at how the server handles pose parameters is a good start. Refer to functions called from CCSGOPlayerAnimState::Update();, they control most of this.
    resonstructed_data.poses = animation_system_rebuilt::construct_player_poses();
    reconstructed_data.flags = animation_system_rebuilt::construct_player_flags();
    reconstructed_data.animation_instance->udpate();

    // We need to correct timulation time for our record so we can abuse the game's lag compensation to essentially unlag compensate them.
    // Doing this is relatively simple, we just take their current simulation time, add the amount of ticks predicted, and then the lerp
 
    reconstructed_data.simulation_time = entity_to_predict->m_flSimulationTime() + ticks_to_time(animation_system_rebuilt::stored::data.size()) + animation_system_rebuilt::lerp();

    // You could use the game's default bone set up here but your results will of course not be as accurate as proper bone setup.
    // We will be using these bones for our aimbot.
    animation_system_rebuilt::allow_bone_setup();
    reconstructed_data.matrix = animation_system_rebuilt::build_entity_bones(reconstructed_data);
    animation_system_rebuilt::disallow_bone_setup();
    animation_system_rebuilt::stored::data.emplace_front(resonstructed_data);
    latest_predicted_entity = resonstructed_data.entity;
}

bool animation_system_rebuilt::handle_commands(c_entity* entity) {
    static bool needs_resimulating = false;
    if (!entity)
        return false;
    // This is lacking about 100% of everything else done, i am only including what is essential.
    // Look at C_CSPlayer::PostThink() in both the client and the server for more insight.
    // The included code is for the most part in this function in void of any anti paste, so enjoy.
    static c_entity* latest_networked_entity = nullptr;
    if (new_commands_incoming) {
        animation_system_rebuilt::process_networked_animations(entity);
        latest_predicted_entity = entity;
        needs_resimulating = true;
        return true;
    } else if (needs_resimulating) { //We want to predict all of the possible ticks the player could be choking as soon as we can, so we can predict them whenever we want.
        for (unsigned int process_index = 0u; process_index < sv_maxusrcmdprocessticks; ++process_index) {
            animation_system_rebuilt::process_predicted_animations(latest_predicted_entity); // This also updates latest_predicted_entity.
            // We want to break out of prediction and start over next time if our product is faulty.
            if (!latest_predicted_entity) {
                needs_resimulating = true;
                return false;
            }
        }
        needs_resimulating = false;
        return true;
    }
    else // Nothing new to handle.
        return false;
}

void lag_comp() {
    for (auto lag_iterator : animation_system_rebuilt::stored::data) {
        // Sort your records and whatnot as if you would with normal records.
        get_best_record();
    }
    /*
        Do the rest as you would with normal lag compensation.
        The normal forward track limit of 200ms does not exist here.
        This is because we will be shooting our shots at the moment that the player is where they are.
        The server will register our shot when the enemy stops choking and it runs hitscan on the choked ticks.
        Our code will not work without this since that would be like backtracking without backtracking, it won't magically work.
    */
}
 

glebokkk

Newbie
Newbie

glebokkk

Newbie
Newbie
Status
Offline
Joined
Jul 5, 2019
Messages
15
Reaction score
11
Most of the explanation for this is in the code itself. Please note that this only works with the current state of cs go packet handling and networking, refer to how players are simulated on the server now vs before the fake angle patch (Now all commands get simulated). Now that we know this fact, we can use it to our advantage. PS. This also allows us to lag compensate players who are "breaking" it, which was not possible pre-fake angle patch (again, each commands gets simulated and you simply cannot move that much in a given tick as to break it, if the other player is using a fix like shown). Basically everything related to the simulation is left out, and only a primitive example is given. This is because everyone having perfect simulation wouldln't be fun in hvh. The ones who are smart enough to build their simulation accurately will get rewarded. On the topic of resolving these ticks, it is largely like pre fake angle patch, as you do not have their eye angles for these ticks. If you cannot reliably correct them, body-aiming these ticks would be smart. Result of near perfect prediction below.
C++:
void animation_system_rebuilt::process_predicted_animations(c_entity* entity_to_predict) {

    /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/  /*DISCLAIMER*/
    // This is very basic and should only be used as guidance when constructing your own player simulation logic.
    // Full paste will not be given. I believe that with this info given and no more, the gap between good and bad cheats will widen, which is good.
    // No validity checks performed here since all are done beforehand. Of course you can add those if wanted.

    // Use latest predicted data to predict next tick too.
    c_animation_system_data resontructed_data = animation_system_rebuilt::stored::data.at(0);

    // If in air we can just use our latest up velocity to predict the next since how it decreases is very simple.
    // velocity_decrease you will have to figure out yourself, though a tip for you is server_anim_state->base_entity + 388.
    // Of course adding something like bhop detection would be nice but once again, that will be up to you.
    if (!(reconstructed_data.flags & flags::player::fl_onground))
        reconstructed_data.animation_instance.velocity.z = std::max(0.f, reconstructed_data.animation_instance.velocity.z - velocity_decrease);
    else
        reconstructed_data.animation_instance.velocity.z = calculate_ground_velocity_z(bsp_scan::movement_dir_ground_level(reconstructed_data.animation_instance));

    reconstructed_data.animation_instance.velocity.x = ; // Calculate these yourself. I'm not going to spoonfeed everything, and since this is basically the most important part especially on moving players, no.
    reconstructed_data.animation_instance.velocity.y = ; // A couple hints i can give you is that you need to account for stamina, acceleration/deceleration, current and old movement direction.


    // The point of this is to correct the direction of the player and determine the player's new origin.
    reconstructed_data.animation_instance.origin = extrapolate_origin(reconstructed_data.animation_instance.origin, reconstructed_data.animation_instance.velocity)

    // Source will not be posted, though looking at how the server handles pose parameters is a good start. Refer to functions called from CCSGOPlayerAnimState::Update();, they control most of this.
    resonstructed_data.poses = animation_system_rebuilt::construct_player_poses();
    reconstructed_data.flags = animation_system_rebuilt::construct_player_flags();
    reconstructed_data.animation_instance->udpate();

    // We need to correct timulation time for our record so we can abuse the game's lag compensation to essentially unlag compensate them.
    // Doing this is relatively simple, we just take their current simulation time, add the amount of ticks predicted, and then the lerp

    reconstructed_data.simulation_time = entity_to_predict->m_flSimulationTime() + ticks_to_time(animation_system_rebuilt::stored::data.size()) + animation_system_rebuilt::lerp();

    // You could use the game's default bone set up here but your results will of course not be as accurate as proper bone setup.
    // We will be using these bones for our aimbot.
    animation_system_rebuilt::allow_bone_setup();
    reconstructed_data.matrix = animation_system_rebuilt::build_entity_bones(reconstructed_data);
    animation_system_rebuilt::disallow_bone_setup();
    animation_system_rebuilt::stored::data.emplace_front(resonstructed_data);
    latest_predicted_entity = resonstructed_data.entity;
}

bool animation_system_rebuilt::handle_commands(c_entity* entity) {
    static bool needs_resimulating = false;
    if (!entity)
        return false;
    // This is lacking about 100% of everything else done, i am only including what is essential.
    // Look at C_CSPlayer::PostThink() in both the client and the server for more insight.
    // The included code is for the most part in this function in void of any anti paste, so enjoy.
    static c_entity* latest_networked_entity = nullptr;
    if (new_commands_incoming) {
        animation_system_rebuilt::process_networked_animations(entity);
        latest_predicted_entity = entity;
        needs_resimulating = true;
        return true;
    } else if (needs_resimulating) { //We want to predict all of the possible ticks the player could be choking as soon as we can, so we can predict them whenever we want.
        for (unsigned int process_index = 0u; process_index < sv_maxusrcmdprocessticks; ++process_index) {
            animation_system_rebuilt::process_predicted_animations(latest_predicted_entity); // This also updates latest_predicted_entity.
            // We want to break out of prediction and start over next time if our product is faulty.
            if (!latest_predicted_entity) {
                needs_resimulating = true;
                return false;
            }
        }
        needs_resimulating = false;
        return true;
    }
    else // Nothing new to handle.
        return false;
}

void lag_comp() {
    for (auto lag_iterator : animation_system_rebuilt::stored::data) {
        // Sort your records and whatnot as if you would with normal records.
        get_best_record();
    }
    /*
        Do the rest as you would with normal lag compensation.
        The normal forward track limit of 200ms does not exist here.
        This is because we will be shooting our shots at the moment that the player is where they are.
        The server will register our shot when the enemy stops choking and it runs hitscan on the choked ticks.
        Our code will not work without this since that would be like backtracking without backtracking, it won't magically work.
    */
}
Thank
 
Top