[Tool] AutoHotkey scripts

Initially with just

if WinActive(“Grim Dawn”)

it was very bad because it was True even if using Grim Tools (because the window is called Grim Dawn Tools)
Fortunately using

SetTitleMatchMode, 3

makes it match precisely (not prefix) but the program still thinks it’s in game while I have a folder called Grim Dawn active while the game’s minimized :slight_smile: so if user has some autocasting going on and Alt+Tab and then opens Grim Dawn folder, (s)he’ll be hearing this specific unpleasant Window sound with a frequency of this autocasting :slight_smile: In the end, it’s not a big issue. Still the Process function will solve this issue for people that turn off the game.

Excuse me, I’m really interested in this, but it says “outdated” - is there a better version than this, and where is it? Many thanks.

It’s fine. It’s outdated/not appropriate for combining it with other scripts/merging into some other AutoHotkey program but as a standalone program it’s working just fine.

I’m planning to merge it with the following program (it’s gonna take me some time) and add many configuration options like which button you need to hold or should it work always, the size and shape of the inner region where it doesn’t work and also the segment around 12 o clock where it doesn’t work (rectangular, ellipse, circle). For now you need to mess up with the code if you want to change those values)

Oh, and there’s compiled .exe version in the following post if you don’t have AutoHotkey installed


and also there’s this

but it has been merged into GDAutocaster and this program should be used instead.

Thanks very much, very helpful! Just getting into this. I got the AHK version working and it’s nice.

But the problem with this I find with all AARPGs, they just have this “traditional” way of point-and-click, or point-and-follow movement, which is fine but it begs a top-down isometric view. But the graphics are so lovely in this game that I keep being tempted to go to the close-up view (NUMPAD1) - but when I do that, I want the damn thing to work like an action MMO with WASD and mouselook :slight_smile:

I think I might try the fast rotate, see how that goes!

I like close-up view too, even if it’s not optimal. I feel more immersed that way. Also playing GD with a controller is awesome but I currently don’t know how to use AHK with it.

To try fast camera rotation you can also download [Tool] GDAutocaster - autocasting, faster camera, hiding items on the ground and more!
and run in with just the following GDAutocaster.ini config

[camera]
angle=60
counter_clockwise=a
clockwise=d
rotation_key=k
delay=40

Just tried it! Yeah that setting works very well for close-up. It’s a bit sluggish but works well enough for that close-up dungeon-crawl atmosphere. Thanks again, I’ll try fiddling around with the autocast options too.

Now that I remember, from playing GD ages ago, I remember a discussion on the forum - “why can’t we just have WASD and mouselook as an option?” and the developers seemed adamant to maintain the traditional system - although I can’t see why, if they’re offering such a great, almost over-the-shoulder look anyway. sigh oh well, we make do :slight_smile:

If by sluggish you mean like in the following video (checking if you don’t have any performance issues)


then yeah, I cannot make it any faster because
  • manual camera basically holds a rotate key and moves the cursor just like you would do if you were doing it by yourself with a mouse (that’s why the cursor is blinking)

  • automatic camera hold rotate left/right buttons

so I use already existing camera rotation methods and would need to mod the game to make it faster

As far as WSAD and Mouse Look is concerned - they would have to specially develop this feature whereas what’s currently available was probably inherited from TQ. However they implemented controller so WSAD would definitely be possible but it would be a feature for a very niche audience I think (I mean not many players really need wsad on top of current M&K and Controller).

Maybe WSAD is possible with AutoHotkey. The way I see it is you would use Controller Mode but intercept the keyboard and mouse input and translate it to controller input.

Might be better to use Process Exist for the Grim Dawn.exe.

https://www.autohotkey.com/docs/commands/Process.htm

didnt i mention that above? :slight_smile: WinTitle covers that with its ahk_exe parameter. so basically

if WinActive(“ahk_exe Grim Dawn.exe”)

should do the trick. it wont mix it with an either same named explorer/folder window nor browser tab. if you want to be super sure, add the path. you may need to set the titlematchmode to RegEx to be more flexible here.

GrimInternals starts Grim Dawn.exe, and its running parallel as GrimInternals64.exe. So checking for “Grim Dawn.exe” should be totally safe.

1 Like

Ha, my mistake, I thought I had the prog on when I didn’t, what I was calling “sluggish” is the native mode of keyboard turning. Yeah, your prog makes the turning fast, but it’s now at the other extreme of being a bit too “twitchy” in numpad1 view for me (the speed is great for numpad2 and numpad3 views though).

That’s an interesting idea about intercepting the gamepad controls. My AHK experience in other games is limited to cobbling together Frankenstein’s AHKs from what I find :slight_smile: It sounds like you know the script very well.

Works perfectly - in-game but not in Grim Dawn folder! Thanks, I didn’t think it’s so simple.

Also I think that moving from Window title to process solved another problem I was having which is program sometimes not working just after starting it (needed to restart it or suspend on and off)

Nope, I only pretend by using words like “intercept”, “input” or “translate” in one sentence :wink:
Not sure how to do it at all or if it’s even possible.

Sketching my idea and implementation, hoping for synergies :slight_smile:
So, here we go. An simplistic imperfect idea/approach to dynamically hide items during combat.

  1. identify the mouse/keyboard actions, that seperate combat e.g from input in vendor searchbox
    since its a very individal thing that depends from playstyle and used binds, i just write how i did it in my case.

precondition: here: an autobuff/recast timer has to be running (and that thing only runs while outside town)

basetrigger:

  • shift+L/RButton casts
  • mousebutton 4/5 casts
  • manual Rbutton Doubletap (configurable timeframe, here 1500ms)
    (all of above, together with bufftimer usually doesnt apply when using searchboxes)
  1. establish a set of 3 different timers
  • itemshide timer
    (we chose timer to run the hiding in a seperate thread, so eg a sleep doesnt throttle the whole script and for other reasons)

  • itemsshow timer
    (everytime itemshide is executed, we start the itemsshow timer. means after its period, it reactivates the display of items on ground. the trick is: when a timer is prematurely restarted its restarted with full period. so we can use that behaviour to extend the basic period by just prematurely restarting it.
    so any other trigger action will extend the period items are hidden)

  • resetcombattrigger timer
    (a combartrigger is used as flag for combat. if this flag is reset, all combatrelated stuff is stopped, this includes hiding of items.
    some action dont qualify as direct hide trigger but we want them to extend the hiding period when in combat. that usually is the left mousebutton. so IF itemshide was executed and itemsshow timer is running, we can now extend its period for an fixed/limited amount. During this extended period items stay hidden, or theyll be shown finally again unless some of aboves trigger rince n repeat it e.g a longer fight

scenario:
-> mousebutton4 action (some pet attack command) - hide is triggered (my value here is 1600 ms til reappear)
-> we then use standardattack to finish of a small group of mobs, initual hiding timeframe extended by 3000 ms
-> if no further hiding trigger was executed, items reappear after 3000ms (+1600 counting from combat start)

since we use lbutton also for walking, it cant qualify as direct trigger (but we can ofc add a doubletap here too to)

as values im currently using

combatdeltatime = 1650 (time in ms after items are shown again, if nothing else happens)
combatresettime = 3000 (time we extend aboves value when using stuff that not necessarly qualify as combat action, but do in combination above)

works quite well, but there is still one problem: depending on area, runspeed and kind of mobs your combatspeed differs, means the time you stay in an area depends from the speed you kill things.

possible to do:

  • (auto) adjust aboves values by either interpreting a heatmap (small chance to implement)
  • adjust those values maybe via mousewheel?
  • [ any other idea ]
1 Like

Give yourself a break :wink: just as you require your scripts to be precise to the milliseconds, now you want the hiding items/combat detection algorithm to be 99% correct. My standards are much lower :wink: When I implement some kind of auto-hiding of items, I probably use only two timers and far fewer variables.

Could you explain further what you mean by these?

1 Like

basically im searching for ideas to adjust the timeframes things stay hidden on ground, depending on killspeed/difficulty of area.

the heatmap stuff means: recoding all key and mousebutton presses and creating some kind of automated statistic that concludes from changed key/mousebutton press intervals to the time the player stays in a given area (if you want call it some kind of very primitive AI) - all that to adjust the defaulttime the scrip hides items (those 2 combat variables in my aboves post) (total overkill, but fascinating)

the mousewheel thing: i looked for a way to change those 2 values manually with least effort as possible while ingame. eg when i see, “hm, items could displayed earlier” then maybe use the mousewheel to reduce the default hiding timeframe, or increase them when fights take longer.
but this shoudnt result in constantly worrying about the perfect hiding timeframe, so im not sure if this would ba a good idea in first place.

but yea, its overkill, right? :slight_smile:

edit: already made a mistake at recapitulating how the algorithm works. shit happens when stuff gets complex.
btw: totally inpedendent from the content that gets postet here. - mho the true gold is not to push own ideas, but to reflect about the own code. talking about how (own) stuff works makes you think about it - and that leads to better stuff.

1 Like

@tqFan

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.

image

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. :salt:

2 Likes

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).

1 Like

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.

2 Likes

@tqFan

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.

1 Like

Thanks, I’ll definitely download it next time I use AHK, even just for the code tooltips.

1 Like

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 -

1 Like