DoString silently failing

[Cypher]

Being the hardware event, this is also the reason, why certain functions wont be called (restricted) if you passed something.

The filename does not need to be a *.lua one but can be used for you to help you debugging in lua. You could pass the name of the function you're executing your script. The filename will be printed on lua errors seen in those message boxes with red font ingame.

Naturally the string can be anything you want, I simply wanted to point out the purpose of the second parameter, as people often question why you "need to pass the code in twice" (which is usually the advice given.

[Apoc]

Fyi the final argument of DoString is the hardware event code I think. It's not a pointer, it's an integer.

The prototype is (or very close to it):
void FrameScript__Execute(const char* pBuffer, const char* pFile, unsigned int HWEvent);

So you might call it with:
Framescript__Execute("MoveForwardStart()", "FakeFileName.lua", 0);

I'm not so sure about that. There's only 4 functions that actually call FrameScript_Execute (might be 5, but my point is still valid.)

The only thing that ever gets passed to the 3rd param, is the val at 0x135EC60. (One of those calls is one of the handlers for RunScript)

From the looks of that, it's just an internal Lua helper. (It's used in *all* the 'actual' lua calls, as well as most (if not all) the protected functions and such.)

From the 3-4 functions I looked at that access it, it gets set to some arbitrary value, some Lua functions are called, then it's set back to what it was.

Then again, I may be entirely wrong, but hey, I don't rightly care as passing 0 works.

[Cypher]

I'm not so sure about that. There's only 4 functions that actually call FrameScript_Execute (might be 5, but my point is still valid.)

The only thing that ever gets passed to the 3rd param, is the val at 0x135EC60. (One of those calls is one of the handlers for RunScript)

From the looks of that, it's just an internal Lua helper. (It's used in *all* the 'actual' lua calls, as well as most (if not all) the protected functions and such.)

From the 3-4 functions I looked at that access it, it gets set to some arbitrary value, some Lua functions are called, then it's set back to what it was.

Then again, I may be entirely wrong, but hey, I don't rightly care as passing 0 works.

You might not be sure, but I am:
.text:0049AACE 8B 4D 10 mov ecx, [ebp+HardwareEvent]
.text:0049AAD1 89 0D 60 EC 35 01 mov WoWHardwareEventNum, ecx

Do your research next time noobcakes.

The WoWHardwareEventNum global is used in the generic protection function on stuff like MoveForwardStart etc. And it's also used directly in some of the newer protected functions such as InteractUnit.

BURNED MOTHER****ER!

[vulcanaoc]

Cypher: I haven't tested this, but would the WoWHardwareEventNum global be required to call those protected functions that you mentioned above?

I tried calling MoveForwardStart(). The first time, it worked. This is because I am constantly updating the value at 0x12CBCD4, which has to do with the last hardware event (it is close to GetTickCount(), but is larger by a non-constant value). However, if I did not update that address, MoveForwardStart() fails.

[lanman92]

I'm not sure if this will help, but WoW has a gettiming function that determines the right timing method to use and returns a value. It's at 0x46E4C0. This might be the time used, it kind of mangles the gettickcount a bit.

[vulcanaoc]

seems like that function immediately jumps to 0x46E460, which calls either QueryPerformanceCounter OR GetTickCount.

I'll reverse it and see if I can figure out what formula it is 'mangling' GetTickCount with

Or, more likely, I'll just call that function from now on..

[vulcanaoc]

Yep, worked like a charm. Thanks for the tip

[ramey]

:| Just pass 0. Protected functions will call without a problem. Thanks for the insight Cypher.

[Nesox]

Yea if you call them from EndScene, doing anything besides that it just plain stupid