ok, found the code.
Bear in mind, that this code is from a few years ago now!!
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.
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
Base class for all 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.