Okay, I did find a problem. Spamming the curses (rbutton) makes them go off so fast it drains my energy. Iād like them to go off fast when I press the key at first, but then less quickly when I hold the button or at least have a delay between groups of them. I can do it my self by just pressing and releasing rbutton every few seconds, but it would be neat to be able to just hold it down too. 
You mean the following combo? It goes only once
combo2=RButton:5,7,9,1
delay2=200
The stuff below is Storm Totem / Sigil etc I suppose
[periodic casts]
cast1=f:2,3,4
delay1=50
Yup. I was exacerbating the problem, by again having a power on rbutton (Devouring Swarm).
Holding f and rbutton is pretty draining, but not a realistic scenario, I think. What I was doing was trying stuff out on a training dummy. Iām going to have to try this out on some real enemies to see how it plays for real.
Yeah. On dummy energy drain is not representative to real fights because you donāt absorb energy etc.
Yes, a quick test on real enemies is looking pretty good. My fingers will be so much happier now.
UNRELATED TO YOUR CURRENT PROBLEM. READ IT IN FREE TIME
Ok, your config looks really fine. You may try some cosmetic things like the ones above.
Also Iām posting my config for my
at the end of the post. You can read it to maybe learn some weird techniques I use to have great intertwining of features of the program.
I mean some skills (i.e. which you spam by [autocasting] or [periodic casts]) not interrupting i.e. debuffs from [combos] or just a normal button click or [periodic casts].
Pick up Items spam
[periodic casts]
delay=100
cast1=PICK_UP_KEY:PICK_UP_KEY // (can repeat, no problem here)
Movement skill spam
(I remind that there should be only one [periodic casts] section and only one castN, where N is a specific number)
[periodic casts]
delay=100
cast1=PREFERRED_KEY_DISPLACEMENT:KEYBINDING_KEY_DISPLACEMENT
My config for the build I mentioned at the beginning for stationary Crucible fights
Vitality Storm Totem
[general]
suspend_key=Tab
capslock_remap=m // DON'T PAY ATTENTION TO THIS, IT MAKES CAPSLOCK
// BEHAVE LIKE A NORMAL KEY AND NOT LIGHTEN UP
[autocasting]
master_toggle=q // TOGGLES BLOOD OF DREEG, STORM TOTEMS, SIGILS SPAM - ALMOST PERMANENTLY ON
[periodic casts]
delay=100 // GLOBAL DELAY, IT'S USED WHEN YOU DON'T SPECIFY I.E. DELAY1=300
cast1=s:s // PICKING UP ITEMS
cast2=Space:6 // DISPLACEMENT SPAM
cast3=RButton:0,7 // STORM TOTEM / SIGIL SPAM TOO
initial_delay3=400 // THIS DELAY IS TO CREATE SPACE FOR DEBUFFS COMBO
// LIKE CURSE OF FRAILTY OR DEVOURING SWARM
// NOT TO BE INTERRUPTED BY I.E. TOTEM AND SIGIL
// IN THIS CASE SPECIFIC BUILD THOUOGH I DON'T HAVE COMBO FOR DEBUFFS
// JUST HAVE Curse of FRAILTY on RMB and DEVOURING IN PERIODIC CAST
// IT'S THE SAME THING THOUGH
cast4=RButton:8 // DEVOURING SWARM NOT SO SPAMMY SPAM
delay4=2850
[combo holds]
combo1=RButton:9 // LITERALLY PRESSED DOWN BUTTON FOR OBLIVION
delay1=400 // DELAY IS SO THAT OBLIVION DOESN'T INTERRUPT
// DEBUFFS COMBO
// IN THIS CASE SPECIFIC BUILD THOUOGH I DON'T HAVE COMBO FOR DEBUFFS
// JUST HAVE Curse of FRAILTY on RMB and DEVOURING IN PERIODIC CAST
// IT'S THE SAME THING THOUGH
[combo presses]
combo1=r:t,1,2,3,4,5,t // STANDARD PERMANENT BUFFS TOGGLE ON FROM 2ND HOTBAR
delay1=600
[0] // SPAMS STORM TOTEM WHEN WE DON'T HOLD RButton
toggle_key=0 // THIS TRICK IS JUST TO CREATE A GAP FOR DEBUFFS
delay=100 // NOT TO BE INTERRUPTED SEE ABOVE
not_hold_keys=RButton // I MEAN SPAMMING IN ONE WAY WHEN WE DON'T HOLD RMB
// AND IN OTHER WAY WHEN WE HOLD RMB
[1]
toggle_key=1 // BLOOD OF DREEG SPAM
delay=1000
[7] // JUST LIKE [0] BUT SIGIL
toggle_key=7
delay=100
not_hold_keys=RButton
[camera]
angle=60
counter_clockwise=a
clockwise=d
rotation_key=k
delay=10
[clicker]
X=1270
Y=230
button=Ctrl
Lots of interesting stuff there. My brain is about burned out now, but Iāll look at it more later.
Have you considered creating some documentation other than just the posts here? Iām one of those people who actually like to read the manual.
How do you think best documentation should look like?
I can only think of explanation of excessive config file with comments,
like in the 2nd part of OP. The tutorial below is unrelated to our conversation.
How to make skills that
- you autocast all the time
- have casting animation (i.e. Blood of Dreeg doesnāt)
- for example Wind Devil, Mortar Trap, Judgment
not interrupt your debuffs
[general]
suspend_key=Tab
[autocasting]
master_toggle=q
MAKES WIND DEVIL BE CAST ALL THE TIME IF WE DON'T HOLD RMB
BUT IT'S CAST IF WE HOLD RMB TOO DUE TO OTHER FEATURE LATER
[0]
toggle_key=0
delay=100
not_hold_keys=RButton
CAST SOME DEBUFFS 1, 2 ONCE ON RMB PRESS (I.E. COF & WOP)
[combo presses]
combo1=RButton:1,2
delay1=200 //DELAY BETWEEN DEBUFFS
SPAM SOME ATTACK 3 & 4 WHILE HOLDING RMB
BUT ALSO WIND DEVIL 0, ALL DELAYED BY 400
FOR DEBUFFS ABOVE TO NEVER BE INTERRUPTED
[periodic casts]
cast1=RButton:3,4,0
initial_delay1=400
delay1=100 // THE DELAY HERE IS BETWEEN [3,4,0] AND NEXT [3,4,0] PRESSED
// NOT BETWEEN 3 AND 4 AND 0 AS IT IS IN CASE OF COMBO PRESSES
scroll this text window down
To start off, let me say that I think what youāve done is awesome. Just the little bit Iāve done so far has made the game 10x less painful to my aging fingers and I probably wouldnāt be able to keep playing this sort of build beyond short periods without it.
For what itās worth, I spent 30 years as a software developer/designer. Iāve been retired for over 8 years, so Iām a bit rusty and while Iāve used and programmed Autohotkey in the past, Iām very very far from an expert. I did look at some of your code, but honestly, itās been to long and Iād have to spend hours on it to make sense of it, so figuring out the sort of stuff I mention below is not on my short list of things to do.
In regards to documentation, I wouldnāt mind seeing some documentation on the keywords and how they relate to each other.
For example, what are all the [section name] sections, what keyword= are valid in each of them. What are valid strings that follow each keyword=, etc. Some examples of thing I donāt know just from looking at examples, is what ākeysā are valid, is there an order to the sections and the keywords within the sections, what are the defaults for things like delay, how do things like multiple casts or combos on the same key press interrelate? I can pick up a lot of that by looking at all the posts, but I almost have to create documentation in my brain or in notes to keep it all together.
Documented examples are awesome, but by understanding how the keywords and sections interact, I would be better able to create my own uses.
To jump to something else, from what I read in some of the earlier posts, if I want to have different profiles (.ini files) for different characters, Iād have to make copies of the program with different names and matching named profiles. I donāt see any other way to do it, but I may be missing something. If there isnāt, would you consider either having a start-up input parameter with the profile name and/or a way to tell an already running version of the program to refresh with a new named profile? Obviously, this isnāt a critical need, but it would be very nice to have.
Thank you again for the program and for your exceptionally quick responses!
1 Like
Something I forgot that really needs documenting is what assumptions you make about keybinds. An example is that your program assumes that 1-0 are bound to skills. Iām sure there are others. For example, how about the camera rotation keys? It isnāt working right for me and I suspect it is because of my strange keybinds.
Edit- I figured out my camera rotation problem. All my own fault.
There does seem to be something off about the angle. Is it in degrees? 60x6 should rotate me completely around, but instead 8 times takes me just a little past a complete circle.
I sympathize with you having so much to read 
My hands are fine but just mastering pressing of buttons is not my thing. Also automatization is fun on its own. Controller is even better for ergonomy and you can even automate stuff just like in GDAutocaster in Big Picture (well maybe not that flexible but still very good):
Ā
Iām not an expert either and Iām bad at programming in general as well (I know nothing about design, havenāt studied it etc). Iāve only written a few programs in AHK and I donāt even know how youāre supposed to do it. But let me tell you some things only look complicated or are complicated because they had to be because I didnāt figure out how to make it better or because I felt like they should be done in a particular way even though I didnāt understand them. Iāll explain shorty some complicated things. I donāt mind if you donāt want to spend time on it:
-
HotkeysCollector.ahk
This weird class is so that I can define multiple hotkeys throughout the code (i.e. multiple RButton:: /some code/ [these hotkeys are defined dynamically though, using functions like Func and ObjBindMethod, and they thrown into the dictionary / object and executed one by one when you press an appropriate button. -
All the classes and files. At some point everything was literally in one file. But it got too big for me, especially since I donāt use any IDE. So I fortunately figured out a way to separate all the code into files and āclassesā and itās just so that the code is readable. To create functions ready to be thrown into HotkeyCollector I use this ObjBindMethod function.
-
MainLoop in GDAutocaster.ahk
Normally for a program to work only in game you do something like this
#IfWinActive ahk_class Grim Dawn
It never worked well for me though so the whole big ass loop is for as good as possible blockage of the program when itās supposed to not be working and suspending on demand.
(by the way I should really extract some more code from this file into other files to make it more readable).
Also remember that you can use GDAutocaster with other games -
All the weird timers in the code and splitting functions into multiple parts and those parts run from timers
fn := ObjBindMethod(this, "PeriodicCastInitialTimer", pressed_keys, held_keys, delay)
SetTimer, %fn%, -%initial_delay%
Most of these because Sleeps block some parts of the program and donāt work well whereas timers work flawlessly. They do make the program much harder to comprehend, especially if you literally split a function into two because you want to put a timer in the middle of it.
Ā
Just as I said, Iām a bad programmer, Iāve never really written a documentation 
And Iām not a quick learning person. However all keywords & sections should be here GDAutocaster.ini and almost all are optional.
Ā
Almost all possible sections are constant and can be seen in the representative extensive config file GDAutocaster.ini
The rest / exception to the rule are the [0], [1], ā¦ [9] sections. They are for the 1st feature of autocasting (the other one is [periodic casts]). By default you have 0 - 9 buttons pressed and [0], [1], ā¦ [9] possible to be read by the program. But you can overwrite that and have different buttons pressed and sections possible to be read by the program in the following way
[autocasting]
pressed_buttons=q,w,e,1,Tab
Then youāll have [q], [w], [e], [1], [Tab] sections available to read.
Ā
For
- [combo presses]
- [combo holds]
- [center casts]
itās comboN=X:Y1,Y2,Y3,ā¦,YK
(or castN in case of [combo holds])
For [periodic casts] itās
castN=X1,X2,ā¦,XK:Y1,Y2,Y3,ā¦,YL
Ā
All keys should be valid. There maybe some weird cases that if you repeat the same button in multiple features across multiple feature or maybe in the same feature in a form of Key:Key it may not work. But I put a lot of work for that not to be the case.
Ā
I donāt know the specifics (I havenāt seen documentation ont it) but I can tell you this:
-
sections can be in whatever order
-
but there should be only one section of a particular name
-
keywords can be in whatever order
Ā
All the defaults used in the program should be here Defaults.ahk
However I think itās best (well I do that) to just specify them, i.e.
[periodic casts]
delay=100 //global delay for all the casts
cast1=Tab:Space
delay1=200 // unless you specify otherwise as follows
Ā
They all should work. This is thanks to HotkeysCollector.ahk I mentioned before. You should assume they all start working at the same moment. All the (initial_)delays are for to make it work in-game and skill animations not interrupt each other. But you can always try simpler config without too many delays first and it may still work well for you.
Ā
Sorry for no good documentation. I would prefer not to spend my time at the moment for that because I can easy get overwhelmed and stressed out since Iām a perfectionist very focused on details and not the grand picture and Iām scared I would not be able to stop. Iām not good at doing things quickly and leaving them when theyāre good enough.
Ā
With this method multiple instances of the program could run simultaneously if you forget about it and it could pose the problem. Sure I could use that too and some people already asked for that. Personally I use command line and when I want to use some config file I just copy it to GDAutocaster.ini and restart the program. Iāll think about something.
Ā
The 1st feature of autocasting kinda assumes that (but you can overwrite this). I explained it earlier in the post in detail.
Ā
I use 60 degrees. The thing is my intention here is to not need to ever be aligned with North.
60 degrees is a perfect angle for me to quickly change the angle I approach the monster and I donāt think I care too much if Iām not perfectly aligned sometimes.
Although I admit to correcting the camera slightly at times.
Iām not sure if this is fixable to be honest because itās a hack honestly.
You know that itās working by literally dragging the cursor at the bottom of the screen
(literally mouse rotation - you just donāt see the cursor too much because itās so quick and at the bottom although you can if you look well enough
However 8 times 60 just past a complete circle? Seem way too much off. I donāt think Iāve ever had anything like that. I though there could be only minor errors. Is your resolution 16 x 9 (although I donāt remember the code and it it makes any difference). Iāll look into the code now.
Ā
Btw the rotation works in a very simple way:
It drags the cursor on the bottom of the screen by
SCREEN_WIDTH * ANGLE / 180
pixels in the appropriate direction (from left to right or in reverse)
Like it would if you were to do it manually.
Possible solutions to your problem
-
maybe youāre pressing it to quickly one after another
-
maybe your fps is bad (it influences the rotation I think) I try to have close to 60 FPS
-
maybe you can try increasing the delay parameter, i.e. from 40 to 80
(it should be as low as possible provided itās still working well) -
or maybe I should implement a scaling/correcting factor in the config if itās not working correctly for you for unknown reason, what do you think?
I tested it myself and 6 x 60 is just a bit over 360.
RE: rotation
My screen resolution is 1920x1080. I tried slow presses and changing the delay. Not change. It is pretty consistent that a press with angle at 60 is a little over 22.5 degrees (2x presses gets my just past 45 degrees of turn).
RE: Documentation
Yeah, documentation is definitely a rats nest. I think a lot of what gave me problems is the additions and just making sense of the whole thing since stuff is spread out throughout this forum. I can easily understand why you donāt want to jump in to it.
The annotated stuff you have in your original post isnāt bad, although incomplete. If you had that for all of the possible sections and keywords (including the newer stuff that isnāt in the OP), that would go a very long way. The .ini file you linked is great, except since there arenāt any comments explaining it, one still has a lot of puzzling out to do.
RE: other stuff
Speaking of comments in the .ini file, is there a way to put comments in that are ignored by GDautocastre? I tried ā//ā, but that didnāt work well as I started getting error messages from AHK.
I think Iām starting to get a handle on this stuff now.
Hereās a newer version of my .ini file for that same character build:
[general]
suspend_key=Tab
[autocasting]
master_hold=`
master_toggle=`
[camera]
angle=60
counter_clockwise=Numpad7
clockwise=Numpad9
rotation_key=Mbutton
delay=40
[combo presses]
combo1=h:y,0,9,8,7,y
delay1=650
combo2=RButton:5,1,7,9
delay2=100
combo3=f:4
[periodic casts]
cast1=f:2,3
delay1=100
initial_delay=100
cast2=f:4
delay=4500
initial_delay=4500
cast3=RButton:5,1,7,9
delay=500
Initial_delay=500
[6]
toggle_key=t
delay=15000
I had it all commented, but as mentioned above, I had to delete the comments.
Uploaded
https://github.com/kowariantny/GDAutocaster/raw/master/GDAutocaster.exe
I literally deleted one line and put
FileSelectFile, config_name,Select Config File,Configs (*.ini)
instead
You may want to add a command line switch so that the old behavior is available for compatibility, otherwise this is awesome.
The program is compatible with the previous version though. It will work with the previous config. Besides who would want that. I mean if you want it or some other person, then sure Iāll add but until then Iāll skip. Would you use it?
If someone only has one configuration or doesnāt want to have to deal with selecting a .ini file from the directory every time, why make them spend the extra time on it?
In my case, since Iāve been making incremental changes to one config file over and over, it would just be a bit faster to just use that as the GDAutocaster.ini file.
Another alternative would be to see if there is a GDAutocaster.ini and use that if there is, but if there isnāt, ask what .ini to use.
I tested
cast2=Space:6 ; test
and
cast2=Space:6 //test
and it worked really badly. I have T for swapping Hotbars and it really swapped them when I pressed Space
So I guess the only way is just whole lines of comments like this (it works)
[periodic casts]
MOVEMENT SKILL
cast1=Space:6
SAVAGERY
cast2=RButton:6
delay2=1900
btw I donāt have control over how config is read. I just use IniRead function and it does everything on its own.
https://www.autohotkey.com/docs/commands/IniRead.htm
Iād also use the behavior where it asks for a .ini file, since I do have multiple builds Iām playing. This is just the only one Iāve tried GDAutocaster upon.
Thinking of that, is there a way to have a key that effectively presses and holds āforced moveā while executing one or multiple skills? What I want to do is be able to use Vireās Might, but since by default that will hit a target if one is near the cursor, I virtually always want to do a forced move to go past any target and move all the way to the cursor position, leaving the fire trail behind.
Iāll add no_dialog flag or something
To the Vireās Might thingy - I need to do it in-game because I donāt think Iāve ever done anything like that / fully understand what you saying. Also never used Forced move in Grim Dawn. But yeah, I should be possible just let me try it in-game normally.