Never really looked at AHK much until these threads and then I noticed that you could build GUI’s with it (which I had been unaware of). So I decided to hack together an AHK GD Switcher version.
I zipped the .ahk file up if anyone is interested. Guess you could call this a first draft.
GD Switcher.zip (3.7 KB)
If you are interested in looking at my code then I apologize in advance for the severe lack of commenting within it. 
I am interested, I’ve been thinking about GUI recently (and how configuring the program with .ini file might be off-putting to some). Thanks. I didn’t know about the GUI in AHK either (I thought you need to download some external library or something like that).
Nope. Everything you need is right in AHK. Here’s a simple GUI you can copy/paste in and try out yourself…
#SingleInstance, Force
Gui, Add, Button, gPush x100 y50, Push Me
Gui Show, w250 h150, Simple GUI
return
Push:
WinGetPos, X, Y, , , A
X := X - 100
Y := Y - 100
WinMove, Simple GUI, , %X%, %Y%
MsgBox, , Gee you're pushy!, Good job, champ.
X := X + 200
Y := Y + 200
WinMove, Simple GUI, , %X%, %Y%
return
GuiClose:
ExitApp…it doesn’t take much to get a GUI up and displayed in AHK, thankfully.
The documentation is a good place to start as well…
https://www.autohotkey.com/docs/commands/Gui.htm
My Switcher script might be a little complicated to piece together what’s going on in there (it’s at about 1500 lines right now) until you get more used to what you’re looking at. If you have any questions feel free to ask.
Not sure what you are using to edit your AHK files but I’ve been trying out AutoGUI:
Which has a graphical GUI designer built right into it as well as other tools.
I like that the tool to convert to self-contained exe’s is built into it as well…
Just thought you might find it useful if ya hadn’t come across it yet.
Thanks, I’ll definitely download it next time I use AHK, even just for the code tooltips.
After using AHK Studio for a bit I realized that it had some serious bugs where it would freeze completely after so many times (several) of running your scripts in app for testing. I’ve resorted to just using VS Code w/ AHK extensions (and manually constructing my UI’s).
As I’ve gotten more familiar with AHK I’ve been having a go at redesigning the interface -
Improved Inquisitor Seal 2.0
Both offensive and defensive functions of the Seal are guaranteed no matter where you click.
If you really want to be able to cast the Seal in the center of the screen from time to time, maybe IF can be added checking if your cursor is near the center and then cast the Seal in the center.
) and then casts the Seal in the same direction but at fixed distance from the center (or feet to be exact). Doesn’t take perspective into account unfortunately but still works fine as you can see in the video.
Got my redesign “mostly” all done.
Bundled both the .ahk and a compiled .exe in the .zip
Switcher.zip (531.8 KB)
It’s kinda commented (or I guess you could say “sectioned”) a little better now. At least a lil easier to read. I’ll probably be expanding on the app more from here now and I think i’ll end up eventually making the AHK version my official version at some point.
Been failing with writing an idea of mine: Auto buff-chaining. E.g. Overguard [OG] and Ascension [Asc].
Whenever GD window is open, OG shall be pressed once, after 10 seconds Asc shall be pressed, repeat.
I run into several problems, of course.
The thing must work, even when I press ESC in between, or minimize the GD window, or if I cast one of both manually in between, or if they extended their cooldown by some effect.
(Re)starting the chain manually (by hand input) would be fine for me. But I think it wont work if there´s no such thing as a “global time”.
Like:
Settimer, OG, -1
OG ()
{
send (overguardbutton)
settimer, Asc, -10000
}and so on.
That 10000 up there must be hard, absolute, seconds.
Because if for some reason, OG is called again before 10 seconds run out, the timer for Asc will be reset and a gap in between the buffs will occur.
Can one implement hard, absolute seconds in AHK?
Or, of course, does someone have a better, working idea for this?
Sorry but I’m not super concentrated at the moment so you want 10 seconds gap between them but if you press one of the skills manually earlier then the 10 seconds gap should be counted from that moment of pressing, right?
Or do you want
no matter what?
I think you want the second version, right?
As far as minimizing and ESC I think it’s double but maybe let’s start from the basic version.
Explain to me why the code you wrote doesn’t work for you so that I better understand it. There is absolute time in AHK but I don’t think it’s necessary because you can have the timers you wrote running infinitely no matter if Grim Dawn is minimized or something
the latter, yes.
It doesnt work because if OG() is being called more than 1 time every 10 seconds, Asc timer will restart. Asc timer then begins counting from -10000 again. This leads to a gap bigger than 10000 ms.
Why is OG function called more or earlier? I though it should work automatically?
Sorry for being dumb if it’s a simple thing to get 
Nvm, it’s a tricky thing I think. Let’s say og is casted. Then I pause the game or similar. 10 seconds pass, the script casts Asc. I re enter the game, and Asc is ofc not being cast cause I’m completely off sync. I need to manually re cast one of the spells to get the chain running again. But if I do this, I add another 10s to the already past seconds of the delay. The delay widens. Bad. Maybe an absolute time won’t help either, dunno.
ofc i can just wait and things will probably fall into place again.
but what if i dont want that, because ill die when i come back from a paused game without ascencion.
Minimizing the game is not a problem. It could be solve by adding an IF to every timer before every SEND and it would mean that those skills/whole chain need to be buffered/cast when the game is active again. Let’s not think about the details because I think it can be done and can be tweaked if needed.
However pausing the game with still active game is trickier but I think it can be done too just let me think a minute.
[edit] Ok, what if you always PAUSE the game with the same key, for example P or ESC (I mean both wouldn’t be a problem either)? Then we know if the game is paused or not and the situation is the same as in minimization/not active game.
Yeah, if the game is paused or minimized then the skill that would have been casted is waiting/chain is waiting in that moment so that when you unpause/unminimized the chain is carry on from this skill that should have been cast but was not because it detected pause/not active game.
I’ll make a draft and test it. It’s going to be a simpler version that assumes you always pause before minimizing
[edit] I think I’ve made some mistake in my thinking if think there’s no way to avoid measuring time because after resuming/unpausing the game the skill cannot be cast too soon because it can be on cooldown, fuck. Still doable I think
[edit2] Ok, got some code, now I’m testing. My testing char is Warlord at the moment lol perfect
Thanks for the effort!
Thought about it during gardening. Saw no perfect solution. Im curious.
bind the 1 and 2 to Ascension and Overguard, P to Pause, run the program and see it alternating between two skills; pause, wait ~ 10 seconds, unpause and see that the appropriate skills is cast when it should, as if there was no pause [time gap between pause unpause needed]
when you PAUSE after some time it tries to cast skill as if game was not unpaused but it knows the game was paused so it measures time from Pause to the moment skill would be cast and after you unpause it wait that amount of time
when we unpause we use calculated time_to_wait and skill_to_be_cast; these values are calculated during Pause so w8 a little while (maximum skill_delay waiting time needed) to be sure they are calculated in Overguard or Ascension function
P should be bound to Pause in game, it probably won’t work if you pause/unpause very quickly, one after another, it needs to wait in Pause state for when Ascension/Overguard would be cast to measure the time it should cast after you unpause
TLDR of above - wait like 10 seconds or sth after you pause before you unpause
A_TickCount is current time in milliseconds
Return in Timers stops them from going
the MainLoop and hack_applied is my workaround for P/Pause hotkey not working for some reason, normally I need to Suspend On + Suspend Off to make it work but this loop and hack make it work automatically, I have the same problem in GDAutocaster, don’t pay too much attention to it
I’ve tested the program and it worked - I mean the skill after unpausing was cast just when it would be cast if there was no pause. You know, in Cairn time, not real time.
the program could be further modified so that you don’t need to Pause before ALT + Tabbing or so that you can Pause/Unpause in quick succession but I don’t have strength to program this complicated logic + I think this quite ok already
I maybe I’ll try to modify it so that you can pause/unpause in a quick succession it shouldn’t be that difficult now that I think about it
looks promising! Mainloop is confusing though. Gonna try it later ! 
Don’t try it, I’m going to post a better and simpler version soon. MainLoop hack going to stay though but the program should work without theoretically it has nothing to do with it just fixes hotkeys not working for some magical reason I have yet to figure out.
