Andor Training Range again (help request)

[lisa]

Ahh found it, I used a different version of MM, not sure which version it actually is as I have had so many versions over the years but this 1 was deffinately the best for speed of mem reads and such, might have a closer look at it but the MM side of things was always a bit out of my comfort zone, to much C##

Code: Select all

Command> local tt = getTime() for i = 1,2000 do player:update() end print(deltaTime(getTime(),tt))
8883.6106475947 -- MM
Command> local tt = getTime() for i = 1,2000 do player:update() end print(deltaTime(getTime(),tt))
8796.4153857446 -- Notepad++

Note the 2000


I'll just post it anyway, maybe if Admin has a chance can determine which version it was, if I recall it was a "test" version that we were testing something.

it has current bot version (761)

[wps]

Cool...
My test result is 4610 (MM), 4773 (Notepad++)
normal ROM andor got 2767 12 wave, and it's still not good enough
4 fdb ROM andor got 2329 11 wave, even worst
It's really hard to figure out how to achieve over 6K

[lisa]

My test result is 4610 (MM), 4773 (Notepad++)

So big improvement then, I honestly can't remember if I changed something in MM or if it was something Admin did, I do know it was a while ago when it was done though lol

[rock5]

If the difference in performance is so big, Administrator really should try to figure out the version and what made it so fast and hopefully restore some of that speed.

[lisa]

did you try it rock ?
Interested to see how fast urs were.

[rock5]

I didn't try it. I'll try it now. Here are my results.

Current base MM and base 761 bot:

Code: Select all

Command> local tt = getTime() for i = 1,2000 do player:update() end print(deltaT
ime(getTime(),tt))
58694.339688503

Your version:

Code: Select all

Command> local tt = getTime() for i = 1,2000 do player:update() end print(deltaT
ime(getTime(),tt))
5838.4886878483

Your micromacro.exe in the base MM folder.

Code: Select all

Command> local tt = getTime() for i = 1,2000 do player:update() end print(deltaT
ime(getTime(),tt))
58598.863144398

So it's not the micromacro.exe executable that's making it fast. It must be some other file.

I had a look at the differences between the other files and lib.lua stands out as the most likely cause. I copied that over and immediately got a faster result.

Code: Select all

Command> local tt = getTime() for i = 1,2000 do player:update() end print(deltaT
ime(getTime(),tt))
5554.9107726285

So it's something in that file.

[rock5]

I think I found it. In function global_hotkey_hook, getHwnd() makes it take ages for some reason. I don't think it's a slow function so I don't understand why it makes it go so slow. But an easy way to improve performance is to do the ctrl-L check first then check for the forward window eg.

Code: Select all

local function global_hotkey_hook(event, line)
	if( keyPressed(key.VK_CONTROL) and keyPressed(key.VK_L) ) then
		local ah = getAttachedHwnd();
		local fw = foregroundWindow();
		if( fw == getHwnd() or  ah == fw ) then
			stopPE();
		end
	end
end

With the base MM and bot and this change I got this result.

Code: Select all

Command> local tt = getTime() for i = 1,2000 do player:update() end print(deltaT
ime(getTime(),tt))
4163.8917871484

[lisa]

That does sound very familiar, I also seem to remember there being an issue with that change aswell, can't recall what it was exactly. Might have to go through some old posts in dev section.

[lisa]

Ok found the topic, funnily enough it was called "Control L" who would have thought.

I had another look at the code you posted and it is different to previous version and I can't see any issues with it, so I think you came up with a good solution. In previous versions it would check the window processes first and then see if you pressed control L, you are checking control L first and then checking processes, very good plan

[rock5]

Yeah, that's what I did. Just switched it around. Now we just need Administrator to add it to the bot and maybe have a go at trying to figure out why getHwnd affects performance so much.

[wps]

Cool.
I tried the fast MM several times,
and I found press control on any window (ROM, MM, or the others) will abort all the MM windows.

I was going to post this issue, but I saw you already knew it.

I removed all the addons and use the fast MM, and I got 58xx in Andor.
Oh yeah~

[Administrator]

Found the problem. I didn't put this in the changelogs since it was such a minor change, but previously I was using a kind of hackish function that I wrote to grab the HWND for the current instance of MicroMacro. There is, however, a function provided by the win32 library that returns the HWND for the current console (essentially accomplishing the same thing my function did). I figured I might as well just drop my function in favor of the win32-standard one.

However, the API calls means overhead, which is where the slowdown is coming from. So, I combined the two methods I was using so that it uses the standard function at it's core, but caches the result in a static variable to return very quickly.

In this case, it now runs about 10x faster. Try the attached fixed micromacro.exe. Try it with both the original lib.lua code and that minor modification. Logically, the original method (calling getHwnd before the nested keyPressed) should be faster, but I would like to hear your input.

[lisa]

Code: Select all

local tt = getTime() for i = 1,200 do player:update() end print(deltaTime(getTime(),tt))

Rock's version of lib
3883.4448595704

new posted MM and Rock's lib
859.67198608407


Old version of lib and new MM
982.5409298809

Looks like a winner to me.

[Administrator]

So checking the key state before HWND is faster for you? That conflicts my results, but I would still like to hear from others.

[lisa]

I only ran it once, to get better comparison I'd have to run each several times and boost it to 2000 instead of 200.

[rock5]

Code: Select all

local tt = getTime() for i = 1,2000 do player:update() end print(deltaTime(getTime(),tt))

Rock's version of lib and old MM
5061.8788980172

New posted MM and Rock's lib
4957.8485648401

Old version of lib and new MM
8351.3548742482

Each result is an average of 5 tests.

Very different results. I thought the high last value was strange so I ran it again, making sure I had a fresh copy of MM and using 2000 instead of 200. Got the same result.

[Administrator]

Hmm, strange results. Again, it seems like checking the hotkey before the HWND is faster for you. Not sure why we're getting contradictory results. Checking the hotkey should, logically, be slower as it requires polling and retrieving information from the hardware, whereas returning the HWND is actually only run once and then returns the same result after that so should be as fast as possible.

Try running this from the script prompt:

Code: Select all

exec local tt = getTime(); for i = 1,1000 do getHwnd(); end printf("HWND time: %0.2f\n", deltaTime(getTime(), tt)); tt = getTime(); for i = 1,1000 do keyPressed(key.VK_TAB); end printf("Key time: %0.02f\n", deltaTime(getTime(), tt));

I get results like:

Code: Select all

HWND time: 0.21
Key time: 1.05

which indicates that getting the HWND is much faster.

[rock5]

Code: Select all

HWND time: 0.12
Key time: 0.79

So it must be something else. Well it does do 2 other functions

Code: Select all

getAttachedHwnd time: 0.13
foregroundWindow time: 0.70

Which looks about right then. 0.12+0.13+0.70 = .95 which is more than 1 Key time alone. Maybe you can do something about the foreground functions too.

[Administrator]

Unfortunately, I don't think there's anything I can do about foregroundWindow(). It is just a direct API call to the win32 function GetForegroundWindow(). For this reason, I'll be implementing the changes you have proposed

[lisa]

my results were pretty much the same

Code: Select all

Command> local tt = getTime(); for i = 1,1000 do getHwnd(); end printf("HWND time: %0.2f\n", deltaTime(getTime(), tt)); tt = getTime(); for i = 1,1000 do keyPressed(key.VK_TAB); end printf("Key time: %0.02f\n", deltaTime(getTime(), tt));
HWND time: 0.16
Key time: 0.88