Why was appending implemented like this?

[jez]

Maybe I'm a bit late to the party here, but I've just been trying out the ZSNES 'append' functionality for movies.

I've finally figured out that ZSNES creates a directory and puts a couple of files in that directory for you to be able to append to the movie. However, if you delete that dir, or only copy the .ZMV file but not the dir, then try to append to that movie, you won't be able to.

My question is, why does ZSNES store that movie append info in the seperate directory and files? Wouldn't it make more sense to store it in the ZMV file, so append was always available and you just had to copy the one ZMV file?

[grinvader]

Appending is not polished yet.
That directory holds the states you create along with the movie, needed in case you want to go back and redo something - the final ZMV doesn't have those states on purpose (it does have chapters and bookmarks, but not every movie rewind/save state).

A small comparison - to alter a snes9x movie from a set point in it, you load an snes9x movie state while replaying the movie in 'read+write' mode.
The zsnes equivalent to that movie state is the directory in question. If you delete it, you can't "go back" until you make a new one (by saving a state while replaying the movie).

Anyway, we barely implemented appending before postponing ZMV work. Nach has probably rethought it around 4 times by now.

Essentially - once it's polished, you won't need the directory to append (it'll be created automatically if it doesn't exist).

[Nach]

Nach has probably rethought it around 4 times by now.

Indeed. The newer version of ZMV is going to be positively nuts