[zaneATAT]

imagine bob is manual right, when he peaks you, he's gonna peak you left, bcs why would he peak his real?
in that case, his velocity direction is oppsite to his head direction
after we captured lastmove lby and confirmed it was oppsite to his movement direction
if he stops moving or starts fakewalking, we can confidently assume he's still on his lastmove (because again, he doesnt want to peak his real)

        if (record->m_fake_walk && data->m_moved || previous && data->m_moved && data->m_move_data.m_sim_time > 0.f) {

            float velocity_yaw = math::NormalizeYaw(math::rad_to_deg(std::atan2(data->m_move_data.m_velocity.y, data->m_move_data.m_velocity.x)));

            float move_diff = std::abs(math::AngleDiff(velocity_yaw, data->m_move_data.m_body));

            record->m_lastmove_oppsite_to_move_dir = (move_diff > 140.f && move_diff < 200.f);; // i don't think this can ever go above 180 but just in case

                if (record->m_lastmove_oppsite_to_move_dir) {

                    g_notify.add(tfm::format("opposite move detected velocity (diff: %.1f)", move_diff)); // 180 means fully oppsite to the move direction, 0 means the same, 90 means they're moving forward/backward (assuming their lastmove was sideways)

                }

        }


        if (record->m_lastmove_oppsite_to_move_dir && data->m_move_data.m_sim_time > 0.f) {

            record->m_eye_angles.y = data->m_move_data.m_body;

            record->m_mode = Modes::RESOLVE_LASTMOVE;

            record->m_resolver_mode = "S:OppsiteVel";

            return;

        }

you should add an additional check to fakewalkers if their movement direction is STILL oppsite to their lastmove lby, i didn't do it out of laziness

i've tested this on a lan server with 2 monitors and 2 accounts, works perfectly
feel free to suggest improvements

also i was told this idea isn't original but i've came up with it myself and i don't see any public cheats using it


^ cringe message ik

i made this long time ago but didn't release because in-complete
the issue it has is if the player changed direction while he was fake-walking or standing, this would make you miss 100% of the time, while i've never seen anyone who does this behaviour, it's still possible

here's how i'd fix that issue (im too lazy to code and test now i don't care about this)

track last 3 lby angles of player, if they all equal each other, we label him as constant lby breakerthen once he goes into oppsitevel resolver, log his first lby (0.22s after resolver mode is active), i say this because he (probably) won't have time to manually change directionif the 2nd lby update happend (0.22 + 1.1s after this mode was active) and it's different than the 1st lby, that means he manually changed directiondrawbacks of this is that you wait a long time to confirm your resolver is correct and would only work on people who have static lby breaker delta

there are better methods sure, but this deserves being looked into.

 

[zaneATAT]

    if ((pPrevious && data.IsValidFloat(data.m_flLastMovingTime))) {
        float flVelocityYaw = Math::AngleNormalize(RAD2DEG(std::atan2(data.m_vecLastVelocity.y, data.m_vecLastVelocity.x)));
        float flMoveDiff = fabsf(Math::AngleDiff(flVelocityYaw, data.m_flLastMovingBody));
        pRecord->m_bLastMoveOppositeToMoveDir = (flMoveDiff > 140.f && flMoveDiff < 200.f);
    }

    static float flLastOppositeVelocityTime = 0.f;
    static float flPreviousLBY = 0.f;
    float flCurrentTime = g_pGlobalVars->curtime;

    if (data.IsValidFloat(data.m_flLastMovingTime) &&
        pRecord->m_bLastMoveOppositeToMoveDir) {
        pRecord->m_angEyeAngles.y = data.m_flLastMovingBody;
        pRecord->m_iResolverType = 20;
        pRecord->m_szResolver = XorStr("opposite velocity");
        pRecord->m_bIsResolved = true;
        pRecord->m_eConfidence = EConfidence::CONF_HIGH;
        // first time using this mode
        if (flLastOppositeVelocityTime == 0.f) {
            flLastOppositeVelocityTime = flCurrentTime;
            flPreviousLBY = pRecord->m_flLowerBodyYawTarget;
        }

you can also set confidence to very high if (flCurrentTime - flLastOppositeVelocityTime < 0.21f) and medium otherwise

also this will probably be less-effective as time goes on because people will be making antiaims to counter it now that method is public

PS: join the csgo modding discord

You must be registered for see links

PS 2: you may wanna decrease the angle range, from my testing on alt i saw that 140 degrees was the minimum value, but the more you decrease the better

you should also pair this with angle validation, if prev lby != lby and lby diff from lastmove < 35.0f, it's probably not real angle as lby wouldn't have updated if the delta was actually less than 35

PS 3: can be used as a reference angle to get their lby breaker delta

Lby - lastmove = lbydelta

Eye angles = lby - lbydelta

And to confirm we have non hallucinated angles we can do

bool isResolved = eye angles + lby delta == lby <- where this lby is newer than the one we used to compute values

^ this is just psuedocode of my thoughts, everything needs testing, just putting this out there incase some passionate smart fella wants to do something about it

but no gatekeep plz (;

 

[bitcoinbandit]

 

[legacypaster]

yo thx this is p as oh no

 

[JessePinkman231]

imagine bob is manual right, when he peaks you, he's gonna peak you left, bcs why would he peak his real?
in that case, his velocity direction is oppsite to his head direction
after we captured lastmove lby and confirmed it was oppsite to his movement direction
if he stops moving or starts fakewalking, we can confidently assume he's still on his lastmove (because again, he doesnt want to peak his real)

        if (record->m_fake_walk && data->m_moved || previous && data->m_moved && data->m_move_data.m_sim_time > 0.f) {

            float velocity_yaw = math::NormalizeYaw(math::rad_to_deg(std::atan2(data->m_move_data.m_velocity.y, data->m_move_data.m_velocity.x)));

            float move_diff = std::abs(math::AngleDiff(velocity_yaw, data->m_move_data.m_body));

            record->m_lastmove_oppsite_to_move_dir = (move_diff > 140.f && move_diff < 200.f);; // i don't think this can ever go above 180 but just in case

                if (record->m_lastmove_oppsite_to_move_dir) {

                    g_notify.add(tfm::format("opposite move detected velocity (diff: %.1f)", move_diff)); // 180 means fully oppsite to the move direction, 0 means the same, 90 means they're moving forward/backward (assuming their lastmove was sideways)

                }

        }


        if (record->m_lastmove_oppsite_to_move_dir && data->m_move_data.m_sim_time > 0.f) {

            record->m_eye_angles.y = data->m_move_data.m_body;

            record->m_mode = Modes::RESOLVE_LASTMOVE;

            record->m_resolver_mode = "S:OppsiteVel";

            return;

        }

you should add an additional check to fakewalkers if their movement direction is STILL oppsite to their lastmove lby, i didn't do it out of laziness

i've tested this on a lan server with 2 monitors and 2 accounts, works perfectly
feel free to suggest improvements

also i was told this idea isn't original but i've came up with it myself and i don't see any public cheats using it


^ cringe message ik

i made this long time ago but didn't release because in-complete
the issue it has is if the player changed direction while he was fake-walking or standing, this would make you miss 100% of the time, while i've never seen anyone who does this behaviour, it's still possible

here's how i'd fix that issue (im too lazy to code and test now i don't care about this)

track last 3 lby angles of player, if they all equal each other, we label him as constant lby breakerthen once he goes into oppsitevel resolver, log his first lby (0.22s after resolver mode is active), i say this because he (probably) won't have time to manually change directionif the 2nd lby update happend (0.22 + 1.1s after this mode was active) and it's different than the 1st lby, that means he manually changed directiondrawbacks of this is that you wait a long time to confirm your resolver is correct and would only work on people who have static lby breaker delta

there are better methods sure, but this deserves being looked into.

ZANE my goat tahnk u will paste now

 

[austino]

yo thx this is p as oh no

 

[bitcoinbandit]

as a jobless 50 year old man this has changed my life

 

[052]

persona what

 

[robert112]

p100!!

 

[052]

p100!!

this is not p100