[In-process] C# managed fishing interaction

[opulent]

So yesterday I decided to add a fishing state to my fsm. I estimated that I could get the whole thing going in an hour or less considering that fishing is such an elementary task.

I should have counted on getting screwed by Murphy, damn Murphy.

Notes to add:
1.All of this code is being pulsed using an endscene hook called by a managed class library.
2.The CLR is running.
3. I'm using Apoc's whitemagic library as a read/write wrapper.


The problem I'm facing at the moment is interacting with the bobber.
specifically.. I'm not interacting with the bobber at all.

I have an interact function that works fine for looting but the implementation doesn't seem to give a s*** about my fishing bobber and hence is inherently flawed.

A debug version of my implementation of 'Interact' is as follows

//Wow version 3.3.0
[UnmanagedFunctionPointer(CallingConvention.ThisCall)]
 private delegate IntPtr InteractDelegate(IntPtr instance);

private InteractDelegate _interact;

public void InteractWithObject(WoWObject obj)
{
     if (_interact == null)
         {
                IntPtr InteractAddress = m.GetObjectVtableFunction(ObjPtr, (uint)VFTableIndex.Interact); //<--That's index 42
                _interact = m.RegisterDelegate<InteractDelegate>(InteractAddress);
            }

            try
            {
                _interact(obj);
            }
            catch (System.Exception ex)
            {
                string debug = ex.ToString();           
            }
        }

I might also add some other design details which may or may not assist in diagnosing this issue but could quite possibly feed some searchers some day.

My bobber is wrapped as follows:

//Wow version 3.3.0
public class FishingBobber : WoWGameObject
    {
        public FishingBobber(IntPtr objPtr)
            : base(objPtr)
        {
            ObjPtr = objPtr;
        }

        public bool IsSplashing
        {
            get { return m.Read<short>((uint)ObjPtr + 0xBC) == 1 ? true : false; }
        }

    }

and GameObject contains the method:

 public ulong CreatedByGuid
        {
            get { return ReadDescriptor<ulong>(Descriptors.GameObjectFields.OBJECT_FIELD_CREATED_BY); }
        }

finding my fishing bobber from a List<GameObjects> reads:

public void FindFishingBobber()
        {
            var list = from c in GameObjectList where c.Name == "Fishing Bobber" select c;

            foreach (WoWGameObject wGo in list)
            {
                if (wGo.CreatedByGuid == ObjectManager.Me.Guid)
                {
                    _fishingBobber = new FishingBobber(wGo);
                    return;
                }              
            }
           
            _fishingBobber = new FishingBobber(IntPtr.Zero);
        }

To the point:

When it's time to interact with the fishing bobber I send InteractWithObject(_fishingBobber). The function executes with no exceptions but nothing appears to happen in the game world. I've done a bunch of searching and although I have a semi working CTM wrapper, I'd rather not go down that path, I'd also rather not write the guid to mouseover and call a keystroke. I want something that attempts to interact with any wowobject which is what I thought I had.

also. I might add that my reversing skills aren't honed and currently I only really use ida to reverse the statics posted on this site to see the calling conventions and args, I havent attempted to reverse the object structures at all but I'd sure like to figure out how someday.

Any hints on where I'm going wrong, methods I should look for or something obvious I'm unaware of with regards to gameObjects or the interact function?

Thanks in advance.

[Kryso]

Why InteractWithObject( WoWObject obj )? Go for obj.Interact()!

Also why are you using query and then interating result when you can simply do this:

var result = from c in GameObjectList where c.Name == "Fishing Bobber" && c.CreatedByGuid == ObjectManager.Me.Guid select c.Address;
_fishingBobber = new FishingBobber( result.FirstOrDefault() );

[Apoc]

All object types (well; almost all) have their own implementation of Interact. (Hence why it's a virtual func, not a static func)

You need to re-register the delegate for each instance of WoWObject (assuming that's how you did it) to get the proper Interact function addr. The other alternative is to cache the 7 or 8 different Interact addrs and use them instead.

[Cypher]

All object types (well; almost all) have their own implementation of Interact. (Hence why it's a virtual func, not a static func)

You need to re-register the delegate for each instance of WoWObject (assuming that's how you did it) to get the proper Interact function addr. The other alternative is to cache the 7 or 8 different Interact addrs and use them instead.

class WoWObject
{
public:
// Other virtual functions for padding
virtual void Interact() = 0;
}

C++ pwns u.

[opulent]

Why InteractWithObject( WoWObject obj )? Go for obj.Interact()!

Also why are you using query and then interating result when you can simply do this:

var result = from c in GameObjectList where c.Name == "Fishing Bobber" && c.CreatedByGuid == ObjectManager.Me.Guid select c.Address;
_fishingBobber = new FishingBobber( result.FirstOrDefault() );

Noted. Redesign in process.

[namreeb]

class WoWObject
{
public:
// Other virtual functions for padding
virtual void Interact() = 0;
}

C++ pwns u.

C# can lick my nuts. That is all.

[Apoc]

        public virtual void Interact()
        {
            if (_interact == null)
            {
                _interact = Utilities.RegisterDelegate<InteractDelegate>(GetVFunc(VFTableIndex.Interact));
            }
            OnyxWoW.ResetAfk();
            _interact(this);
        }

Works just as well. o.O

[Cypher]

        public virtual void Interact()
        {
            if (_interact == null)
            {
                _interact = Utilities.RegisterDelegate<InteractDelegate>(GetVFunc(VFTableIndex.Interact));
            }
            OnyxWoW.ResetAfk();
            _interact(this);
        }

Works just as well. o.O

Yes, it works "Just as well". I'm simply talking about how much EASIER it is to do in C++, especially "from scratch" where you don't have aux libraries to abstract away some of the ugliness (e.g. GetVFunc, RegisterDelegate, etc).

Surely you can't deny that the C++ code I presented is a LOT easer to implement. In terms of the amount of work you need to do it's about equivalent to defining the VFTable index object/enum/whatever you are referencing in your class.

[opulent]

        public virtual void Interact()
        {
            if (_interact == null)
            {
                _interact = Utilities.RegisterDelegate<InteractDelegate>(GetVFunc(VFTableIndex.Interact));
            }
            OnyxWoW.ResetAfk();
            _interact(this);
        }

Works just as well. o.O

I changed things up and now an 'InteractHandler' gets registered to every WowObject that gets instantiated rather than just My active player. The bobber gets looted when I trigger its interact method passing it's own Object pointer as an argument. Units are also being interacted with the same way.

Thanks for all the help on this.

[Apoc]

Yes, it works "Just as well". I'm simply talking about how much EASIER it is to do in C++, especially "from scratch" where you don't have aux libraries to abstract away some of the ugliness (e.g. GetVFunc, RegisterDelegate, etc).

Surely you can't deny that the C++ code I presented is a LOT easer to implement. In terms of the amount of work you need to do it's about equivalent to defining the VFTable index object/enum/whatever you are referencing in your class.

Oh, no doubt. I've actually been looking into how much of a perf hit it will be to write a native wrapper around wow, and expose it via COM so I can use it in C#. (Sorry, but general bot logic is just soooooooooo much easier in C# than C++)

[Cypher]

Oh, no doubt. I've actually been looking into how much of a perf hit it will be to write a native wrapper around wow, and expose it via COM so I can use it in C#. (Sorry, but general bot logic is just soooooooooo much easier in C# than C++)

No argument here. Unless you're a very heavy C++ user then C# is going to be a lot easier to write your actual bot in. C++ however is much easier to use for all the low level stuff.

How far along are you in your COM tests? I'd be interested in that...

[Apoc]

No argument here. Unless you're a very heavy C++ user then C# is going to be a lot easier to write your actual bot in. C++ however is much easier to use for all the low level stuff.

How far along are you in your COM tests? I'd be interested in that...

Honestly; I'm not familiar with COM enough to run any tests as of yet. (Still doing research so I don't end up hitting a brick wall)

There's obviously going to be an overhead, but if that overhead is more than just switching my current code to use unsafe code (pointers/refs/etc) and skip the entire Marshaler, then I'll probably just fix the 5 or so methods I have doing a bunch of work via the Marshaler. Honestly; once you finish writing the framework in C#, it's quite easy to update. (Especially the vtable part, no moving stuff around, just change some numbers)

At any rate; I'll let you know what I find. Gotta whip up a basic WoWObject class and do some tests.

[amadmonk]

Honestly; I'm not familiar with COM enough to run any tests as of yet. (Still doing research so I don't end up hitting a brick wall)

There's obviously going to be an overhead, but if that overhead is more than just switching my current code to use unsafe code (pointers/refs/etc) and skip the entire Marshaler, then I'll probably just fix the 5 or so methods I have doing a bunch of work via the Marshaler. Honestly; once you finish writing the framework in C#, it's quite easy to update. (Especially the vtable part, no moving stuff around, just change some numbers)

At any rate; I'll let you know what I find. Gotta whip up a basic WoWObject class and do some tests.

Honestly, the dispinterface perf hit is minimal (this topic is covered in various formats in other places), so unless you write the code totally craptastic, the perf should be fine (where 'fine' means I don't know that I'd use it in microsecond-precise tools, but it should have no problem whatsoever in controlling WoW with no FPS hit).

Wait for C# 4.0, and the COM re-wrap will be trivially easy. In fact I think it might "just work" out of the box (maybe you'd need to add 10-12 lines of code, tops). I hadn't even considered the COM route when moving my code out of process, and now I'm kicking myself since that's pretty much exactly what I've been doing (exposing WoW's internals as a "service" to be consumed elsewhere).

Eenteresting.