[PM]

Uh I don't know, I've never used it with the HL2SDK.
If it's that difficult, it will be probably easier to compile for linux and run valgrind ;)

EDIT: Maybe this thread has links to good tools too:
http://www.gamedev.net/community/for...opic_id=328601

[CrimsonGT]

After numerous problems getting any of the debugging tools to work (I dont think its them, I think its me) I just started going through commenting stuff out and recompiling and testing. I figured out what seems to be corrupting it, and its my detour on FileWeaponInfo_t::parse() which is called before the first map actually loads or anything. This is the function that loads in all the data from the CTX files, but I overwrite the necessary stuff here as a median to allow me to not have to worry about the extra file modifications.

It all seems to work fine when im setting ints and floats, but I think something is corrupting when I set strings for some reason. Ive had countless problems setting ammo types, models, etc. They all work fine in release mode, but apparently it doesnt like doing it for some reason. Im guessing the same tools that im having so much trouble with might be able to help me with this, but it just doesnt make a lot of sense as to why its screwing up.

On another note, huge thanks you PM and Bailopan for the help, been very insightful

[PM]

Are those c-style strings or some wrapper class instances? How do you set the strings?
Some code might help

Overwriting strings tends to be error-prone, you need to watch out for null terminators, not overwrite more than the memory that has been allocated, update some size member variable if you are dealing with a wrapper class, know how memory has been allocated if you are reallocating it, etc.

[CrimsonGT]

Good point, and yeah sorry about that, was dead tired when I posted. Heres an example. The strings are commented out for the time being for all of the weapons as that causes the heap corruption.

PHP Code:

DETOUR_DECL_MEMBER2(FileWeaponInfoParse, void, KeyValues *, pKeyValuesData, const char *, szWeaponName)
{
    /* Rocket Launcher */
    if(StrEqual(szWeaponName, "tf_weapon_rocketlauncher"))
    {
        pKeyValuesData->SetInt("Damage", 100);
        pKeyValuesData->SetInt("Range", 0);
        pKeyValuesData->SetInt("BulletsPerShot", 1);
        pKeyValuesData->SetFloat("Spread", 0.0);
        pKeyValuesData->SetFloat("PunchAngle", 0.0);
        pKeyValuesData->SetFloat("TimeFireDelay", 0.8);
        pKeyValuesData->SetFloat("TimeIdle", 0.8);
        pKeyValuesData->SetFloat("TimeIdleEmpty", 0.8);
        pKeyValuesData->SetFloat("TimeReloadStart", 0.1);
        pKeyValuesData->SetFloat("TimeReload", 0.83);

        //pKeyValuesData->SetString("ProjectileType", "projectile_rocket");
        //pKeyValuesData->SetString("primary_ammo", "TF_AMMO_PRIMARY");

        pKeyValuesData->SetInt("clip_size", 40);
        pKeyValuesData->SetInt("default_clip", 40);
    }

    DETOUR_MEMBER_CALL(FileWeaponInfoParse)(pKeyValuesData, szWeaponName);
} 


[PM]

Are you linking to some tier1 library or compiling keyvalues.cpp?

I could imagine that if you have your own instance of the keyvalues.cpp code, the operator new[] your SetString() calls uses a different heap manager then the delete[] which the engine or whatever calls when finally destroying the KeyValues instance. Might be wrong though.

[CrimsonGT]

I have...
"$(HL2SDKOB)\lib\public\tier1.lib"
defined in my linker settings. And when I right click ->SetString() and go to definition it takes me to KeyValues.h so im assuming both.

What exactly should I do? Remove the tier1.lib from the linker addition includes?

[PM]

That's weird, I think that it should be okay if you're linking to the SDK's tier1.lib file. Then you're most likely using valve's code for the keyvalues stuff (you can be sure by stepping into the SetString call with a debugger and seeing where it takes you).

[CrimsonGT]

Alright, I got the sig for KeyValues::SetString and used that instead and it worked perfectly. Is this something that could be fixed on ->SetString or should I just keep using it this way?

[PM]

That method sounds pretty good. Note that if you're using SetName you apparently don't need to sigscan that as that allocates memory over a global KeyValuesSystem thing or something. I'm not sure

Another solution would be manually overriding operator new [] and delete [] and all that functions to do the same thing Valve's internal allocator does, either through sigscanning (though that would be much more work than the current method and not give you any real advantges) or maybe trying to use memoverride.cpp and memdbgon.h (both tier0) as valve does (though it might also be a lot of work to get that to compile and even then I don't know if it will help).

[CrimsonGT]

Yup, ill stick with this method

Thank you for all the help, I think I would still be twiddling my thumbs otherwise.