Heh, thats the thing,- this program scans the screen prior to sending key presses. Eg (overly simplified):
Send, {Up 3}
Send, {Enter}
Loop Scan for F9 screen
{
If true, hit F9, continue
If false
{
Scan for world creation screen
If true, break
If false, continue
}
}
Rescan to check for world creation screen
if true Send, {Down %World%}
Send, {Enter}
...etc
In this manner, it should only be sending the key presses after screens have changed. Literally every time the screen changes, there is a scan in place to check whether or not it has occurred or not.
I originally built the program around my computers' specific timings, but upon making a public release I knew that wouldn't cut it so I came up with a design that would cater for any delays, no matter how long. This works on my beast of a gaming/workstation rig, as well as my shitty (and I mean shitty) internet access pc at work
(don't tell my boss
)
What it doesn't scan for is whether or not your DF has registered the keypress and that the right option is highlighted before moving on. So, effectively if it's sending keypresses faster than your computer can take, that could be an issue.
The scans are relative to your window, too, so make sure the whole thing is visible. Another thing this does is gauge your desktop scheme's title bar thickness, as it varies the Y coordinate of where true 0,0 is within your DF window. WinXP is 3,22 where as Win7 is 3,25 etc. If you have some trippy colours or even flat whites and blacks, the program could miscalculate the true 0,0 and scan the wrong portions of your screen and thusly lead to misdirection.
Thanks for the advice on the debugging too. When I get time to make another release, that'll definately go in there. I'm sick of guestimating fixes
Cheers, GFXiNXS