2.00 Replays: Save 1 file, not 2

[Simon]

Hi,

this has been annoying Icho a lot. I don't remember if it's brought to discussion before.

On saving a replay, Lemmix saves 2 files. One is the binary replay format. One is a human-readable representation of the data in the binary format, but the human-readable one is unusable by Lemmix. I assume the human-readable file is leftover debugging. This is annoying because one of the two files is nothing but clutter.

The obvious solutions are 1) stop outputting the debugging file, or 2) stop outputting the binary file and have the game read the human-readable version.

You'd expect me to make a huge push for 2) now, but I don't feel as strongly about this as with human-readable graphics sets. The reason is that replays don't foster a culture around editing them with commonly-available tools. Occasionally, their contents are important to know for the game developer, because they're often sent in as bug reports.

I feel 1) is good enough for now, sounds like a one-line change.

-- Simon

[namida]

I actually tried to change it so it didn't save the text file at one point, but this caused errors. Note that they do contain useful info for challenges, especially when using Challenge Mode, etc.

This was though, back before I knew Delphi (and Lemmix's code) half as well as I do now, mind you. If I looked at it again now, chances are I could probably get it to work.

As a point of interest, leftover code in EricLang's base Lemmix code suggests the text files were intended to eventually be loadable, but it never got implemented.

[Nepster]

As it seems that there is no need for further discussions on "saving 1 or 2 files" at the moment, let me add two further suggestions concerning saving replays in NeoLemmix V2.00:

1) Auto-save replay only on success.
At the moment one has only the option to auto-save all tries on a level or none. At least for me it would be useful to have an additional option here: Save only those replays automatically, that actually solve the level.
Reason: Currently it can happen that one ends up with several replays for a single level, with no way to tell which ones are successful, except by loading each in the player. But I only rarely need replays of failed attempts (and in these cases I may as well save the replay by hand).

2) Change automatic naming scheme for replays.
This suggestion would only apply to replays of levels in big level packs, which I assume are saved in the same folder as the level pack (and not in the folder of the NeoLemmix player).
The current naming scheme is:
  rank name - level number - date - time
This has two disadvantages to me:
a) The rank names are usually not in alphabetical order, so the replays are not ordered as in the level pack
b) The level name is not given, which for pack designers is a useful description, because the place of levels in level packs frequently change during the creation phase.
So my suggestion for the naming scheme would be:
  rank number - level number - level title - date - time
I am aware that other people may remember levels and their positions in a different way than I do, and therefore may prefer the current naming scheme (or yet another one). So unless many of you like this new naming scheme, we should probably keep the current one.

[IchoTolot]

As I read Nepsters post: The automatic save of a replay should also not overwite the old one (data loss). More like choose a name yourself or put a 2 behind it so the old one doesn't get deleted.

[Nepster]

As I read Nepsters post: The automatic save of a replay should also not overwite the old one (data loss). More like choose a name yourself or put a 2 behind it so the old one doesn't get deleted.

As far as I know, the automatic save always either prompts you to enter a custom file name or uses "something - date - time", so there is no chance of automatically overwriting old saves.

[ccexplore]

I had use the text version of replay file in the past to help optimize/work out challenge solutions, so it's not completely useless even though I understand the clutter argument.  Then again, if you're really that bothered by it, write a rather elementary script to clean that directory up periodically.  The people who are actually sufficiently annoyed probably also have (has?) the ability to write such a script.

Instead of removing the ability to create text savefiles altogether, I'd propose not creating them by default, but provide a hotkey with the explicit function of "save to a text replay".  Failing that, creating a tool that can generate a text replay from the binary replay would also work, though seems like the hotkey proposal would actually be easier to implement.

[namida]

For V2.00n, I'll likely use a purely text-based format - I've put together a framework to easily load and save text files (still converting the existing loading / saving code - mostly just that of terrain / objects - to use it).

For V1.36n, how's this proposal:
- When auto-name is on, save only the binary file
- For automatically-saved replays, save only the binary file
- When auto-name is off, and the "save file" dialog box appears, offer (in the format dropdown box) a choice between LRB only, or TXT + LRB (or even just TXT? would there be much use for that?)

This is based on that, generally, any case in which you'll need a text file will be the minority of cases and the user will generally know in advance that they'll need one. In a worst-case scenario where they forget, it is possible to simply load the LRB file, then save the replay again, this time *with* the text file.

[Simon]

Yes yes, all of that is good!

-- Simon