WoWDb Patchables Issue

[Beowulfe]

Hey guys,

Messing around with a couple of the Patchables and have setup structs for them.

Everything's going great, except for one minor issue that winds up making the code look a little messy.

Namely, some issues with Styx.WoWInternals.WoWDb.Row.

NOTE: To simplify things, I'm going to omit the "Styx.WoWInternals" off of the front of a number of these things, assumes a "using Styx.WoWInternals;" statement.

I've worked out all of the value types in one of the Patchables to the following struct (with variable names removed):

    struct
    {
        UInt32;
        UInt32;

        float;
        float;
        float;

        string;

        UInt64;
        UInt64;
    };

Using this statement (Ignore the typename for the struct, it's not the real name obviously ):

                WoWDb.Row dbRow = dbMain.GetRow(uiIndex);

                if (!dbRow.IsValid)
                    continue;

                SStructFromAbove structNode = dbRow.GetStruct<SStructFromAbove>();

works perfectly, EXCEPT for the string variable. The string comes out either blank or garbled. HOWEVER, the following statement (which should essentially act exactly the same way):

string sSomeString = dbRow.GetField<string>(5);

works perfectly and grabs the string, no problem.

So, I assume the issue in the struct is related to string being a reference type by default, but I'm a C++ programmer, not a "pro" C# coder (though I do know my way around C# pretty well), so I figured it was possible I missed something simple on my end.

Does anyone know if there's anything I can do to fix this myself, and if it's an issue in the GetStruct<> code for WoWDb.Row, is there any chance one of the HB devs could fix it?

Any help is greatly appreciated, thanks.

 

[MaiN]

A 'string' field in .NET is marshalled (by default) like a string pointer (like it should be). When you use GetStruct, Honorbuddy copies over the bytes from WoW into Honorbuddy and marshals the structure to a managed structure. Because the string in WoW, natively, is a "char *", the copied data only contains the string pointer to another process' memory space. Obviously the value points to something else entirely due to it being in our process.
GetField has this inner implementation to handle strings:

if (typeof(T) == typeof(string))
{
    object s = _memory.Read<string>(_memory.Read<uint>(((uint)_address.ToInt32() + (index * 4))));
    return (T)s;
}

That means in your structure you want to do stuff like this:

[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct SomeStruct
{
  public float SomeValue;
  private uint _someStringPtr;

  public string SomeString { get { return ObjectManager.Wow.Read<string>(_someStringPtr); } }
}

 

[Beowulfe]

A 'string' field in .NET is marshalled (by default) like a string pointer (like it should be). When you use GetStruct, Honorbuddy copies over the bytes from WoW into Honorbuddy and marshals the structure to a managed structure. Because the string in WoW, natively, is a "char *", the copied data only contains the string pointer to another process' memory space. Obviously the value points to something else entirely due to it being in our process.
GetField has this inner implementation to handle strings:

if (typeof(T) == typeof(string))
{
    object s = _memory.Read<string>(_memory.Read<uint>(((uint)_address.ToInt32() + (index * 4))));
    return (T)s;
}

That means in your structure you want to do stuff like this:

[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct SomeStruct
{
  public float SomeValue;
  private uint _someStringPtr;

  public string SomeString { get { return ObjectManager.Wow.Read<string>(_someStringPtr); } }
}

Thanks for the help! Appreciate it.

Figured it was something like that - I had tried messing around with string pointers instead (using "unsafe" code), but HB doesn't like compiling plugins using unsafe code and I figured it was a long shot at best. I'm too used to C++, methinks.

Rep++!

 

[Apoc]

Thanks for the help! Appreciate it.

Figured it was something like that - I had tried messing around with string pointers instead (using "unsafe" code), but HB doesn't like compiling plugins using unsafe code and I figured it was a long shot at best. I'm too used to C++, methinks.

Rep++!

Thanks for the bug report. Never bothered to test unsafe code in CCs/Plugins. I'll add support for it now.