MicroMacro 2 alpha build

[Administrator]

Several months ago, I had announced that I started working on MicroMacro 2. Things were going together very quickly. Now, it is in a somewhat usable state but could use some testing. I'm interested to see what suggestions you guys might have as well.

Note that this is not compatible with RoM-bot! If you try to run MicroMacro 1 scripts on MicroMacro 2, it will fail.

Git on Google Code: https://code.google.com/p/micromacro/
Documentation and examples on wiki: http://www.solarstrike.net/wiki/index.php?title=Manual

Example screenshot:

If you're interested in experimenting with it, feel free to download a copy and read the wiki. I'm aware that there's not enough information to fully explain all the big changes that have happened so I think perhaps any questions you might have will help me to write up some more tutorials targeted at what you need to know.

[BlubBlab]

Yes a few question and annotation.
I'm really not sure where to start okay first when does the events fire? While the main() runs or between them?

Than I have a bad feeling mixing event driven design with a pulse driven design because you have 2 different entry points for your program. There are solution for this but those means you have to memorize the state of your bot in a global table.

The other way would be you could also register events on changes in specific memory sections and/or register timed events.

How do you solve the player:moveto(...) or similar things ? I mean from me experiences the bot can be improved or broken with changes in that function very easily and it's run relativ long in it while even need short pauses in execution in it.(so it is the ultimate test if it can work or not)

Here also an example for how to make a event register in LUA:

Code: Select all

local crashEventList = {}

function registerCrashEvent( func, name)
	local foundflag = false;
	for key,value in pairs(crashEventList) do
		if(value == func or string.dump(value)== string.dump(func))then
			foundflag = true;
		end
	end
	if(foundflag == false)then
		if(name)then 
			crashEventList[name] = func;
		else
			table.insert(crashEventList, func)
		end
	else
		print("Function has already registered,so it will be ignored ")
	end
end
--check if already registered
function isCrashEvent(func, name)
	if(name)then
		if(crashEventList[name]~=nil)then
			return true;
		else
			return false;
		end
	end
	local found = false;
	for key,value in pairs(crashEventList) do
		if(value == func or string.dump(value)== string.dump(func))then
			found = true;
		end
	end
	return found;
end
function unregisterCrashEvent( func )
	for key,value in pairs(crashEventList) do
		if(value == func or string.dump(value)== string.dump(func))then
			value = nil;
			print("Function has been unregistered ")
		end
	end
	
end

On the point where it will be called(Where the event happened) it will be used this way:

Code: Select all

for key,value in pairs(crashEventList) do
		if(type(value)=="function")then
			value()
		end
	end

A few checks are missing it's only example how event can be registered. The usefulness is depended what you do with is theoretically someone can use it to split off the event calls from macro.event(..) or whatever. Anyway I thought someone have use for it in that context.

[Administrator]

I'm really not sure where to start okay first when does the events fire? While the main() runs or between them?

Events will be fired between every main loop.

Than I have a bad feeling mixing event driven design with a pulse driven design because you have 2 different entry points for your program. There are solution for this but those means you have to memorize the state of your bot in a global table.

Only a few events are registered, and none are really necessary. These events should be used more for informational purposes, such as catching all errors and logging them.

The other way would be you could also register events on changes in specific memory sections and/or register timed events.

I suppose the user could throw any event they wanted, but as of right now this isn't a supported feature. I'm not sure whether I should add it or not.

How do you solve the player:moveto(...) or similar things ? I mean from me experiences the bot can be improved or broken with changes in that function very easily and it's run relativ long in it while even need short pauses in execution in it.(so it is the ultimate test if it can work or not)

While loops like that should be completely avoided. Here's a piece of code I was testing with that did manage to move my character very smoothly and at 0% CPU usage:

Code: Select all

include("state.lua");

Moveplayer = class.new(State);

function Moveplayer:constructor(x, z)
	Moveplayer.parent.constructor(self);
	self.name = "Move player";
	self.toX = x;
	self.toZ = z;
	self.moving = false;
	ncurses.print(logWin, sprintf("Moving to (%0.1f, %0.1f)\n", x, z));
	ncurses.refresh(logWin);
end


function Moveplayer:update(dt)
	-- Fake the players movement...
	local angle = math.atan2(self.toZ - player.z, self.toX - player.x);

	if( math.abs(angle - player.angle) > 0.05 ) then
		player:setDirection(angle);
	end

	if( not self.moving ) then
		keyboard.virtualHold(getWindow(), key.VK_W);
		self.moving = true;
	end

	if( math.distance(player.x, player.z, self.toX, self.toZ) < 25 ) then
		ncurses.print(logWin, sprintf("We arrived at (%0.1f, %0.1f)\n", player.x, player.z));
		ncurses.refresh(logWin);

		keyboard.virtualRelease(getWindow(), key.VK_W);
		self.moving = false;
		return false;
	end

	return true;
end

And then the state (Moveplayer in this case) called update() on every main loop. That's it! Very simple.

[Lamkefyned]

This version will work with microMACRO Rombot someday?

[lisa]

rombot would need a complete rewrite to work with MM2, so it is possible but only if someone wants to spend the time doing it.

[rock5]

I think ultimately we will but it's a huge task. The bot would have to be mostly rewritten not only to use the new commands but to use the "states" idea. I think we should wait until someone uses it for another newer, smaller project first. That will give us the chance to gain a bit of practice with it and iron out any kinks in the MM2 code before trying tackle rombot.

[BlubBlab]

The "problem" is we need a lot of information for the state or in a other way said we bypass what a programming language does under the hood and do it manually. Which give a lot finer control with the cost of complexity.

I thought about it you need 3 return values for the functions: succeed , failed , pending.

The State needs a Name for debugging, a function pointer, Last_Call, Last_Success .
e.g

Code: Select all

State:Push({state_name="USE_SKILL",func=player:check_skill,last_call = nil, last_success = nil})

or

Code: Select all

State:Push_Tree({state_name="USE_SKILL",func=player:check_skill,last_call = nil, last_success = nil,fail_func == player:fight, success-func = player:fight })

on the main loop you have a simple State:Call()

Code: Select all

function State:Call()
 local state = self:pop();
local   callreport = state.func()
if(callreport == PENNDING)then
self:Push(state);
end
if(callreport == FAILED and state.fail_func ~=nil)then
self:Push({--new constructed state--})
end
-- same for success
end

The point when it become hardcore is when you want to delay or doing things simultaneously for that it would be needed a second state/stack so things that lua coroutine did before you must now do yourself.

EDIT: okay I implemented a little bit for fun the State class is nearly finished.

[BlubBlab]

Okay I made an example based on this what do you think?

Code: Select all

function macro.init()
	player = CPlayer.new();
	state = new CState.new();
end

local running = true;
local HaveWaypoint = false;

function macro.main()
	local temp_state = state:peek();
	local name_state;
	if(l_state == nil)then
		name_state = "MOVING"
	
	else
		name_state = temp_state.state_name;
	end
	player:update();
	--I'm not sure how to handle this  "FIGHT" I could mean a categorie best idea until now
	if(player:hasTarget() and name_state ~="FIGHT")then
		
		state:push(
		{state_name ="FIGHT",
		func = player:fight,
		last_call = nil, 
		last_success = nil}
		);
		
	end
	if(HaveWaypoint == false)then
	-- get new waypoint/ update target waypoint/ missing implementation  
		HaveWaypoint == true;
	end
	
	temp_state = state:peek();
	name_state = temp_state.state_name;
	if(name_state == "MOVING")then
		local not_empty ,report = state:call();
		if(report == STATE_SUCCESS)then
			HaveWaypoint == false;
		end
		if(report == STATE_FAILED)then
			
			state:push(
			{state_name ="UNSTICK",
			func = player:unstick,
			last_call = nil, 
			last_success = nil}
			);
			
		end
		if(state:empty())then
		   -- update state/push new state / missing implementation  
		end
	else
		local not_empty ,report = state:call();
		if(state:empty())then
		   -- update state/push new state / missing implementation  
		end
	end
	-- replacment for coroutine should I implement a another class for it or both in one?
	state:timed_calls();
	
	return running;
end

It is still not complete but the idea should be transparent.

[Administrator]

Rather than passing a whole bunch of variables as a state, why don't you instead just create a new state object with those parameters?

[BlubBlab]

Because I should perhaps better name the class StateStack but I got an idea from that^^

Code: Select all

state:push_state("UNSTICK",player:unstick);

That is much more compact and easier to read.

By the way I can't post attachments here, so I can't append the code on my posts^^

[Administrator]

What filetype are you trying to post? If you zip it up, it should upload without issue.

[BlubBlab]

That doesn't matter the option don't show up.

[Administrator]

I'm not sure I understand the problem. I, and others, attach zip files to the forum all the time.

Are you saying you do not see the file upload form just below the reply section?

[BlubBlab]

Yepp the form is missing I think it is deactivated just in this section for normal users.

[lisa]

There is no attach file for this section.

[Administrator]

OK; all users should have permission to attach files in this section now.

[lisa]

I can confirm I do now.

[3cmSailorfuku]

Anyone compared the execution speed yet?

[BlubBlab]

Admin said that the main loop run 1000x a second, I never counted them in the old MM but it is to expect the old (MM1.x) is a bit slower because of the Coroutine overhead . The other function should be similar fast(or admin should say I'm wrong) but I must notice MM and Rombot became faster over time.

The main advance with MM2 is that you can do multiply things at once because you make only short calls and update the status. I did try to do something similar with threads and Lua it is awful(in compare to Cx14,C#, Java) because Lua weren't designed for this.

------------
Okay something other I nearly finished implementing the state class, some testing and bugfixing&doc need still be done
It looks like this now:
creating a new state:

Code: Select all

--create a new state:
state:push_state("NEW_STATE_LABEL",func_name);
state:push_args(arg1,arg2,....argn)

-call the new(last) state:
 success_boolean, report_string = state:call()

for that to work the function need to have a specific format:

Code: Select all

function example(self, arg1, arg2,....argn)

--e.g how to save the last success time
self.last_success = getTime();

--you need to return STATE_PENNDING  or STATE_FAILED  or STATE_SUCCESS 
-- STATE_FAILED  or STATE_SUCCESS  basically says we are finished go to the next state, and STATE_PENNDING says call me again.
return STATE_$
end

While I'm looking at this I realize I need to allow more return values and add debug options.
EDIT: Done.

[Administrator]

Yes, by default MicroMacro 2's logic cycle will run at ~1,000 cycles per second. This is probably good enough for most purposes and recommended as unless you're doing something crazy, processor usage will remain at 0%.

Optionally, you can open up config.lua and modify yieldTimeSlice to false. When not yeilding your timeslice, the CPU usage will run unlocked and use 100% of the CPU, so the number of cycles it runs per second is variable. Note, however, that in this mode it only consumes unused CPU time. This means that it will give other processes preference instead of trying to constantly hoard the whole CPU for itself. So, while you might run at a much, much higher frequency in this mode, it still is using a whole lot of extra electricty and producing more heat; definitely not recommended for a laptop as it will drain your battery fast.


MM2 is faster for a few different reasons. First, as stated, we ditched the confusing coroutine structure. Second, we're not jumping all over the place during execution. Third, the important back-end stuff is all written in C/C++ instead of Lua, which is about 20 times faster in itself. Fourth, a lot of code has received some optimization. Finally, we're no longer loading and compiling on the fly; things can now be compiled into bytecode and run more efficiently.

I don't have the exact numbers anymore (ran tests on this awhile ago, and much has changed since then), but MM2 is definitely faster. How much faster, I can't say. It really depends on what you're doing with it. If you use simple Lua code for testing, you'll get approximately the same speed on both as I have done nothing to make Lua execution faster; just the flow and execution of MicroMacro itself.

There's also a number of new functionality for improved performance, such as reading memory as chunks. This is great for things like reading a whole pawn object from memory, and is typically 2-4 times faster.