[c0ldfyr3]

I dont hook it at all, I created the definition to try calling the function, but the following function works fine..

void CBaseAnimating_Teleport( CBaseAnimating *pThisPtr, const Vector *newPosition, const QAngle *newAngles, const Vector *newVelocity )
{
	void **this_ptr = *(void ***)&pThisPtr;
	void **vtable = *(void ***)pThisPtr;
	void *func = vtable[ VFUNC_OFFSET_TELEPORT ]; 

	union {bool (VfuncEmptyClass::*mfpnew)( const Vector *, const QAngle *, const Vector * );
	#ifndef __linux__
		void *addr;	} u; 	u.addr = func;
	#else 
			struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
	#endif

	(void) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)( newPosition, newAngles, newVelocity );
}

EDIT: Forgot to mention..

#define VFUNC_OFFSET_TELEPORT CBASEANIMATING_TELEPORT

[PM]

I don't see what's going on, so I have more questions if you don't mind.

From the quoted call stack I'm assuming that you're using MSVC. Which version?

Is there any other hook on that entity?

> baadf00d() zombie_mm.dll!SourceHook::MExecutableClass3<v oid,Vector const *,QAngle const *,Vector const *>:perator()(const Vector * p1=0x0012e18c, const QAngle * p2=0x0012e198, const Vector * p3=0x0012e180) Line 3452 C++ zombie_mm.dll!ZombiePlugin::Slap(int iPlayer=1148846080) Line 2682 C++

Please double-click on the second frame (MExecutableClass3's operator()) and switch to the "Locals" variables view. When you expand 'this', you should see the vtbl index. Is this index correct? (it should be the entry's index; ie. 0 for the first entry, 1 for the second one, 2 for the third, ...).
Under 'u' you should see addr. What is this set to? 0xbaadf00d? Is adjustedthisptr the this pointer you passed to SH_GET_MCALLCLASS ?

Thanks.

[BAILOPAN]

Originally Posted by c0ldfyr3 zombie_mm.dll!ZombiePlugin::Slap(int iPlayer=1148846080) Line 2682 C++

what. btw that's 0x447A0000, or 1000.0 as a float. stack corruption

[c0ldfyr3]

Originally Posted by PM I don't see what's going on, so I have more questions if you don't mind. From the quoted call stack I'm assuming that you're using MSVC. Which version? Is there any other hook on that entity? > baadf00d() zombie_mm.dll!SourceHook::MExecutableClass3<v oid,Vector const *,QAngle const *,Vector const *>:perator()(const Vector * p1=0x0012e18c, const QAngle * p2=0x0012e198, const Vector * p3=0x0012e180) Line 3452 C++ zombie_mm.dll!ZombiePlugin::Slap(int iPlayer=1148846080) Line 2682 C++ Please double-click on the second frame (MExecutableClass3's operator()) and switch to the "Locals" variables view. When you expand 'this', you should see the vtbl index. Is this index correct? (it should be the entry's index; ie. 0 for the first entry, 1 for the second one, 2 for the third, ...). Under 'u' you should see addr. What is this set to? 0xbaadf00d? Is adjustedthisptr the this pointer you passed to SH_GET_MCALLCLASS ? Thanks.

MSVC 2003. And yes there are about ten manual hooks on that entity, all which work. Teleport is not hooked though.
Couldnt find 'u' but ....

m_CC=0x0e1e8d78
m_ThisPtrOffs	0
m_VtblIdx	92
m_VtblOffs	0

Looks better.

When I print %p of the CallClass just before I fire the macro, its:
CallClass: 0x0e1e8d78

EDIT: Its a big project but I can send it to you and tell you where Im testing this call...

EDIT2: + u {mfpnew=0xbaadf00d addr=0xbaadf00d } SourceHook::MExecutableClass3<void,Vector const *,QAngle const *,Vector const *>:)::__l2::__unnamed

EDIT3: - adjustedthisptr 0x10316160 "Tˆ?"" char * -- 84 'T'

Memory at m_CC: http://www.c0ld.net/mem.gif

[PM]

I think I've found the cause for this one. Are you doing any hooks with higher vtable indices? If yes, that's probably why. SH's callclass implementation uses assumes that a vector of pointers auto-inits its elements to NULL; our CVector doesn't do that and I guess that on your platform it'll get auto-initalised to 0xbaadf00d by MSVC to tell the programmer that something went wrong. It's actually one of the first things that came to my mind but I forgot about it instantly because I thought I used STL's vector (BAIL was so kind to point out that we use our own CVector).

EDIT: That said, I expect to fix it by tomorrow.

[c0ldfyr3]

Ya the hooks go from 5 to 350 so this is probably the problem.

Thats another pound of hair you owe me :\

[c0ldfyr3]

Also, another question before I go changing everything over to this method.

As I already have most of the functions mapped out with unions, do you think its worth converting to this method?

It seems this new method has more over head associated with it...

[PM]

If you always do GET_CALLCLASS / SH_MCALL / release callclass, it _will_ be a lot more overhead, yes. You should store the callclass and use it, and release it when you don't need it anymore.

Even if you do that there's still some overhead (two indirect function calls and a conditional jump) when using this method. That's the prize you have to pay to make sure that any SH hooks are bypassed. If you don't care about this, you can keep using union hacks of course.

If you mean overhead from the compile time side of things, it probably does, yes. Because of the many templates and overloading and stuff like that.


Anyway I think I've fixed this bug, the fix is in CVS. Initally I wanted to compile a Win32 sourcemm binary for you, but I've found out that I don't have the hl2sdk; so please compile it yourself or ask BAIL or something =P

Thanks,
PM

[API]

Awesome PM! Thanks for the example

[c0ldfyr3]

I was just getting the call class localy to make sure it was working.

The minute you posted this I added a new variable to my player class which is found on ClientPutInServer, pCallClass =)