[SUG][PLAYER/EDITOR] Version field for levels

[Dullstar]

I'd like to suggest adding an optional version field to the level format. This information, if present in a level, would also be saved into replays made for that level.

The main use of this, in my opinion, would be for replay management. Currently, other than trying to load it and see if it works, there's no way to tell what version of a level was made from unless it's been baked into the filename. You could alter the level ID, but then a replay is recognized as being for a completely different level, and depending on what changes were made, there is a chance the replay might still pass - so it is still potentially useful to load a replay from an old version in a later version of the level - certainly, the chance the replay passes is a lot higher than the chance a replay from a completely different level passes. I believe you can still load the replay anyway, but it would be useful to have a different warning for "This replay is for a completely different level" and "This replay is for a different version of this level."

Sometimes, people have an outdated version of your level (and don't realize it) and they submit a replay they think may be a backroute. It may still be useful to watch the replay, even if it fails the current version of the level: is it an old backroute that you've already fixed? Or is it a new backroute that could still be made to work in the current version even if the changes to the level were enough to break the replay? But which old version of the level does the replay go with?

If a replay from an old version passes a new version, it might be beneficial to have it automatically resaved with the new version as well, either as a separate file, or by allowing the replay to store a list of versions that it's known to work against.

There could also be some potential for discussion of what, if anything, the editor should do to help manage this, but I think that might be best saved for after we decide whether or not this feature should be added at all.

[namida]

I suspect a very large number of people would not bother to keep this updated, so editor assistance would be critical to such a feature actually having much real-world use. Perhaps it could be manually overridden on a per-level or even user-settings basis, but I'd insist that the default behaviour is that it's automated.

With that being said, happy to look into it - including "write it into the replay". The questions that would arise are:
- What should the format be? Given it's mostly for internal use, I'd say simply an integer that increments every time the level is saved should be fine.
- What should the player do with this info? Write it into replays of course - but also, warn the player (similar to what happens currently for incorrect level replays)? Perhaps warn in a less-intrusive manner? Or the alternative is to warn the same way it does now, but with a situation-specific text.

This won't come as a V12.10.0 feature, at least as far as player support goes. I might add editor support for the next stable update on that side, if we're in agreement at least about how the editor side of things will work by that point; for the player, V12.11.0 would be most likely.

[Simon]

As a version, you can write the datetime of the most recent modification into the level, and have the replay refer to that. Like the incremented integer, this would update even for cosmetic chances, but that might be even desirable: In Lemmings, you can't guarantee that a terrain change is purely cosmetic.

Version mismatch isn't important enough to warn the user every time. If the replay works, it's all good. If the replay fails, only then it's interesting to see if the replay expects the same level version as the level has.

The downside of the single incrementing integer (compared to datetime) is that one version can give birth to two subversions with different terrain (both by you, or by different people), but they would have identical versioning information.

-- Simon

[Dullstar]

I agree that the timestamp is probably the best way to do this. In addition to this not causing the situation Simon describes involving a level that has been forked, it would avoid having an incremental version number that jumps far ahead each release if you save frequently.

I would agree that the warning should be suppressed if the replay works when using the mass replay checker, although I'm not sure what the best thing to do when actually viewing the replay would be, as if you have a replay that fails the level, there could be multiple reasons (e.g. the replay's version doesn't match, breaking physics changes were made to NL, or the replay was someone's submission of their best attempt). I'd say maybe warn on load, then if it passes, re-save it with the new version information. Alternatively, run the replay behind the scenes to see if it works before deciding what to show the user.

[namida]

The most important player side aspects of this are implemented in commit afb67a3. In particular, (a) an integer "version" line in level files will survive Cleanse Levels; and (b) a level's version will be saved in a replay file. This will apply from player V12.10.1 onwards.

Editor support will come later, as well any further features relating to it in the player (in particular, mass replay tests should be making use of it).

[namida]

Everything I want to do on the player side (for now) regarding this feature is implemented, in or before commit aaf57ef.

Specifically;
From V12.10.1, the "Version" field of a level is saved in replay files and preserved when cleansing levels.
From V12.11.0, the mass replay check will draw attention to cases where the version number of a level does not match the version number the replay was recorded on.
From V12.11.0, cleansing a level will increment its version by 1.

V12.11.0 features will not be included in new skills experimental builds (V12.10.1 features will, or rather, already are).

There is still no progress yet on the editor side of this, including that current editor builds do not preserve the Version field. However, as only editor work remains to do now, I am moving this to the Editor Bugs & Suggestions board.

[namida]

And, editor side implemented in commit 73664d1.

The editor increments the version number by 1 every time the level is saved, including when it is saved for the purpose of entering testplay mode. As such, this feature is now complete (pending the release of player V12.11 for full support on that side; and editor V1.33 for support on its side).