SolarStrike Software

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.

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 ?

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

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.

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 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?

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.

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.

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)

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)

Yeah Bill,Admin and myself used the very early versions of MM2 with GW2 a very long time ago.

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.

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.