The new buffer/vector was freed before the old function was called with the new parameters
or the return value could be used by the called. This caused undefined behavior which seemed
to be fine before, where free didn't change the user-payload. free does change the user data now,
causing the changed values to be garbage.
Wait until the next frame before deleting the newly allocated buffers/vectors, so the original code had a chance
to use the live pointers. AddFrameAction might be a bad choice if our hook happens before the game ticks, but
we can tackle that problem when it happens ;)
Callee cleans the stack and first two arguments are passed in registers ecx and edx.
You could emulate this by choosing stdcall and setting the custom_registers on the arguments manually, but this is easier.
When the this pointer is set to ThisPointer_CBaseEntity and the address is null, just return INVALID_ENT_REFERENCE instead of trying to access the pointer.
Floats are always returned in FPU register st0. Since the value in st0 doesn't matter in a pre-hook before the function was executed, don't try to save and restore the value of the FPU stack top for a pre-hook.
Only replace st0 after a post hook.
If the Functions section was parsed before and the gamedata file is loaded again,
the arguments were all added again instead of keeping the old number of arguments.
When removing a plugin's callback from the list of callbacks of a detour
the next callback in the list would be skipped. Don't only check every second callback,
but every single one!
A "Functions" section is parsed in gamedata files that allow you to define the signature of functions including metadata like the calling convention and specifying the register an argument is passed in.
A new native DHookCreateFromConf can be used to setup a hook or detour from one of that function sections in the "Functions" section.
The this pointer was always passed to the plugin callback if the calling convention was a thiscall. Even if the plugin author set the this pointer type to ThisPointer_Ignore.
If a function was optimized to only pass one parameter in a register, but still pass other parameters on the stack, save the registers at the correct offset in the buffer.
The post hook would have cleared the esp value from the return address map, but there seems to be a case where the post hook isn't called, but the function gets called with the same esp again. This is probably just masking a different error :(
If the compiler decided to pass an argument in a register on an internal function instead of pushing it on the stack to save time, allow us to specify the register the parameter is going to be in.
DHookAddParam received another parameter to set the register.
The esp pointer wasn't removed from the map after the function was called and the original return address was retrieved.
If the same function was called again with the same esp this would fail due to there already being an (old) return address associated with the esp.
The custom return value was lost when calling the original function.
Save and restore our own return value, if we're about to call the original function.
Peace-Maker