It's aliiive! Angband replay logger works

[Pete Mack]

After embarrassingly many false starts, I found the correct invariant:

macros are always determined by the local machine.

So to record, log everything that has passed thru macro processing.
To replay, hijack the macro processor to read the log.

Unsurprisingly, all the heavy lifting is in util.c


(very much pre-alpha) patch attached.

To record a movie: '&'
To stop recording a movie: ^x (exit)

A "movie" consists of a directory with 2 files:
* A (readonly, nonscoring) save file.
* Pref files for anything that can effect key interpretation, except macros.
(options, keymap, squelch, auto-inscribe)
If you are aware of any others, let me know.


To play a movie: navigate open the file called "save" in the appropriate .bmv (band movie) directory. (Hey, I said it's pre-alpha!)

User input consists of interrupting a long pause in the original game.

[Sirridan]

After embarrassingly many false starts, I found the correct invariant:

macros are always determined by the local machine.

So to record, log everything that has passed thru macro processing.
To replay, hijack the macro processor to read the log.

Unsurprisingly, all the heavy lifting is in util.c


(very much pre-alpha) patch attached.

To record a movie: '&'
To stop recording a movie: ^x (exit)

A "movie" consists of a directory with 2 files:
* A (readonly, nonscoring) save file.
* Pref files for anything that can effect key interpretation, except macros.
(options, keymap, squelch, auto-inscribe)
If you are aware of any others, let me know.


To play a movie: navigate open the file called "save" in the appropriate .bmv (band movie) directory. (Hey, I said it's pre-alpha!)

User input consists of interrupting a long pause in the original game.

its pretty late (early) over here right now, 3 am about and I need to hit the hay. Sometime tomorrow I'll try and figure how to compile all this and get it working so I can test it out. Unless of course you want to make a visual studio 2008 project that's compiling already for me

[Pete Mack]

Add logger.c to the list of source files, and use the Windows equivalent to gettimeofday for the delay time in milliseconds. There are a few additions to externs.h you might need to add to get rid of annoying compiler warnings.

[Nick]

I've had a bit of a think about this, the more I think it's a great idea. Features I'd like to see:

1. The capacity to run forward while displaying only every 10th frame, or whatever; this implies
2. Fast Forward - run without display to the chosen spot;
3. Rewind (maybe slow) - start from the beginning and then go forward to the required spot;
4. Automatically jump to the next entry in the player history, extendable to
5. Automatically jump to player-set points and possibly
6. The ability to set stop-points while viewing rather than playing.

I intend to put this in FA when it is out of pre-alpha...

[Pete Mack]

I already added fast-forward/slow motion, though not by skipping frames, just running them faster/slower. Of course, all my movies to date are pathetic, as I'm not interested in playing, just in writing code

Once you've got the basic replay functionality, points 4,5, and 6 are just book-keeping. Create a save-file, and replay with no gfx to the exact position in the log.

On further reflection, I have come to believe that the biggest benefit of this feature is being able to track down even the most elusive bugs. If you have a particularly nasty one, just use replay mode by default*, and the repro cases will come rolling in.


* possibly with occasional savefile checkpoints to prune the log.

EDIT:
Oh, yeah, and whatever method you use, make sure to put the record (replay) logger in the right place: immediately after (before) macro translation (in inkey_aux/inkey_ex). It took me a long time to realize that invariant.

[myshkin]

Hmm. What do you think about using this as a basis for regression testing?

[Pete Mack]

Redo logging is a standard method for regression testing, but you need a less naive implementation for it to be really useful.

The naive replay log I wrote is physical (essentially raw user input), so a single UI change will break them.

If you want them to have a longer lifetime, you need logical logging (of commands, rather than keypresses.) That's much more durable--it will last as long as there's no change of the command specification. But it's quite a bit more work.

[d_m]

Pete, have you ever used Git or Mercurial for version control? It would be really great to publish this work in a DVC repository. That way, people could easily get your most recent work and send back patches against it, and you could easily track Angband HEAD while still maintaining your own commit log and rollback capabilities.

Of course, if you think this code will get added to HEAD soon, then maybe this is less important. But if it's going to be more like the Borg (in terms of maintaining a patch set or a parallel repo) then I think it would be great.

If you're interested and would like more information on setting this up, I'd be happy to discuss it.

[bebo]

Awesome feature! Great work Pete, this is something that I'd imagine a lot of people in the community would be interested in - I know I am for sure. Can't wait for this to be included in a 3.1.2 development release.

[Pete Mack]

@d_m -- I'll make the code available in a little bit. Really, the only thing left is a few UI tweaks, and minimal user friendliness--it's only about 200 lines total.

[d_m]

@d_m -- I'll make the code available in a little bit. Really, the only thing left is a few UI tweaks, and minimal user friendliness--it's only about 200 lines total.

I await with baited breath.

[s0be]

I often find myself having the same problem when I hack on a program... someone asks if NN feature is done yet, and I'm like "I dunno, I'm hackin"

[Magnate]

I await with baited breath.

(I can't believe I beat Nick to this) ... I hope not, that would be a bit smelly. Bated breath, now that's understandable.

Seriously though, I'm being encouraged to set up a git repo for the Debian version control (Debian frowns on having it enmeshed with upstream source) - so if I do that, would that suffice for things like Pete's logger and Sirridan's savefile editor?

[Nick]

(I can't believe I beat Nick to this)

Well, I did think about it, but decided it wasn't worth it. But apparently you did, and that's fine

[Pete Mack]

Beta release, movie player.

OK, here's the first pre-beta.

Use:
In normal play.

1. '&' "toggle movie": record a movie, or stop recording if already recording.
2. Use the "notes" command ':', to leave a message to your audience.

Files will be saved to a <name>.bmv ('Band movie) directory in the same location that character dumps get put.

In replay:
To start: open the "save" file in the .bmv directory created during recording. (For a full recording, there should also be a "log" file and a "prefs" file. And yes, the "save" and "log" files can be used for keystroke-level save scumming, but without hacking, it will only open in replay mode.)


Features:
1. Hitting any key will interrupt the sleep and go on to the next frame.
2. '&' (toggle) will pause replay and put you in a limited command mode, where you can see the whole map, look at inventory and equipment, and change the replay speed with '+' and '-' commands.
Repeating '&' will resume play.

I haven't done much (any) testing of the replay command mode, so expect bugs. Don't worry, you can't die to bugs during replay. (You can always start the movie again.)


Known Bugs:
* No hooks for screen resizing, so make sure to set your screen size to the size as the original game. (In other words, use 24x80.)
* Will not compile on windows. (Uses *IX-style high-resolution time API.)
* Will not work across significant UI changes. (Use a compatible svn rev for record and replay.)
* Boring as hell, at least when watching your own game.
* Log files are unnecessarily large: 4 bytes for every key stroke (2 bytes for time in MS, 1 byte for event type; one byte for actual keyboard input.) Information theory says that this should be closer to 1 byte/command.

EDIT: you will almost certainly want to set the debug variable in logger.c to 0. It generates a whole lot of useless output. And in gcu mode, it will destroy the UI.