-- Scan rect variables
local scanWidth = 10; -- Width, in 'steps', of the area to scan
local scanHeight = 8; -- Height, in 'steps', of area to scan
local scanXMultiplier = 1.0;
local scanYMultiplier = 1.1;
local scanStepSize = 35; -- Distance, in pixels, between 'steps'
You can make the steps closer by changing 'scanStepSize = 35' to 30 or so and you can make the scan area wider by changing 'scanWidth = 10' to an higher valua. Caution: If you only reduce 'scanStepSize', then you will make the scan area smaller.
I'm using yGather. I just let my bot run a while around the area to collect as much havesting points as possible. After that I create a waypoint file. There seems to be a bug in yGathere with the minimap. Means all yGather points at the minimap are a little wrong placed. Since I know that I can consider that.
What is the structure of yGather's information in SaveVariables.lua? I'm guessing that it will just be map coordinates instead of world coordinates, but it could still be useful.
You could solve this by making for each map a X,Z offset that will be converted by taking the map positions and differ them from the world coordinates. Would be easier though if theres a function in the game that will return world coordinates (In Lua).
Another problem when bot trying to harvest and a mob attacks him it staring to fight the mob and after fighting bot forgets about the unharvested resourses and just moving to the next point. So i need to change the behavior of the bot so after fighting he will move 1 or 2 points to back not forward.
kolobok wrote:Another problem ... to change the behavior of the bot so after fighting he will move 1 or 2 points to back not forward.
That's really a problem ... just joking. I would say there are so much rescoures. I would not worry about.
Ok. I'm harvesting at the moment in the low level area. Pherhaps I would see it different, if I had really to fight to go to a ressource point.
If you go back, there is a greater possibility to get stuck and look bottish. And I don't really understand, why the bot is skipping a waypoint. I think if I look at the coding the bot have first to reach a waypoint to go to the next. Only if you start the bot he will look for the closest one?
How can i make bot scan the area while it`s moving? So it will goes like this:start at one point(scan it) moving to another(always scan the area) stop at the point(scan once again) and so on! Is it possible or not?
Did anybody make this work on Ubuntu/Linux?
I set all up in wine, but when i press "del" nothing happens, there isn't even a error message in the console where i run MicroMacro ...
Do I maybe need some additional libraries for wine?
Only if you start the bot he will look for the closest one?
Yes he will no matter where i start him.
Yes, when you start the bot, it automatically starts the waypoints off at the closest waypoint, rather than the first waypoint.
Did anybody make this work on Ubuntu/Linux?
I set all up in wine, but when i press "del" nothing happens, there isn't even a error message in the console where i run MicroMacro ...
Do I maybe need some additional libraries for wine?
I never actually tried this specific script under WINE. I have tested MicroMacro under WINE before, and I don't think I encountered any major problems. I don't think any additional libraries would help. I think the problem is in hotkey detection. MicroMacro uses GetKeyState() to read the key up/down states. I'm not sure, but I think that WINE may have problems with this function. Does the problem persist even when MicroMacro is the foreground window? Can you try changing the hotkey from DELETE to something else (see rom/bot.lua line ~20 for this)?
How can i make bot scan the area while it`s moving? So it will goes like this:start at one point(scan it) moving to another(always scan the area) stop at the point(scan once again) and so on! Is it possible or not?
You can't do it while running. If something were found, by the time you enact on it, it would not be in the exact same place on-screen. This means when you try to harvest it, you're going to totally miss it. Plus, the function isn't designed be be used while running. It is only to be used while stopped.
I never actually tried this specific script under WINE. I have tested MicroMacro under WINE before, and I don't think I encountered any major problems. I don't think any additional libraries would help. I think the problem is in hotkey detection. MicroMacro uses GetKeyState() to read the key up/down states. I'm not sure, but I think that WINE may have problems with this function. Does the problem persist even when MicroMacro is the foreground window? Can you try changing the hotkey from DELETE to something else (see rom/bot.lua line ~20 for this)?
I tried to change both setKeys (line 18,20) but it still didn't work.
Can i maybe make him force the start when the script is called; so that i don't even have to press any key?
Change startMacro(main) to startMacro(main, true) at the end of bot.lua. I'm going to try looking into this problem and figure out why it's not working properly under WINE. I have no idea how it will act with memory reading, so expect more problems.
EDIT: Yeah, it's a known problem with WINE that is expected to not be fixed any time soon if at all.
Nope. There really is no relevance to the coordinates shown by the mini-map. The only way to get these coordinates, as far as I know, is to use rom/createpath.lua to dump your location. You could, if you wanted to, write a script to just show only your location like this:
include("classes/player.lua");
function main()
local playerAddress = memoryReadIntPtr(getProc(), staticcharbase_address, charPtr_offset);
player = CPlayer(playerAddress);
while(true) do
printf("\rLocation: (%5d, %5d)", player.X, player.Z);
player:update();
yrest(100);
end
end
startMacro(main);
