Plan for input recording and playback
The input recording file format is a simple stream of binary codes. I was tempted to use a RELOAD file, but decided against it. Input recording and playback is always be one way linear progression through a stream, so it doesn't make sense to have a random-access structured file, especially with whatever overhead that involves. I still might have tried it, but allmodex does not already depend on reload, and I didn't want to add that dependency just for this.
Also, whenever we change the format and that breaks playback of old input files, that is no disaster, since input recordings are fragile by nature and will break for a ton of other reasons too.
I know this format isn't super efficient in terms of storage space, but that isn't what I care about. I am focusing on implementation simplicity and clarity.
Contents |
[edit] .ohrkey file format
| byte size | data type | description |
|---|---|---|
| 12 | string | "OHRRPGCEkeys" header |
| 4 | int32 | version code, currently 4. Playback should refuse files if this this indicates a format that won't be understood. |
| 8 | double | random number generator seed used for this recording session |
| ? | tickblocks | a stream of 0 or more variable-sized tickblocks |
[edit] tickblock
| byte size | data type | description |
|---|---|---|
| 4 | int32 | tick number. Ticks will always be in order, and ticks where no keys changed will be skipped. |
| 1 | byte | milliseconds in the previous tick (setkeys-setkeys interval) (capped at 255ms). This is needed for determining key-repeat events. |
| 1 | byte | number of keys stored in this tickblock |
| ? | keyblocks | a stream of 0 or more keyblocks, of the number specified above. |
| 1 | byte | number of characters of text input during this tick |
| ? | string | text input during this tick, Latin-1 encoding (one byte per character). Number of characters specified above. |
[edit] keyblock
A keyblock is only stored for each keybd() element that has changed since the last tick
| byte size | data type | description |
|---|---|---|
| 1 | byte | key index |
| 1 | byte | keybd value (never bigger than 7) |
[edit] Possible additional features
- hotkeys for Record/playback of macros.
- should game/custom automatically record keys internally for including with crash reports? (what about passwords in custom?)
- TAS features
- Automatically switch from playback to record mode on the same file when a key is pressed.
- Playback at max speed, but switch to normal speed X seconds before the end of the ohrkey file
- Record mouse input
- After Plan for improved joystick support is finished, joystick input should be recorded automatically, with no extra work.
[edit] Known determinism problems
- Mouse and joystick input
- Script commands like "system seconds", "seconds of play" and "milliseconds"
- Audio functions like "sound is playing"
- Global and function-local STATIC variables which cause differences if multiple games are played without quitting Game:
- random_formation
- targ and spread in menu_attack_targ_picker?
