Hi, I have several issues related to the old DOS FPRPG Amulets & Armor. I'm trying to get it more convenient to play (more like a modern FPS with standard features like always-run, dedicated strafe keys, etc. - it's pretty much Wolfenstein 3D-era controls as-is, with the addition of Ultima Underworld-style mouse input.) However, I've run into several obstacles in the attempt. They seem independant of the game itself, as the issues in question also occur at the DOSBox prompt, etc.

I've tried to use AutoHotkey Basic to map a key to perform as a sticky/toggle run/strafe modifier, the only problem with which has proven to be that for some reason DOSBox doesn't see key actions AHK sends to it. I've tried a wide variety of AHK's send methods, as well as altering usescancodes= and priority=, but DOSBox simply doesn't see what AHK sends it (despite non-DirectInput apps seeing input from AHK fine - other DirectInput apps like vanilla Quake 3 have similar, yet not identical, trouble with AHK input.) A couple other people have confirmed for me that in their freshly-installed Win98SE VMs, DOSBox DOES recieve input under the same circumstances, so it's not the DOSBox or AHK versions involved doing it. If AHK were capable of sending input to DOSBox for me, it would likely be able to handle all my needs regarding AA. I need to send it lasting key down and key up events, but no events at all get recieved - not even trying to 'type' normal text in the prompt, e.g. 'help' followed by enter. In DOSBox's case, this applies even if DOSBox is windowed; Quake 3 accepts AHK input when windowed, but not when fullscreened. There are a few minor issues with AHK's reception of keystrokes, but nothing I can't live with; it's sending them to DOSBox that's the real problem.

As an alternative, I've attempted turning on StickyKeys only while in AA, via DLL calls on a AHK hotkey, with it automatically disabling when I tab out of AA. This mostly works (since it doesn't require DOSBox to recieve input from AHK directly), with several caveats - having to tap the key twice to 'lock' it is sub-optimal, and a somewhat larger problem is Ctrl-Esc and other shortcuts triggering when Windows sees the relevant modifier keys 'permanently' down. Just remapping something else to Esc (e.g. mapping 1 to send an Esc scancode to AA, within DOSBox's remapper) isn't really an acceptable solution here - the physical location of the Esc key is needed for its function because it's intuitive. As far as I can tell no newer versions of DOSBox have improved ability to get around this - is an external program to disable Ctrl-Esc at the source my only possible solution to this sub-problem? It would be a rather clunky one... if anyone knows of a dllcall or two that would do it directly from AHK, that would be superior.

I'm using Win98SE with DOSBox 0.65, DirectX 9.0c. I have a fairly extensive library of old games performance tuned to my liking on this particular system and version, so I'd really rather not change DOSBox versions unless it will definitely solve something major, and the OS is absolutely non-negotiable - it's absolutely necessary on my gaming machine for various OTHER compatability issues DOSBox, VMs and the like are still incapable of resolving. And naturally, for DOS games, I also need to run DOSBox on that same machine. The funny thing being, it's pretty much proven AHK -can- work with DOSBox under this combination to the degree I need... seems there's just some particular option or caveat I don't know about breaking it for me specifically. Unless somehow running the OS under a VM is what fixes it - which would in turn break other things I can't have broken, if so. Obviously, CPU/sound/video should be irrelevant to these issues. And also obviously, I've researched these issues in considerable detail already. I see nothing in the changelogs that would suggest DOSBox has changed things that would improve these issues. Incidentally, it would be nice if there were a install-it-yourself .zip distribution of 0.74 available. Having to deal with the potential issues of an actual windows installer just to test if some obscure problem that probably isn't fixed by a new version happens to be anyways is a real pain, and automating making the zip as part of the release process should be trivial - many programs do it.