I fully explored the AutoHotkey GUI model. I pushed it to its limit. If I move the window manually, the GUI will float by the edge and stay on screen. First thing I did was program it to dock and undock the window. It turns into a 15x15 pixel image that's completely silent, only flashes red. I press f1 and it transforms into battle mode which I used to click faster on things for a little while. It's alright.
I devised a callback system. This is how it can exit a raid, start all timers, and go back in after the timer's over. For no apparent reason it can start as many timers as it wants, and I can dismiss all notifications because I wanted to see how hard it'd be to program the GUI to allow that. This is how hard it was.
for k, v in guiMessages
{
Gui, MsgGui:Add, Text, cWhite gMsgGuiCloseMsg y+m, % v
}
Gui, MsgGui:Add, Button, cRed gMsgGuiClose, CloseAll
nice
I wrote a reusable click tool because, for an autoclicker, they're sorely lacking a really reusable "click this image" function. Here's a clue.
FFind(searchImg, searchTime := .5, variation := 50, t := "", coordinates := "", doFind := 1)
not capability, waits for something to disappear.
NotFFind(searchImg, searchTime = .5, variation := 50, t := "", coordinates := "")
The concept of "patience" or searchTime as passed in the function improves on sleep.
Over 100 snips of images were taken to click on.
Inevitably I wrote various sequence functions, shrinking the code down quite a bit if I rewrite it.
These expect delay, fail after delay
SlowChain(allowMistake := 1, params*)
SlowMenu(image, delay := .5, endimg := "")
These expect zero delay, or fail immediately
TransitionChain(allowMistake := 1, params*)
TransitionMenu(image, delay := .5, endimg := "")
I also used Gdip and called it like the FFind... I guess this would be basic stuff for someone with continuous decades of experience, but I don't think these languages have been around so long, so, I think it was good work.
Oh yeah and I had the mouse delay about half a second before it was allowed to click again so FClick and XClick both use code like this.
s := nextClick - A_TickCount
if (s < 0)
s := -1
sleep % s
I hardcoded just a few things.
That's almost all there is to it.
There was one failed idea. Memorizing click and timing. It trained, excluding images that moved around the screen. It called upon one function after training, saving, and loading the variables
then it clicked after the calculated delay, failure. The game's delay is too random. Scanning a hardcoded region of the window repeatedly always worked hence: FFind(.... coordinates...) was produced. All click functions were rewritten to use FFind or the inverse NotFFind when I wanted to wait for something to go away.
The game checks to see if the party is full often, it reparties dropped members anywhere and tries to save time exactly how I would, if you're anywhere but on a quest it's faster to log out first.
The game goes on raids, gets killed, repeats for hours if necessary before getting stuck on Nessy.
Each raid has a unique strategy. There are more functions involved with healing, dodging, and min-maxing the heals, for more final damage, and it saves heals to scrape by the taco lord when it can wipe your whole underequipped party. The last thing I did was I had to program an estimation for how fast mana recharged and how many heals were going to be ready, it seems to work, but the slight randomness means I have to shuffle the equipment around to get the result I need.
Here's the video, full raid, with one level advantage, takes place at 14 minutes. If you sat around watching a true raid with minimal gears it takes over 4 hours. Especially when you have to farm for equipment in the middle. The script also was programmed to farm loot and reset, reload saves, restart the raid until it found another fabled gear, etc.
Developer
