[Drunken F00l]

I'm looking for a way to hook all entities on spawn. I need this so that I am able to keep track of all key/value pairs on all entities. I've tried two methods, and both work, I'm just not exactly happy with either method.

The first method was to manually detour the CreateEntityByName function in the server dll. The detour would call my function after the networkable was created. This worked, but only on Windows. It would have worked for Linux I think, but I was too lazy to rewrite the detour I made for it.

The second method is to grab the EntityFactoryDictionary from the server and iterate through all entity types, create one of each and then VP hook them (nice SourceHook patch btw). This works as well, but doesn't seem very efficient.

My idea for a third method is to completely overwrite the CreateEntityByName function with one that just calls my own function. Since my plugin is aware of the entity factory dictionary, it can spawn the entity itself and then vp hook it if necessary right there.

I'm looking for everyone's opinion on all three of these methods. I'm also interested in knowing if anybody has any other ideas.

Thanks!

[API]

Do you mean you want to hook RoundRespawn?

[Drunken F00l]

No, this isn't necessarily for CSS.

I'm hooking KeyValue as well as some others on every entity.

[API]

Ah, you mean CBE::Spawn()
I believe you can sigscan for CBE:Spawn(), or you may be able to just do it through MMSource, and hook that void*

[Drunken F00l]

One of us doesn't understand the other. Are you telling me to just call or hook CBaseEntity::Spawn()?

I can spawn entities and hook vfuncs just fine. I was more interested in getting opinions on those three methods that I mentioned.

Each method is one that will allow me to hook the entity before any function is called on it. I need this so that I am able to track all of its key/value pairs.

[API]

Oh, sorry, didn't read the full post. I would not suggest writing your own function, so I don't really like the #3 approach. The #2 seems to be okay, as long as the hooks are safe and there is no crashing or memory problems. #1 doesn't really scratch the surface on my type of knowledge, so I wouldn't be able to give an opinion on that.

[Drunken F00l]

Well thanks, those two opinions tend to match my own.

The second method works fine, but it adds a second or so to the map loading time. It also causes crashes on creating some entities, so I had to create an exception list.

I'm kind of reserved about totally wiping out the CreateEntiyByName function with my own for compatibility issues.

And all I mean by the first method is altering the CreateEntityByName function in memory so that instead of, for example, step 1, step 2, step 3, the function will now do step 1, step 2, call my function, step 3. I don't like this for the same reason I don't like the third one.

[BAILOPAN]

I personally prefer to detour things like this, so I'd go with #1, if nothing else but purely for efficiency. Patching it out entirely would definitely be more of a compatibility stretch. It's probably very easy to detour since I think it's static, and since it doesn't change much from mod to mod, it'd probably be trivial to maintain a list of supported mods and how many bytes you need to patch/restore to be safe.

If you do go with hooking, of course, I highly recommend using SourceHook; even if you don't want to use MM:S, it can be embedded as its own third-party library and it will (hopefully) make your life a lot easier :]

[Drunken F00l]

Thanks bail! I do use SourceHook and it does make things easier. I was looking at Lance's CDetour class, but does it allow me to detour post-function rather than pre-? I haven't really looked into it much so I'm not sure if CDetour would be a good idea. Also, there's that linux compatibility issue showing up again with CDetour.

[BAILOPAN]

It would probably be easier to write your own detour instead of Lance's, since you have kind of a specialized request. If you're trying to go Post instead of Pre, that complicates things a bit. You'd need to do the patch at the end of the function instead which is always trickier.

Actually, one really hacky possibility is to change the return address on the stack with a pre-detour, then when the function returns, it returns to a second post detour, where you can do your thing and then jump to the original return address.

Another post detour possibility which is probably much easier is making a detour that calls the original (calling the original bytes, then jumping onward), and then returning back and calling your post function.

I'm kind of tired so I might have gotten the details wrong.