First Person AHK
Mar 12, 2021Introduction
The first time I had ever used AHK was back in highschool. My friend made a Discord bot called “Starmine” that would give out points whenever a user typed !starmine.
It was a fun incremental/idle game that we all played, and while you could wait for the passive point generation, the fastest way to get points was to type !starmine.
The game got really competitive and as we went into the summer months and I needed a way to edge out the competition.
Enter AHK.
A few minutes of searching yielded this language that was easy to use for a programming beginner (me).
Back in 2017, the wiki for AHK was a little lacking in detail but I was able to piece together a simple script, with some help from reddit, which automated the Starmine game. Success!
Elite: AFK
Fast forward to Christmas 2020, more than three years since I last touched AHK. My friend introduced me to a game called Elite: Dangerous, a mind numbing MMO that I have developed a love-hate relationship with in my three months of experience.
Within this game there are several unfun gameplay loops that you need to master in order to progress to the more fun portions of the game. One of these loops is gathering engineering materials.
Smart players figured out the most efficient way to gather each type of material and compiled it into a spreadsheet.
There within lies the dreaded Jameson’s Crashed Python. This method of collecting encoded data requires the player to point and click three beacons around the player, and then log out and log back in to reset the beacons.
This is not gameplay. I don’t know what this is, but it is definitely not gameplay.
My friend had been playing this game for five years and has done this task hundreds of times. So I dusted off AHK and got to work.
I couldn’t recognize the AHK docs the first time I opened them up. They were so neatly organized, the style was much better and it was apparent that a lot of effort went into making examples.
Planning the script
From the get-go I scoped out some issues I knew would suck.
- How do I pan the camera
- How do I deal with loading screens
Everything else could be accomplished with sequential keypresses.
Panning the camera
AHK has the ability to move a cursor to a specific point on the screen using the MouseMove function. However, this doesn’t work in first person games.
You can’t move the mouse to a point further than the edge of the screen. I needed a way to move the mouse in a direction instead of to a point.
After searching the AHK forums, I stumbled upon a library called LLMouse written by evilC.
https://www.autohotkey.com/boards/viewtopic.php?f=19&t=26137
A copy of the library can be found here (fetched December 2020)
The description says, “a library to send low level mouse input”. The library comes with a function LLMouse.Move(x, y, times, rate) which lets us move the mouse some number of units in a direction. It also lets us specify the speed and multiplier for movement.
Perfect, now we can pan the camera by sending relative movement input. Even if the mouse hits the side of the screen, we can continue to move the mouse.
Loading screens
The other parts of the script can be timed or done sequentially. Loading screens are a different issue as the time it takes to get through the loading screen varies from computer to computer.
Looking through the AHK wiki, I found a function called PixelGetColor which allows AHK to obtain the color of a specified pixel.
The first loading screen is between exiting the game and entering the main menu. The program looks for a light blue pixel that should remain the same across all game versions.
The next loading screen is between the main menu and entering the game. The program looks for when the black color of the loading screen stop showing up. I didn’t pick a color that appears on screen after the loading finishes because different ships have varying colors and users can customize the HUD colors.
All done! Sort of…
The code was pretty simple to work out but there are still many things to improve. The script only works for 1980x1080 resolution since the camera movements are hard-coded. I believe that I could calculate the ratio of movement required to move from one beacon to the next, meaning that a user would only have to modify one parameter to adjust the overall camera movement.
The biggest issue is the reliability of the SRV positioning. I have a screenshot in the repo for the script but it is still unreliable.
There was a bug where the exit script button doesn’t work sometimes. I’m not actually sure what the issue with that is, I would love it if someone would let me know.
The repo can be found here.
Notes
This entire project is Matthew’s fault, and will not be maintained while I have ragequitted Elite. Feel free to make it better and fix it up yourself.