I'm planning on adding an option to analinp that ouputs the bits pressed and amount of frames held down in order so we can get a history of presses and compare them with another history of presses. Format will be as follows

1000 4 0 10 4 1 3 4 1 10

This means in the recording 1000 frames passed, then the 0 bit button was held down for 4 frames, then no buttons were pressed for 10 frames, then both the 1 and 3 bit buttons were held down for 4 frames, then the 3 button was released (still holding the) 1 button for 4 more frames, then there were no button hits for 10 frames...

sound good? This will be a nice tool (companioned with diff) to determine if phil was using a macro program.

-- Anonymous, September 13, 2000

Answers

Sorry forgot about the double line thing

1000F-
4F- 0
10F-
4F- 1 3
4F- 1
10F



-- Anonymous, September 14, 2000

You realise that this is going to produce an awful lot of output, don't you? Trust me, I have done it once or twice already. I remember doing it to analyse Olivier Millardet's Kung-Fu Master recording during T2. That was hardly a general program. I used information from the driver to know which bits meant what, and even despite that (so it was more readable because it said "button 1", "left", etc. instead of some bit numbers), it was an awful lot of trouble to interpret anything from it.

Also, you can't really say that a button was held down. On some games, a bit value of 0 means that the button was held down, while on others a value of 1 means that it was held down. I guess in most cases assuming that the first frame has all the buttons in their released position (just like you do with the autofire detection) will work, but it does not give absolute certainty.

As for Phil's case, what if you get two sequences that are identical as far as presses are concerned, but not identical as far as how long the presses last? Maybe you should do a variance analysis on those two sequences then, but as long as we don't know how "inaccurate" an external key macro program is, that might still not be enough. I mean, if there's a very small variance, then it is probably humanly impossible and so he's caught, but if the variance is large enough for humans to do, then that large variance could still be caused by the fact that the macro program is external and might not generate keystrokes with better than 0.05 seconds accuracy (which is very possible since that is the resulution of the TOD clock).

Cheers, Ben Jos.

-- Anonymous, September 14, 2000

yep i've taken care of the down and up thing with saving the inital state for the bit and assuming it's down at that state, it could be messedup if someone held down a button during startup, but most people hit 'k' or 'return' which don't get recorded in the inp. Even if it's screwed up it will be noticable since one button will mostly be "on" sometimes "off" but the states will still change the same as if it were mostly off and sometimes on.

The output just as long as the verbose Speed can be if an inp was recorded in auto mode on a slow machine. I think this will be a very usefull tool since you can time variances of "sequences" of presses rather than just timing single button press separations. So we can get slowdown information on games that only use the joystick. I think InpHist has trouble in doing this with 4-way joystick movements because when you do a half circle twist, you are pressing the down button for the whole time you press the right diagonal to the left diagonal. With a sequence history you can get the transitionstates of the buttons and get a real acruate tick of how fast people do things with joysticks. This can get confusing with button presses and joystick movements since you have to hands that can be equallly fast. But i will have to work on that to get the stats, at least for the moment I have sent you the history of keystrokes for phills offending level, we can do the variances by hand for now.

-- Anonymous, September 14, 2000