MicroMacro 2 alpha build

Message
Author
User avatar
Administrator
Site Admin
Posts: 5313
Joined: Sat Jan 05, 2008 4:21 pm

Re: MicroMacro 2 alpha build

#41 Post by Administrator » Thu Aug 21, 2014 11:13 am

No need for the brackets. We could just flat-out use functions instead of strings. That would make it much easier to find and fix errors as well.

We could even have the profile be a class. The class code is really clean.

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: MicroMacro 2 alpha build

#42 Post by BlubBlab » Thu Aug 21, 2014 7:53 pm

Administrator wrote:No need for the brackets. We could just flat-out use functions instead of strings. That would make it much easier to find and fix errors as well.

We could even have the profile be a class. The class code is really clean.
Can you make an example how this should look like I have trouble imagine it ?
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

User avatar
Administrator
Site Admin
Posts: 5313
Joined: Sat Jan 05, 2008 4:21 pm

Re: MicroMacro 2 alpha build

#43 Post by Administrator » Thu Aug 21, 2014 8:16 pm

Sure. The function would just be the same, except not encapsulated as a string:

Code: Select all

return {
  type = "whatever",
  somethingelse = "whatever",

  onload = function()
    do_something();
  end,
}
As a class:

Code: Select all

profile = Profile();

profile.type = "whatever";
profile.somethingelse = "whatever";
profile:onLoad()
  do_something();
end

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: MicroMacro 2 alpha build

#44 Post by rock5 » Fri Aug 22, 2014 12:53 am

I have to admit, the class idea is pretty sweet. At least you don't have to remember to add commas between each part like you do with tables. Although there will still be tables, eg. when adding the skills or maybe we'll still have an "options" table. But I suspect this way will increase the need for users to learn some basic lua before they can start to using the bot.

I still like the idea of a purely "data" type file which is basically what the xml files are. In regards to the difficulty of adding stuff that needs to be validated, I wonder if we could make some sort of generic xml reader that loads whatever is in the xml file and puts it into a table. Maybe even a generic function that creates an xml files from a table. Any validations can be done on the table after it's loaded.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: MicroMacro 2 alpha build

#45 Post by BlubBlab » Fri Aug 22, 2014 9:23 am

rock5 wrote:I have to admit, the class idea is pretty sweet. At least you don't have to remember to add commas between each part like you do with tables. Although there will still be tables, eg. when adding the skills or maybe we'll still have an "options" table. But I suspect this way will increase the need for users to learn some basic lua before they can start to using the bot.

I still like the idea of a purely "data" type file which is basically what the xml files are. In regards to the difficulty of adding stuff that needs to be validated, I wonder if we could make some sort of generic xml reader that loads whatever is in the xml file and puts it into a table. Maybe even a generic function that creates an xml files from a table. Any validations can be done on the table after it's loaded.
Why wonder ? I posted/mentioned one on the second page :D I discuss this because I don't want this do alone for me I personal think XML is better for large data structures like waypoints where you have endless lists of repeating informations second best would be a lua dump because like Rock5 mentioned I can save it directly which is if you want later to use an editor it is good.

What I see is admin want us to simple include the files than load it with some tools , dynamic including is possible , for saving you need again some string building script, loading a file and do selective changes like with LuaXML's xml.save() or table.save() is hard to do and need some extension of you building script.(I admit I did this twice for ROM but since than I'm not really a fan of it)

How I go from here I don't know but like I said somewhere we need the XML at least I should be possible to load the old files and save them in another format. I wrote today a scanner for XML syntax validation in lua so most of the XML part are closed for now.

I can support both with what I do that's not the problem. It's later for me any comments?
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: MicroMacro 2 alpha build

#46 Post by BillDoorNZ » Sun Nov 15, 2015 1:25 pm

rock5 wrote: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.
The 'states' idea was a real PITA. It's workable, but it's a helluva lot of work to get to function reliably and logically. I ended up implementing it with ROM (with MMv1 tho), and while it works, you end up running into issues around decision making and tracking state stacks. From memory, I had the bot running waypoints etc, but it would get confused if it got interrupted. It would push the combat state onto the stack, with move states to get to the appropriate mob/location. I needed the combat/heal state to trump move states etc as it was kinda a nuisance if your character was letting itself get killed all the time! :)

It's been too long now unfortunately, and I cant remember the exact issue. It required a fair bit of state checking to resolve though, and the result was somewhat fragile. It definitely worked and allowed me to modularise stuff more though, which was great :) It did require rewriting any waypoints too, as having old-style code in the waypoints wasnt possible...i.e. putting in a object:moveTo() obviously wouldnt work as (a) I'd removed the function and (b) its not a state. It'd have to be converted to a stateStack:push(new MoveToState(object)) // or some such, cant remember the syntax.

Might see if I still have the code lying about somewhere.

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: MicroMacro 2 alpha build

#47 Post by BillDoorNZ » Sun Nov 15, 2015 3:07 pm

ok, found the code.

Bear in mind, that this code is from a few years ago now!! :)


main.lua:
This has been changed a fair bit to call the statemanager to process the state stack. The main loop starts on line 715.
I was tracking the 'ticks' and using that when updating the player objects etc so it knew whether or not it had been updated that tick already (and would therefore not RE update).
There's some UDP stuff in there too, cant remember if the libraries are standard MM or not tho.

classes\statemanager.lua:
Manages the State stack/queue.
Each tick, the state on the top of the stack/queue would have its update() method called.
It would also check any events and ask the topmost state to handle the event, but handle the event itself if the event was not handled by the current state.
Events were being used to allow the bot to react to changes - e.g. the character is being attacked, so it would push the combat state

classes\state.lua:
Base class for all states.

classes\states:
All state implementations were defined in here.
Not all of the are mine, many are Lisa's original GW2 classes.

Of particular note are:
holdkey.lua - holds a key down for the specified amount of time
move.lua - moves the character to a target, uses holdkey to do the move-forward part


Because of the existing (at the time) implementation of the way the player class etc worked, it was quite hard to separate out movement etc. Previously, the waypoint code controlled what the character did, but with the states each state should be quite small, with additional functionality being injected by pushing more states onto the stack. This made handling interrupts quite painful at times. e.g. the bot is moving to loot, but gets attacked, so it needs to switch to combat which might take a while and end up requiring more lootings / movement. If it moves too far, it may get blocked when trying to move back to the original loot.

Ideally, a lot of the position checking logic etc would be pulled out into helper methods or onto an abstract state class for state-types that require it.

If I'd had the time, I would have pulled the whole bot apart to modularise the property value updates more, but thats a hell of a lot of work.

There are some old waypoint files in there too. I didnt look through them to see if I'd updated them tho. Obviously, with the state stuff, you cant have a waypoint taking over complete control of the bot for a long-running process, as this completely breaks the design.
Attachments
stateRom.zip
(917.35 KiB) Downloaded 2075 times

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: MicroMacro 2 alpha build

#48 Post by BlubBlab » Mon Nov 16, 2015 5:00 pm

BillDoorNZ wrote:
rock5 wrote: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.
The 'states' idea was a real PITA. It's workable, but it's a helluva lot of work to get to function reliably and logically. I ended up implementing it with ROM (with MMv1 tho), and while it works, you end up running into issues around decision making and tracking state stacks. From memory, I had the bot running waypoints etc, but it would get confused if it got interrupted. It would push the combat state onto the stack, with move states to get to the appropriate mob/location. I needed the combat/heal state to trump move states etc as it was kinda a nuisance if your character was letting itself get killed all the time! :)

It's been too long now unfortunately, and I cant remember the exact issue. It required a fair bit of state checking to resolve though, and the result was somewhat fragile. It definitely worked and allowed me to modularise stuff more though, which was great :) It did require rewriting any waypoints too, as having old-style code in the waypoints wasnt possible...i.e. putting in a object:moveTo() obviously wouldnt work as (a) I'd removed the function and (b) its not a state. It'd have to be converted to a stateStack:push(new MoveToState(object)) // or some such, cant remember the syntax.

Might see if I still have the code lying about somewhere.
I wrote a small framework for the state idea and admin wrote one too. Your's are the 3th.

By writing my meta-framework I also wrote a big base for an rom-bot for MM2.(because I copied and saved all the settings for it) The movement:moveTo(...) needs only some adjustment and testing & camera with faceit What is really missing is the fight(..) routine. You can browse it on GitHub the link is in my footer.(meta framework)
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

BillDoorNZ
Posts: 446
Joined: Wed Aug 03, 2011 7:37 pm

Re: MicroMacro 2 alpha build

#49 Post by BillDoorNZ » Mon Nov 16, 2015 5:51 pm

BlubBlab wrote:
BillDoorNZ wrote:
rock5 wrote: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.
The 'states' idea was a real PITA. It's workable, but it's a helluva lot of work to get to function reliably and logically. I ended up implementing it with ROM (with MMv1 tho), and while it works, you end up running into issues around decision making and tracking state stacks. From memory, I had the bot running waypoints etc, but it would get confused if it got interrupted. It would push the combat state onto the stack, with move states to get to the appropriate mob/location. I needed the combat/heal state to trump move states etc as it was kinda a nuisance if your character was letting itself get killed all the time! :)

It's been too long now unfortunately, and I cant remember the exact issue. It required a fair bit of state checking to resolve though, and the result was somewhat fragile. It definitely worked and allowed me to modularise stuff more though, which was great :) It did require rewriting any waypoints too, as having old-style code in the waypoints wasnt possible...i.e. putting in a object:moveTo() obviously wouldnt work as (a) I'd removed the function and (b) its not a state. It'd have to be converted to a stateStack:push(new MoveToState(object)) // or some such, cant remember the syntax.

Might see if I still have the code lying about somewhere.
I wrote a small framework for the state idea and admin wrote one too. Your's are the 3th.

By writing my meta-framework I also wrote a big base for an rom-bot for MM2.(because I copied and saved all the settings for it) The movement:moveTo(...) needs only some adjustment and testing & camera with faceit What is really missing is the fight(..) routine. You can browse it on GitHub the link is in my footer.(meta framework)

nice...will take a proper look at that :) my stuff was based off Lisa/Admins original stuff (from memory - been about 3 years since I wrote it)

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: MicroMacro 2 alpha build

#50 Post by lisa » Mon Nov 16, 2015 10:54 pm

Yeah Bill,Admin and myself used the very early versions of MM2 with GW2 a very long time ago.
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

FrankWhids
Posts: 4
Joined: Mon Mar 25, 2019 6:25 pm
Location: Bulgaria
Contact:

MicroMacro 2 alpha build

#51 Post by FrankWhids » Sat Apr 06, 2019 10:08 pm

I dont really know if its already possible or planned but why dont you think about integrating Alien into MicroMacro. This way it would be possible to access external functions written in C/C if I am not mistaken.

User avatar
Administrator
Site Admin
Posts: 5313
Joined: Sat Jan 05, 2008 4:21 pm

Re: MicroMacro 2 alpha build

#52 Post by Administrator » Sun Apr 07, 2019 4:25 pm

That's actually not a bad idea. It's obviously already possible to launch external processes or to write DLLs to extend the functionality, but having a C FFI might streamline and simplify. I'll have to add that to my to-do list for when I have a day to work on these kinds of things.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests