MicroMacro 2 alpha build
- Administrator
- Site Admin
- Posts: 5307
- Joined: Sat Jan 05, 2008 4:21 pm
Re: MicroMacro 2 alpha build
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.
We could even have the profile be a class. The class code is really clean.
Re: MicroMacro 2 alpha build
Can you make an example how this should look like I have trouble imagine it ?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.
Jack-of-all-trades, but master-of-only of a few
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
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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
- Administrator
- Site Admin
- Posts: 5307
- Joined: Sat Jan 05, 2008 4:21 pm
Re: MicroMacro 2 alpha build
Sure. The function would just be the same, except not encapsulated as a string:
As a class:
Code: Select all
return {
type = "whatever",
somethingelse = "whatever",
onload = function()
do_something();
end,
}
Code: Select all
profile = Profile();
profile.type = "whatever";
profile.somethingelse = "whatever";
profile:onLoad()
do_something();
end
Re: MicroMacro 2 alpha build
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.
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
Re: MicroMacro 2 alpha build
Why wonder ? I posted/mentioned one on the second pagerock5 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.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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
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
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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
-
- Posts: 446
- Joined: Wed Aug 03, 2011 7:37 pm
Re: MicroMacro 2 alpha build
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!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.
![Smile :)](./images/smilies/icon_e_smile.gif)
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
![Smile :)](./images/smilies/icon_e_smile.gif)
Might see if I still have the code lying about somewhere.
-
- Posts: 446
- Joined: Wed Aug 03, 2011 7:37 pm
Re: MicroMacro 2 alpha build
ok, found the code.
Bear in mind, that this code is from a few years ago now!!![Smile :)](./images/smilies/icon_e_smile.gif)
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.
Bear in mind, that this code is from a few years ago now!!
![Smile :)](./images/smilies/icon_e_smile.gif)
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 924 times
Re: MicroMacro 2 alpha build
I wrote a small framework for the state idea and admin wrote one too. Your's are the 3th.BillDoorNZ wrote: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!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.
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 greatIt 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.
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
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
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
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
-
- Posts: 446
- Joined: Wed Aug 03, 2011 7:37 pm
Re: MicroMacro 2 alpha build
BlubBlab wrote:I wrote a small framework for the state idea and admin wrote one too. Your's are the 3th.BillDoorNZ wrote: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!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.
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 greatIt 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.
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
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: MicroMacro 2 alpha build
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 ![Wink ;)](./images/smilies/icon_e_wink.gif)
wiki here http://www.solarstrike.net/wiki/index.php?title=Manual
![Wink ;)](./images/smilies/icon_e_wink.gif)
wiki here http://www.solarstrike.net/wiki/index.php?title=Manual
-
- Posts: 4
- Joined: Mon Mar 25, 2019 6:25 pm
- Location: Bulgaria
- Contact:
MicroMacro 2 alpha build
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.
- Administrator
- Site Admin
- Posts: 5307
- Joined: Sat Jan 05, 2008 4:21 pm
Re: MicroMacro 2 alpha build
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.
Who is online
Users browsing this forum: No registered users and 2 guests