Quote:
Originally Posted by mooman2
Ok, I just tried again with passing the index in manually and it still didn't work.
On the mod Zombie Master, I tried this originally and it crashed whenever I shot a zombie:
Code:
SH_DECL_MANUALHOOK2(BecomeRagdoll_hook, 0, 0, 0, bool, CTakeDamageInfo const&, Vector const&);
SH_MANUALHOOK_RECONFIGURE(BecomeRagdoll_hook, idxBecomeRagdoll, 0, 0);
BecomeRagdollHook = SH_ADD_MANUALDVPHOOK(BecomeRagdoll_hook, vtblCNPC_BaseZombie, SH_STATIC(BecomeRagdoll_handler), false);
If it also interests you, I tried hooking CBasePlayer::Weapon_Equip using what you told me to do in the latest post and that also crashed whenever I shot a zombie.
EDIT: It could be a problem with sourcehook backwards compatability since I'm also using deprecated methods to hook stuff DispatchEffect.
RE-EDIT: Ok, I definitely think it's a problem with sourcehook backwards compatability. CentOS server is running MM:S 1.5. I add a plugin that uses 1.4 methods to hook ITempEntsSystem:: DispatchEffect. It crashes whenever I shoot something that uses DispatchEffect. Now I comment out the DispatchEffect hooks and reload the plugin and it doesn't crash.
YET ANOTHER EDIT: I figured out its not the hooks causing the crash, but deprecated callclasses which I think are supposed to still be backwards-compatible?
EDIT #2415: after fixing the crash and trying a lot of random stuff, I still can't get DVPHOOK to work. Does it really not need a pointer to an already existing instance?
|
Whoa, that doesn't sound healhty.
I'll try to reproduce your situation here, so I'll have to ask some questions in order to get a precise picture of what is going on
Are you running only this plugin? Or also other plugins (which hook the function in question?)
Does your plugin use deprecated callclasses (SH_GET_CALLCLASS and stuff)? And then SH_CALL on them crashes? Do you do this when there is a hook on the function? Also, is the plugin which causes the callclass-related crashes compiled against 1.5 or 1.4 headers? Thanks
EDIT: Does it crash if you have a plugin running which "uses 1.4 methods to hook DispatchEffect"? Was that plugin compiled against the 1.4 SDK? Or was it recompiled? (it is important that not-recompiled plugins don't crash) Or does it only crash if you have BOTH your new plugin and an old plugin running?
It could be possible that I've made some error when writing those source backwards compat quirks.... I'm not sure yet, I'll have to test it.
However it worries me that you can't get VP hooks working :-O
There are two kinds of VP hooks:
normal VP hooks expect a pointer to an already existing instance (internally, they add the thispointeroffset and vtable offset to the this pointer, then dereference this computer "vtable pointer pointer" and use that as a direct VP hook. the thispointeroffset and vtable offset are either given manually (manual hook) or are discovered automatically from a member function pointer (non-manual hook) ).
direct VP hooks expect a pointer to the vtable. They only do vtable[vtblidx] in order to refer to the virtual function pointer then. This means that vtblidx is not the offset from the vtable beginning, but the offset / sizeof(void*), but you probably know that anyway.
/* It is important that the function/"method" you want to hook is called through this vtable (ie. it is possible that you hook a function in one vtable; but a derived class has its own vtable and thus when someone calls baseClassPointer->Function() and baseClassPointer is in fact a pointer to a derived class which overrides one or more functions from the base class (and it doesn't matter if the function is the function you are hooking or not) your hook will not be called). But you are probably doing that correctly as BaseZombie doesn't appear to be the lowest base class having a virtual BecomeRagdoll member. */ (EDIT2: I took a look at the SDK and found out that what I wrote here was unimportant for this discussion)
The source-level backwards compatibility callclasses are only template hacks so that old plugins compile without changing code; basically SH_GET_CALLCLASS stores the this pointer in some fake callclass instance and then SH_CALL extracts it again. So it should be the same as calling SH_CALL with the this pointer directly unless I've made some fault on the way.
Sorry for my confusion, it's early in the morning ;)
__________________