Jump to content

Photo

PC Multiplayer Control Fixes w/ AutoHotKey


  • Please log in to reply
18 replies to this topic

#1
randomfoo

randomfoo
  • Members
  • 417 posts

I spent some time today writing some fixes for MP controls w/ AutoHotKey.

 

For those unfamiliar, AutoHotKey is a scripting layer for Windows that allows keyboard customization among other things. It's free and open source and the latest version can be downloaded here: http://ahkscript.org/

 

My script is available here: https://gist.github....e623227e63ac0be

 

Happy to take suggestions/requests. If there's enough demand I can move it to a repo for collaboration.

 

What it actually does:

 

Dragon Age Inquisition Multiplayer Key Bindings
---
You should map WASD (from WQSE to movement).
These tweaks should make DAI easier to control.

What the script does:
* MB4 toggles RMB down/up (freelook)
* Caps lock toggles sprint
* Left Windows key disabled
* Right Control toggles mute for your own microphone (See comments on how to assign the proper mixer)

For more info, see: https://github.com/lhl/damp_ahk


  • Peer of the Empire, veramis and 21T09 like this

#2
Zorinho20_CRO

Zorinho20_CRO
  • Members
  • 3,252 posts

Is AHK safe to use with this game?



#3
21T09

21T09
  • Members
  • 498 posts
That sounds good!
I ll give it a try, instead of the controller.

#4
randomfoo

randomfoo
  • Members
  • 417 posts

Is AHK safe to use with this game?

 

Generally, from ME3MP, staff was pretty cool w/ modifying keybindings so I don't think it should be a problem - these fixes probably just make it about on par w/ the controller.

 

I just played a bunch of hours w/ this script and it seemed to work ok. The only issue was tracking the status of the keybinds. I may also add sounds to the toggles. Also, one thing that's weird is that for the sprint, it seems to also enable autorun which was a bit weird. Not holding RMB definitely reduces RSI.

 

Since the RMB toggle is used so little (really once a round) I may move that to a keyboard key so that RMB can be used for targeting grenades if necessary...



#5
21T09

21T09
  • Members
  • 498 posts

Since the RMB toggle is used so little (really once a round) I may move that to a keyboard key so that RMB can be used for targeting grenades if necessary...


Great idea!

#6
Blackstork

Blackstork
  • Members
  • 629 posts

Generally, from ME3MP, staff was pretty cool w/ modifying keybindings so I don't think it should be a problem - these fixes probably just make it about on par w/ the controller.

 

I just played a bunch of hours w/ this script and it seemed to work ok. The only issue was tracking the status of the keybinds. I may also add sounds to the toggles. Also, one thing that's weird is that for the sprint, it seems to also enable autorun which was a bit weird. Not holding RMB definitely reduces RSI.

 

Since the RMB toggle is used so little (really once a round) I may move that to a keyboard key so that RMB can be used for targeting grenades if necessary...

this would be sweet

i am holding with sp till BW fixes PC controls, and want to play MP for now, and such change (grenade targeting) for RMB would be nice thing to have indeed



#7
Zorinho20_CRO

Zorinho20_CRO
  • Members
  • 3,252 posts

Just to be sure,I bought Xbox 360 controller.

At least,as I heard that is one of the better on the market.



#8
21T09

21T09
  • Members
  • 498 posts

Thanks for the work randomfoo, it s very nice :)



#9
KevTheGamer

KevTheGamer
  • Members
  • 1,172 posts

Am I the only person who gets annoyed when the left windows key doesn't work in a game? I use it to get to messages I get on Steam when I am playing a game in origin 



#10
randomfoo

randomfoo
  • Members
  • 417 posts

Obviously anyone can modify or remove/comment out the parts they don't want. It's pretty modular, each section for each keybind is commented!



#11
Reginald Cousins

Reginald Cousins
  • Members
  • 119 posts

Love it! Thank you.



#12
randomfoo

randomfoo
  • Members
  • 417 posts

I've made some updates to the script that should make it work a little better

  • I've removed the RMB toggle since it's togglerarely but can interrupt w/ AOE targeting. I've mapped it to backspace and MB4, which means you can easily toggle, and then use the RMB regularly for AOE targeting
  • I've added the toggle sounds for all the toggles since it's so damn useful
  • I fixed a bug of a missing return that was making the LWin key not being disabled properly


#13
randomfoo

randomfoo
  • Members
  • 417 posts

Just a quick update after playing using this script for a few dozen hours:

  • Moved toggle run to Caps Lock - this also gives the advantage of having the light on when you're running, but I found it to be easy to reach and then let me use Shift/sprint for fine actions. Also, the main impetus was that I was typing in all caps in the Origin overlay, which is now fixed :lol:
  • Similarly, I removed the Backspace binding for freelook toggle - that was silly.
  • I added some toggle cleanup so that when you hit Shift or RMB it resets the toggles so the next time you click Caps Lock or MB4 it turns things back on. Among other things this makes AoE considerably easier.
  • I was trying to change LWin to bring up the Origin Overlay but it does some weird stuff with input listening and I'll leave that as an exercise for anyone's interested. I ported the gist to a full repo, so will take pull requests if anyone's motivated enough or can send pointers.

BTW, a few other keyboard mapping notes (outside of AHK)

  • I always put a potion in 5 and mapped that to Q
  • I try to put my evade in 4 and have that mapped to E

Overall seems to make life more pleasant.



#14
Falkiner

Falkiner
  • Members
  • 8 posts

Nicely written script, with the modularity and comment-references. Your sprinting implementation doesn't work, though. For MP Bioware just imported the horse 'giddyup' function from SP, so you can't just hold down Shift to keep sprinting. If you jump or run into anything, including other players in the lag-dance, even momentarily, your sprinting ends and you have to hit Shift again.

 

Below is an outline of an effective sprinting implementation. There's a key to toggle autosprinting, which enables and disables sending Shift every 100 milliseconds, so even the frequent collisions of the lag dance won't knock you back into walking. Pressing Shift also disables the timer-loop, giving you a single Shift-press. In addition, while you are standing still the timer-loop stops, and restarts as soon as you begin moving. Basically, if you turn on the toggle, you never have to hit Shift again.

; Sprint Toggle
PgUp::
    sprintToggle := !sprintToggle
    if (sprintToggle) && (GetKeyState("w", "P") || GetKeyState("a", "P") || GetKeyState("s", "P") || GetKeyState("d", "P")) {
        SetTimer KeepSprinting, 100
    }
    else
        SetTimer, KeepSprinting, Off
return

; Sprint when moving if toggled
~w::
~a::
~s::
~d::
~Space::
    if (sprintToggle) {
        SetTimer KeepSprinting, 100
    }
return


; Stop sprinting when not moving
~w UP::
~a UP::
~s UP::
~d UP::
    if !GetKeyState("w", "P") && !GetKeyState("a", "P") && !GetKeyState("s", "P") && !GetKeyState("d", "P")
        SetTimer, KeepSprinting, Off
return

#UseHook    ; Prevent the following hotkey from calling itself
; Sprint once  
~Shift::
    SetTimer, KeepSprinting, Off
return
#UseHook   Off

KeepSprinting:
    IfWinActive, ahk_class Dragon Age: Inquisition
    {
        Send {Shift Down}
        Sleep 10
        Send {Shift Up}   
    }
return

Some other miscellaneous pointers ...

 

SetTitleMatchMode, 2   Can be problematic, especially for a script that others might use. If a user has a document (notepad, spreadsheet, etc.) open that is similarly titled, you're going to run into problems. SetTitleMatchMode, 3   is a better idea, as well as using the ahk_class title. (#IfWinActive ahk_class Dragon Age: Inquisition).

 

It would be good to add functionality to your RMB scripting that releases the button if the user alt-tabs, or switches to another application another way. This relieves the user from having to remember to toggle the RMB off before switching applications. Even better would be to re-enable the RMB conditionally when switching back to DA:I. Here's a scriptlet that does that:

Loop {
    WinWaitActive, ahk_class Dragon Age: Inquisition
    if rmb {
        Click down right
        SoundPlay, %A_WinDir%\Media\Windows Hardware Insert.wav
    }
    WinWaitNotActive, ahk_class Dragon Age: Inquisition
    if rmb {
        Click up right
        SoundPlay, %A_WinDir%\Media\Windows Hardware Remove.wav
    }
}

Lastly, the problem of Shift carrying over to the overlay is a bit of a challenge. The overlay seems to be completely immune to Autohotkey -- while it's active as well as calling it and dismissing it. You can have a hotkey that adds a wildcard to F1, then match onscreen colors to determine if Shift+F1 was presed or just F1 (the overlay has distinct colors to match). Something like this ...

; On opening Origin overlay, stop sprinting, and on 
; closing the overlay, resume sprinting if toggled on
#UseHook
~*F1::
    PixelGetColor, pcolor1, 869, 26
    PixelGetColor, pcolor2, 865, 26
    if (pcolor1 = 0xECECEC && pcolor2 = 0x3B3B3B && sprintToggle) {
        SetTimer KeepSprinting, OFF
        Keywait, F1, down
        if sprintToggle {
            SetTimer KeepSprinting, 100
        }
    }
return
#UseHook   Off

This doesn't quite work, though. I'm still working on it (obviously the PixelGetColor coordinates will vary by monitor size). Hmm, I suppose putting the color-check into the KeepSprinting subroutine (which runs every 100 milliseconds if toggled on) could prevent sending Shift while the overlay is active.



#15
randomfoo

randomfoo
  • Members
  • 417 posts

Thanks for the AHK tips Falkiner. I dev for a living, but I'd actually never touched AHK before writing this script, so it was what I cobbled together from a few hours of searching (there's a tremendous amount of code/docs, sadly mostly scattered in forum posts). Also, the improved sprint looks good - I wrote this pretty much in the first day or so before understanding the sprint mechanics - I'll inline it and your other suggestions when I get a chance (although honestly, I've stopped playing MP until patches fix the connection issues - even then, DAMP is nowhere near as fun as ME3MP was).

 

Curious if you know - does PixelGetColor work w/ all DX/D3D screens/overlays? A quick search seemed to be ambiguous: http://www.autohotke...g-gui-overlays/ (but that was from 2011 as well, so things may have changed) - sadly, I haven't found good logging w/ AHK. What I'd give for a good remote console or even a basic syslog (I have Cygwin so I could SSH in from another machine and tail that. It'd be nice if there was a way to HUP/restart AHK from the CLI as well? You can see that most of my debugging was based by testing in Notepad.)

 

If so and if performance isn't terrible it could do all kinds of things like automatically releasing the RMB not just on switching windows, but also potentially on game state (ie, in single player, the worst thing is that when you go into menus/looting you have to manually switch off the RMB toggle). You could probably do some fancy math to match pixel location based on resolution, either with a ratio or worst case, with a resolution-specific switch.



#16
Falkiner

Falkiner
  • Members
  • 8 posts

Your script is a great result for having just taken a look at AHK. AHK is really a rather powerful scripting environment and it's been around for a long time, so there is, indeed, a lot of (scattered) material to work with. A lot of forum code snippets are quite well engineered; a lot are not.  You can find forum posts with code that are a decade old, and some of these are still useful while some are not. The help system is actually a fantastic resource for those who want to write bug-free scripts and understand the nuances and deep possibilities - it's comprehensive and easy to use. For an experienced coder one good approach is to browse through the topics to see what AHK can do -- a process that doesn't take long -- then use the help's search function and web searches to find a starting point with any novel scripting challenge.

 

My sprinting script needs a bit of tweaking. I'm finding that the reenabling of autosprint has an odd delay occasionally, almost surely the result of mouse-button and key combinations that naturally occur when in combat.

 

I haven't played ME3MP, but I have heard that DAMP suffers in comparison, and it's certainly true that DAMP needs some technical fixes and content expansions. From what I understand ME3MP was in somewhat the same circumstances at its own launch, and there's continuing interest at Bioware to keep developing DAMP. We'll see, I guess.

 

I have not run into problems with PixelGetColor and DX/D3D myself, but I use PixelGetColor only occasionally. Problems with DX games recognizing hotkeys are more common than problems with PixelGetColor, and there are workarounds for hotkey problems. Only quite rarely do I encounter a game that refuses to play nicely with AHK. (The Origin overlay is such an example, though I have not tried every recourse yet). And yes, PixelGetColor is quite powerful. If you can identify reliable color changes to detect you can respond to in-game events. What you describe is precisely what I've been planning to do with single player. I haven't started that process yet, though detecting colors in the overlay works fine. While it's obviously possible to create a very resource-greedy script, with modern systems you rather have to go out of your way to do it. AHK does allow you to set priorites for threads, among other threading options, if you really want to tweak performance, but I've never had a performance problem springing from a script I wrote.

 

You can, indeed, do some math conversions for a script that is to be used by users with differing resolutions, but the various possibilities somewhat discourage this approach (windowed? borderless fullscreen windowed? Some random window size? borderless can change things by just a pixel or two, or not.) It can depend on just how precise your PixelGetColor read needs to be, keeping in mind that selecting very specific pixels to read is often the key to detecting in-game events reliably. Also, without examining other resolutions yourself you cannot be sure that they scale in a mathematically uniform manner witout exception. A possibly less tedious and more reliable (and certainly more popular) apparoach is to include a GUI that prompts the user to click a specific screen region, then saves the coordinates (AHK provides GUI support, and other tools make GUI creation even easier with AHK.) Or you can just direct users to use WindowSpy themselves ... teach a man to fish ...

 

Debugging AHK is not, I'm afraid, comparable to a modern IDE or professional development experience. If you are not yet using SciiTE4AutoHotkey as a script editor, I recommend you download and use it. Among other significant benefits, it does provide a limited but functional debug mode. Still, for most longtime AHK users Tooltip and MsgBox remain useful testing tools, with occasional recourse to Notepad for simple checks. I know of no good logging or console functionality. HUP would be nice; AHK doesn't have such features.

 

Incidentally, it's best to direct new users to ahkscript.org, rather than autohotkey.com. Autohotkey.com supplies a legacy version of Autohotkey, while ahkscript.org offers the latest version. The schism has its roots in, alternately, personal drama, differing development goals, or a conflict between best practices and a self-serving agenda. You can get more info about it at ahkscript, if you like. The most important detail is getting the best version of Autohotkey, which is unquestionably hosted at ahkscript.org



#17
randomfoo

randomfoo
  • Members
  • 417 posts

Gotcha, reading the crazy AHK drama now. Fun stuff. I've updated the first post to point to the ahkscript.org page.

 

I just finished my SP playthrough, and like I mentioned, won't be playing much MP until/unless there are some patches, so adding to this script is pretty low on my priority list, but I'm happy to either take pull requests or add collaborators on the github repo, or if you (or anyone else) get something online, also happy to point/link to that in this post and my README.md.

 

The forum sticky says that Bioware is aware of the PC control issues, but considering that over years of development they couldn't implement something sensible, I have my doubts on how/when they'll fix things.



#18
Falkiner

Falkiner
  • Members
  • 8 posts

I hooked up with the Bioware Social Network Teammate Finder group, which runs a couple of chatrooms and resolves for me a lot of the connectivity issues I get when PUGging. I'll play MP a bit more, at least until I get my script working right and feel readyish for a Community Event. So I'm still tinkering with my script, and will post a final version at some point, and update the snippets here. And I'll probably work on those single player RMB-lock issues before I return to the campaign.

 

Like you, I'm not sure how much committment Bioware has to de-consolizing the PC UI, but I'm also keenly aware of the power and flexiblity of the PC platform which allows external solutions not available for consoles.

 

For PC, there's now a hack to fix (mostly) the tac camera zoom problem. The RMB "problem" is almost certainly solvable with AHK for both SP and MP. We have effective if not comprehensive microphone fixes: your mute toggle and a not terribly dissimilar PTT which I wrote and will put on Reddit shortly. I surely would like to be able to look in one direction and move in another, but a solution for this on PC is probably going to have to come from Bioware (I'm not holding my breath). I'm not bothered by the lack of an autoattack, and a bit puzzled at the demand for one -- why would i want less interactivity with the world? But an Autohotkey fix is certainly doable -- that is, it's possible to write a script to autoattack your locked target beginning with a keypress and ending with the target's death.

 

I'll have the sprinting problem solved shortly, though it's notable that this is a cross-platform problem. The tac-camera pan-on-mouse-edge that I and many people want is also very doable with Autohotkey. People complain about the inability to reassign all keys effectively, but this can be tackled with a variety of software and hardware options. There really are only a couple of PC Control issues for which we absolutely need Bioware's cooperation.

 

Of course, it would be great if Bioware handled some of these issues themselves in a timely fashion, but I think they'd be wiser to fix all the ability and effect bugs and the netcode first.

 

I'll message you with any links to scripts I finsh that you might want to add to your posts and pages.



#19
silksieve

silksieve
  • Members
  • 166 posts

Hi--

 

Could you direct me to your mic fixes? Or are they in the script? I've been having problems getting DAMP to read my mic.  Thanks!