Engine Prediction in Gmod

[podato]

Hello, sorry if Im a bit noobish, but how do you get m_pCurrentCommand ?

[eth0s]

Hello, sorry if Im a bit noobish, but how do you get m_pCurrentCommand ?

Check RunCommand in IDA
https://******.com/ValveSoftware/sou...ction.cpp#L831
https://******.com/ValveSoftware/sou...ction.cpp#L732
StartCommand and FinishCommand are inline

Edit:
localplayer + 0x2498

sub_1B2F70+13    8B 7D 0C                          mov     edi, [ebp+cmd]
sub_1B2F70+16    8B 75 08                          mov     esi, [ebp+player]
sub_1B2F70+19    57                                push    edi
sub_1B2F70+1A    89 BE 98 24 00 00                 mov     [esi+2498h], edi

[JayFromSubway]

You will be using outdated data for your aimbot/bhop/garbage cheat and therefore you'll lose in hvh.

[eth0s]

What?


















//////////////////////

[IAmPhage]

You're asking about bypassing a BHop check, I don't think you have any kind of valid input here.

[JayFromSubway]

You're asking about bypassing a BHop check, I don't think you have any kind of valid input here.

Just because I am learning Lua doesn't mean that my input is not valid. It's pretty obvious that the delay is negligible and you should be focusing on optimizing the efficiency, performance, and way you go about your code to get a better result...not that I'd know how to do any of that

[eth0s]

Just because I am learning Lua doesn't mean that my input is not valid. It's pretty obvious that the delay is negligible and you should be focusing on optimizing the efficiency, performance, and way you go about your code to get a better result...not that I'd know how to do any of that

Try moving sideways whilst aimbotting, since you don't realize the difference.

[IAmPhage]

Just because I am learning Lua doesn't mean that my input is not valid. It's pretty obvious that the delay is negligible and you should be focusing on optimizing the efficiency, performance, and way you go about your code to get a better result...not that I'd know how to do any of that

I don't understand why I even bother with you retards anymore. Go read the SDK man, the LocalPlayer is NOT predicted when you call createmove. Your shitty velocity prediction will miss and you will fail.

This is the callstack for CreateMove (credits: Casual Hacker)

The callstack for the engine creating user cmds looks like this:

engine.dll!CL_Move which calls
client.dll!CHLClient::CreateMove which calls
client.dll!CInput::CreateMove which calls
client.dll!ClientModeShared::CreateMove which calls
client.dll!C_BasePlayer::CreateMove which calls your active weapon's
client.dll!C_BaseCombatWeapon::CreateMove...

So! Which place do you want to hook? Each of those functions executes some logic then delegates further processing to the next layer. Based on this information you can decide the best place to put your CreateMove hook.

Note that when you hook, your code runs either *before* or *after* the hooked function, not in the middle.

Let's investigate each layer in detail:

CL_Move: This is inside engine.dll, the function is not virtual and not easily hooked. Sending your usercmd is done inside this function by calling CL_SendMove. All this makes it a very undesired place to hook.

CHLClient::CreateMove: Remember what I said about hooks only running before or after? As you can see it has a critical section in it as well as code that allows us to safely access bones... If you hook here you get none of these guarantees. Bad place to hook.

CInput::CreateMove: Much better already, however among other things it verifies the usercmd. If you hook here you have to do this manually yourself. It's fine to hook here but we can do better. EDIT: Due to an optimization called 'devirtualization' you cannot hook this with a VMT hook...

ClientModeShared::CreateMove: Here we have the fabled clientmode createmove. Perfect for hooking, just one caveat: if you look at how it's invoked in CInput::CreateMove you can see what it does with its return value. You should call SetViewAngles youself first, then always return false or your silent aim won't work. It is also called from CInput::ExtraMouseSample which is undesired, but you can filter those calls by checking if ucmd->command_number != 0.

C_BasePlayer::CreateMove: Hooking here is a bit harder as your local player instance is destroyed and recreated on every level join. Finding the CreateMove virtual index is also an extra chore. All in all client mode is a better choice.

C_BaseCombatWeapon::CreateMove: Now you're just making things hard for no reason, go with client mode instead.

I hope this helped you understand why people made these choices.

If we also take a look at valve's wonderful wiki, we can see that the prediction code gets called after our CreateMove calls being ran. So as I said before, you are inaccurate and your shitty velocity prediction will not save you.

Oh PS: Your entire argument about focusing on efficiency is invalid because my menu calls are more expensive than engine prediction.