AutoHotkey Community

Problem solved, thanks to sinkfaze: still wondering why it arose and how to prevent it in the program, though.

Summary: Furcadia has stopped being AHKable in recent releases. What might I be doing wrong?

I have the following minimal script to test the send commands:


This script works fine in apps like Notepad, Firefox, etc (actually, I've yet to find an app where sendplay works, but I'm not too worried).

Furcadia.exe (available from www.furcadia.com/download) does not accept ANY of these inputs. It *used* to work fine, a couple of versions ago, though.

I'm one of the programmers there, so if I knew what to fix, I would try. But I'm new to it, and the input code change was before my time, so don't know why it happened, or what was changed: I'm asking around about that, but most of the other coders are asleep at the moment.

But I didn't think it was even possible to write an app that wasn't AHKable.
Am I maybe doing something wrong? Is there a way to get the above script to work with this app without changing the way we read keys?

If it's something that needs fixing in our client, I suspect it'll be a really low-priority fix: I'm probably about the only person who uses AHK to remap keys for Furcadia, but damn I love my AHK remappings. Just little things, like ctrl-b and ctrl-i making text bold/italic rather than ejecting me from my current zone: little stuff like that makes life so much simpler.

_________________
Yet another hotkeyer.

Now THAT is an interesting hodge podge of Send modes for just one game.

I'm willing to bet you'll need to try SendPlay again and possibly tinker with SetKeyDelay to see if maybe the keystroke speed is causing them to be rejected by the game. For example, try this and see if the game responds to the keystrokes:



If it doesn't, increase the delays and try again. If you get up to a 100ms delay and there's no response, there's probably something else going on.

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

Aha! Thank you!

Your code does nothing at all in Notepad, Firefox, or Furcadia. Hrm. If it's expected to work, could this be a bug in my machine that is causing sendplay to not work?

My own "mishmash" code was a minimal test of all possible send commands, to demonstrate that none of them work with the game. Yes, send and sendraw were redundant, but I included them for completeness' sake.

Testing that script in either notepad and firefox, by hitting the five function keys in sequence, causes the numbers "1235" to appear. Note: 4 does not appear from hitting F4, in any app.

Adding the line "SetKeyDelay, 50, 50, Play" to the top made no difference in this case, either for Notepad, Firefox, or Furcadia. Sendplay just no worky on my machine.

However, adding "SetKeyDelay 50,50" made the 1235 appear in Furcadia! Awesome.

Adding "setkeydelay 50, 50" to the top of my real script also made it all start working again.

Good call, and thank you! :D

This leaves me with two questions.

1) I'm a little worried that sendplay maybe ought to be working, but since I never use it anyway (I generally use sendmode input for most stuff), I'm not hugely worried. Do they work for other people on notepad? I'm using Vista SP2 and running it as myself, with no elevated privs.

2) In programming terms, what does it *mean* that I needed to add a key delay? What could cause this?

We like to remain compatible with third party utils as much as possible, so I'd be interested in knowing what changed to have broken this in the first place.

_________________
Yet another hotkeyer.

You could try to Controlsend

Like I said in my previous post, the problem is solved, I'm just wondering now why the problem arose.

_________________
Yet another hotkeyer.

If you're on Windows Vista or later, read my post here.
Games often "poll" for input; i.e. they repeatedly check if a key is in the "pressed" state. If the key is pressed and released between one check and the next, that keypress will be missed entirely. Here's an exaggerated example (sound required):
The more frequently it polls for input (the lower the sleep, or in most games, the higher the framerate), the more likely it is to catch the keypress. It's more of an issue with artificial keystrokes since they can be "pressed" and "released" much more quickly than a user can physically press and release a key.

So based on that, odds are the change was not in the input code at all (which matches with what I'm seeing in SVN) and is more likely that some of the features we added recently just made the main game loop a bit slower.

Makes sense, and probably not really fixable, though I'll keep an eye out for possible optimisations.

Thanks :)

_________________
Yet another hotkeyer.