Auto-replays, to what dir and filename

[Simon]

Hi,

this discussion was split off the NL issue about overwriting existing NL autoreplays.

D Lix uses the player's name and the datetime, precise to seconds, a la
AnotherLixInTheWall2p-Simon-2015-12-02-035345.txt.

PPS: I'm not completely happy with Simon's D Lix replay names either: For single-player levels, the user name is useless, but the level pack and rank are important.

PPS: I'm not completely happy with Simon's D Lix replay names either: For single-player levels, the user name is useless

Not when you are the level author and you are saving replays from several different users for future backroute-proofing!

Bad Lix replay naming: Agree with how pack/rank is important. I'm considering to autogenerate a directory tree inside replay/ that mirrors the tree in levels/. Solving the level
    levels/single/mypack/myrank/a.txt
creates
    replays/auto/solutions/single/mypack/myrank/a-Simon-datetime.txt,
creating missing directories in this exact full filename on the fly (mkdir -p).

I don't think auto-saving failures is needed at all. It could generate its own tree in replays/auto/failures, then it wouldn't ever clutter the solutions tree. But the failures tree would grow really quickly, almost no file would be interesting, and there's manual saving in case something is interesting.

I feel the player's name should go in the filename, with Proxima's reason. If it's really painful for some, they should write a script to mass-rename and move replays from the auto dir.

Workflow: Basically, this is the workflow I'd like to enable: User plays lots of exciting levels, then zip up a subtree of their auto/solutions/ and email that to the pack creator. The pack creator can merge that subtree with their own tree, which they might maintain outside of auto/, and run the replay verifier over a single tree.

-- Simon

[NaOH]

Workflow: Basically, this is the workflow I'd like to enable: User plays lots of exciting levels, then zip up a subtree of their auto/solutions/ and email that to the pack creator. The pack creator can merge that subtree with their own tree, which they might maintain outside of auto/, and run the replay verifier over a single tree.

-- Simon

Maybe then the username should be the name of the first directory after replay/auto?

[Nepster]

I am happy with any naming structure, as long as I can easily identify pack, rank and level.

However with your tree structure, you would have to strongly encourage players to send (ziped) subtrees/folders, and not just a bunch of ziped replay files.
Consider the following example: I play the first half of Vicious and send the replays - so far everything is fine. Now I play the second half of Vicious and a few levels of Hopeless. Because I don't want to send replays twice, I select the new replays of Vicious (not really straightforward to do!) and zip them (of course without the folder). Then I simply add the Hopeless replays directly to this zip file. The result is a big jumbled zip file with no easy way for the level author to sort them again.

It doesn't make things better that players, coming from NeoLemmix or the current Lix, are used to zipping only replay files. In fact the above is essentially what I would do.

@Simon: Sorry for posting this only now, but I was away over Christmas.

[Simon]

Yes, I see how people would resort to clicking one file at a time here. This is a problem.

Intuition suggests this kind of housekeeping be easy and straightforward. And it is -- zipping things newer than a day, preserving the directory structure, is a one-liner [1].

I imagine it's more annoying with on-board Windows tooling. I can be persuaded into beefing up the replay browser with such functinality. Maybe put the level's path in the replay's filename instead of the replay's pathname, but that seems weird at first.

However, in this light, NaOH's suggestion leads to this point of view: Replays don't form a tree, but rather a database, sortable by different criteria. Pressing replays into a level-dir-mimicking tree is an unnatural choice of one sorting criterion to dominate everything else. Maybe the idea to put everything in one dir, no subdirs, needs to be carefully considered before we ditch that idea.

-- Simon

[1]
find replays/auto/solutions/single/lemforum -mtime -1 | xargs 7z a newer-than-one-day.zip

[Nepster]

While playing some levels in the pack by Rubix, I noticed another problem: When the level files are only called a.txt (and such a level exists once per rank!) your suggested name for the replay will not tell one anything useful. Perhaps use the actual title of the level for the replay name, instead of relying on the file name?
(I agree that bad naming of files by the level author is part of the problem, but I am somewhat sceptical that you can force people to use descriptive file names.)

[Simon]

Level title instead of filename: Sensible suggestion, will keep in mind. Level title is what people associate with a level most.

File ordering would be mixed up; but the custom-order file (_order.X.txt in a level dir) does the same. Level title instead of filename makes it slightly harder for automated matching (level -> list of replays for this level). I believe I shouldn't rely on the filename for this matching anyway. This kind of database operation, if it's wanted later, can get an appropriate solution once time comes.

Level title can depend on language chosen by the player. Setting several titles is loosely deprecated, except for tutorial levels.

The alternative is to rename Rubix's levels in the main release, and use an odering file. Rubix has made his pack before the ordering file became a feature, and needed to cook up his own solution.

(Ideally, both levels and replays should be handled with a content-addressable filesystem >_>)

-- Simon

[Simon]

I would like to keep (naming the replay file after (the level filename) instead of (the level's title)). I don't want to introduce exceptions à la "use title if filename is 2 chars or less" -- good naming keeps both program and usage simple.

The only problematic set seems to be Rubix's set. I'll find a solution with him before declaring the D port to be standard for singleplayer.

-- Simon