that guy had a clever idea. However, if I understand well, as soon as the interface changes a bit, he's left to rearrange all his function pointers in the vtable. I'm not sure it's very practical. It doesn't seem to bother the AMX guys though, as they are used to get/set info where they shouldn't, such as in HL1 edict's private data...
RACC home - Bots-United: beer, babies & bots (especially the latter) "Learn to think by yourself, else others will do it for you."
Well, you can hook whatever functions you need, and have the ones you don't bypass it. You can also make it so that if new functions come around, they could also bypass it.
No, you don't get it. The order in which the functions are may be arranged everytime a new interface version is defined. Contrarily to HL1. That's the purpose of this "interface factory" to ensure consistency between DLLs using different versions of the interface. Unless he cares about the version of the interface he hooks onto (but I don't see him doing that), he'll be in big trouble at any minor revision of the interface.
RACC home - Bots-United: beer, babies & bots (especially the latter) "Learn to think by yourself, else others will do it for you."
i thought about an easier way using the plugin interface. Technically if we chain the plugin, Is it not possible too dump any information between the server -> plugin interface like weapon bit id`s (really needed at the moment).
Plugins in Half-Life2 are implemented similar to the way they are in Metamod. The plugin does not sit between the engine and the game DLL.
In Half-Life2, the engine can call plugin functions when (after) game DLL functions are called. It's more of a branch off from the main engine/gameDLL connection than it is a connection between them.
For example, the engine calls the game DLL GameFrame() function, then when the game DLL returns back to the engine, the engine calls it for plugin A, then plugin B, then plugin C, like this...
engine->GameDLL::GameFrame()
<- GameDLL::GameFrame() returns back to the engine
engine->PluginA::GameFrame()
<- PluginA::GameFrame() returns back to then engine
engine->PluginB::GameFrame()
<- PluginB::GameFrame() returns back to the engine
botman what i mean is engine call`s the hook plugin, then hook plugin calls the real plugin.
Have a hook dll that sit`s in between dumping various information on engine functions passed to the real plugin.
edit
found an intresting hooking library for injecting your own code into a remote process windows only here