Exempt wrote:The 64bit upload still seems to have the same issue with wrong number of arguments.
You're right. Sometimes I'm kind of a ding dong and forget to compile things before packaging them for distribution.
Also for some reason while using the 32bit MM becomes unresponsive when the pixelSearch returns true I believe.
I'm unable to reproduce that at all. Have you overwritten all files with the pack I uploaded?
I modified your script to just check Notepad for the color white:
Code: Select all
function macro.init()
hwnd = window.find("Untitled - Notepad");--("testJavaClient");
winX, winY, winW, winH = window.getRect(hwnd);
print(window.getTitle(hwnd), winX, winY, winW, winH);
end
local running = true;
function macro.main()
return running;
end
function macro.event(e, data1, data2, data3, data4)
if( e == "keypressed" ) then
if(data1 == key.VK_Y) then
x, y = mouse.getPosition();
x = x-winX;
y = y-winY;
r,g,b = window.getPixel(hwnd, x, y);
print(r,g,b);
local sr, sg, sb = 255, 255, 255;
px, py = window.pixelSearch(hwnd, sr, sg, sb, x-5, y-5, x+5, y+5, 1, 1);
if(px and py) then
print("Working.");
else
print("Not working.", x, y);
end
end
if( data1 == key.VK_SPACE ) then
print("Space bar was pressed. Quitting.");
running = false;
end
end
end
It works just fine there. What is the target application you're trying to check against? It could be related to how that window is being rendered, or perhaps it has some sort of anti-cheat that is preventing MicroMacro from grabbing a screenshot of it. Alternatively, it could be that there is some sort of blending which is causing the color values at those pixels to slightly change and therefor be outside of the accuracy range.
- bar_example.png (14.93 KiB) Viewed 20406 times
In this example, the top health bar shows an optimal candidate for pixel searching. It is solid, has very contrasting colors against nearby pixels that you don't want to detect, and has no alpha transparency or overlays. This means it is reliable because the pixel colors are fairly constant.
The bottom bar is a bad example. The colors blend together a bit with the gradient, there is alpha transparency which causes background element (the tree, in this case) to potentially throw off color values, and the green part of the bar can be too similar to surrounding elements. This means the exact pixel colors vary and will be unreliable.
The command is relatively new but isn't that the same function I suggest in LUA for reading the LP bar in ArcheAge ?
I'm not sure. It's been part of MicroMacro for a very long time. However, its usefulness is minimized due to the fact that it is a very poor way to do detections in anything beyond the most simplistic of visual elements. It cannot recognize shapes or anything like that; it just looks for any pixel that matches a single specified color.