Storm/Move.hpp

47 lines
1.1 KiB
C++
Raw Permalink Normal View History

2024-10-07 03:45:39 +08:00
__int32 Extra_Commands;
void* Original_Move_Caller;
2024-10-07 03:45:39 +08:00
void Redirected_Move(float Unknown_Parameter, __int8 Final)
{
prediction redesignment (details in description) my plan to use constant buffering to instantize actions (as healing, reviving) turned out ill-fated: - many things are using server relative timing: rock stuns, lagcompensation and many of interactables (they're all getting delayed by 150*(1/30) seconds) - there's always undefined behaviour no matter whether i'm constantly buffering or periodically - implementing logic that prevents buffering on when you're about to get hit by rock or to use something would adjust weapon timings (they're all getting delayed by 150*(1/30) seconds) thus i've removed some of things i've worked on (as exploits, viewmodel timing correction) mostly same thing about extra commands up to 21 while exploiting (my old trick doesn't works anymore): it's either undefined behaviour or feature cuttage but on good note: - prediction got hardened against timing fluctations - prediction now respects network timing updates - speedhacking issued undefined behaviour is significantly mitigated (not completely but i'd prefer to not bloat my code over such rare cases) i'll be working on features from now, here's potential list (anything that involves guessing is very low priority): rock prediction (involves guessing, it's not lagcompensated) tongue cutter (involves guessing) tongue aimbot/triggerbot (i've actually forgot to adjust lagcompensation for it but i'm not playing versus anyway) animation cycles prediction (involves guessing, u-rates are synced already so it's just about latency adjustments now) minigun aimbot (i'd like to work on it but just one thing that it's angle is limited thus impossibility to compensate spread accurately ruins it for me) visual improvements (such as visually removing m_duckUntilOnGround)
2024-10-24 17:39:44 +08:00
using Run_Prediction_Type = void(__cdecl*)();
2024-10-07 03:45:39 +08:00
if (*(void**)((unsigned __int32)Client_Module + 7498712) != nullptr)
{
Redirected_Read_Packets(Final);
prediction redesignment (details in description) my plan to use constant buffering to instantize actions (as healing, reviving) turned out ill-fated: - many things are using server relative timing: rock stuns, lagcompensation and many of interactables (they're all getting delayed by 150*(1/30) seconds) - there's always undefined behaviour no matter whether i'm constantly buffering or periodically - implementing logic that prevents buffering on when you're about to get hit by rock or to use something would adjust weapon timings (they're all getting delayed by 150*(1/30) seconds) thus i've removed some of things i've worked on (as exploits, viewmodel timing correction) mostly same thing about extra commands up to 21 while exploiting (my old trick doesn't works anymore): it's either undefined behaviour or feature cuttage but on good note: - prediction got hardened against timing fluctations - prediction now respects network timing updates - speedhacking issued undefined behaviour is significantly mitigated (not completely but i'd prefer to not bloat my code over such rare cases) i'll be working on features from now, here's potential list (anything that involves guessing is very low priority): rock prediction (involves guessing, it's not lagcompensated) tongue cutter (involves guessing) tongue aimbot/triggerbot (i've actually forgot to adjust lagcompensation for it but i'm not playing versus anyway) animation cycles prediction (involves guessing, u-rates are synced already so it's just about latency adjustments now) minigun aimbot (i'd like to work on it but just one thing that it's angle is limited thus impossibility to compensate spread accurately ruins it for me) visual improvements (such as visually removing m_duckUntilOnGround)
2024-10-24 17:39:44 +08:00
Run_Prediction_Type((unsigned __int32)Engine_Module + 527776)();
using Update_Animations_Type = void(__cdecl*)();
Update_Animations_Type((unsigned __int32)Client_Module + 205296)();
using Fire_Events_Type = void(__cdecl*)();
Fire_Events_Type((unsigned __int32)Engine_Module + 521648)();
Update_Animation_Time = (*(Global_Variables_Structure**)((unsigned __int32)Client_Module + 7096744))->Current_Time;
Update_Animation_Type = 1;
Update_Animations_Type((unsigned __int32)Client_Module + 205296)();
Update_Animation_Type = 0;
2024-10-07 03:45:39 +08:00
}
Extra_Commands = -1;
Move_Label:
{
(decltype(&Redirected_Move)(Original_Move_Caller))(Unknown_Parameter, Final);
prediction redesignment (details in description) my plan to use constant buffering to instantize actions (as healing, reviving) turned out ill-fated: - many things are using server relative timing: rock stuns, lagcompensation and many of interactables (they're all getting delayed by 150*(1/30) seconds) - there's always undefined behaviour no matter whether i'm constantly buffering or periodically - implementing logic that prevents buffering on when you're about to get hit by rock or to use something would adjust weapon timings (they're all getting delayed by 150*(1/30) seconds) thus i've removed some of things i've worked on (as exploits, viewmodel timing correction) mostly same thing about extra commands up to 21 while exploiting (my old trick doesn't works anymore): it's either undefined behaviour or feature cuttage but on good note: - prediction got hardened against timing fluctations - prediction now respects network timing updates - speedhacking issued undefined behaviour is significantly mitigated (not completely but i'd prefer to not bloat my code over such rare cases) i'll be working on features from now, here's potential list (anything that involves guessing is very low priority): rock prediction (involves guessing, it's not lagcompensated) tongue cutter (involves guessing) tongue aimbot/triggerbot (i've actually forgot to adjust lagcompensation for it but i'm not playing versus anyway) animation cycles prediction (involves guessing, u-rates are synced already so it's just about latency adjustments now) minigun aimbot (i'd like to work on it but just one thing that it's angle is limited thus impossibility to compensate spread accurately ruins it for me) visual improvements (such as visually removing m_duckUntilOnGround)
2024-10-24 17:39:44 +08:00
Run_Prediction_Type((unsigned __int32)Engine_Module + 527776)();
2024-10-07 03:45:39 +08:00
if (Extra_Commands > 0)
{
Extra_Commands -= 1;
goto Move_Label;
}
}
}