How to avoid old versions of styles? [STYLES] [QUESTION]

[Nepster]

In another thread, the following just occured:

<IchoTolot>as it is always the case that the lems body/head does not count

This is simply incorrect: Consider the jumping ball trap in the L2-sports style. The trigger area reaches not only 1 pixels below the trap, but 4 pixels, so the lemming will still die, even if only the head and body, but not their legs and feet meet the trap. Same for the L2-shadow style squisher trap and the water object in this style.

No, this is correct!
The L2-sports balls trigger + Shadow's stomper + all the water objects trigger areas only go 1 pixel into the ground as I fixed all the trigger areas some time ago.
I even checked in the editor again to be sure.

I downloaded a style, missed the update notification in the corresponding forum thread and therefore used old objects for quite some time. Such a situation may cause two kinds of problems:
- The user with the old style may play levels meant for the new version, that are impossible in the old one.
- The user with the old style creates a level, relies on the parts that got changed and then gives players with the new version either an impossible level or one with backroutes.
The nasty thing with this is, that (if a level just gets impossible) the one playing the level (regardless whether they are the one with the old or the new version) has no chance at all to realize where the problem actually lies!

I have no idea how one can solve this problem. How can we inform users that they have an old version of a style? How can we inform them, that a given level was created using an old style version?

[ccexplore]

I realize this is totally off-topic, but I'm not inclined to agree with Ichotolot's so-called "fixes" especially as pertained to the L2 tennis ball traps (it makes sense for water and in any case is the least relevant for normal usages of that object anyhow; I don't even remember what the stomper trap is in Shadow).  His assertion about "the lems body/head does not count" feels like a classic case of confusing implementation with design.  It's certainly not a general principle in the game or the builder and climber would not have ceiling checks at all, but let's stick with harmful objects for now.  Take L1's spinning fire trap (in the Marble set) as an example, I very much doubt anyone who has played the game without knowing the details of trigger area mechanics (which is likely the majority of players) would intuitively expect a lemming to be immune merely because it was one pixel below floor level, or that the trap is affecting the lemming through its feet (almost anyone would probably say it's the spinning arms of fire that are deadly).  More generally, how do you determine that a given trigger area was extended below ground level intentionally by design (so that a head/body collision still counts) versus due to limitations or bugs in implementation?

The feet idea may make some sense for triggered traps, especially the few whose graphics include an actual visible (though often buried just below ground level) trigger button that is indeed often only one pixel tall, implying that the trap is triggered due to stepping onto the button.  Intentions are typically less clear for other objects.

(One confounding factor is I don't remember if L2 also has a minimum size for trigger area like L1 did, or instead can support down to 1 pixel.  I want to say the latter but I'm not 100% certain.  If it's the former that maybe you have a slight stronger case that the in-game setup is not intentional but limited by implementation; if it's the latter then it can only be either a mistake or intentional.)

----------------------

Fine, I digress.  Now back to topic:

I have no idea how one can solve this problem. How can we inform users that they have an old version of a style? How can we inform them, that a given level was created using an old style version?

Well, isn't it what the "malware" is for? If you let NeoLemmix checks online, it should be able to tell you what it believes the latest version of a style is, and therefore whether an older or otherwise mismatched style is in use.  It doesn't have to download anything to do this, you just have to let it do a check at least.  Ask for this as a feature if it doesn't exist yet.

[Simon]

Dependency hell has no perfect answer.

Let levels point to (named & versioned tiles) instead of to (named tiles)? With semantic versioning, where tileset version x.y.z increases z for purely graphical retouchements, y for new tiles because that's backwards-compatible, and x for backwards-incompatible changes.

Ship a proof of solvability with every level, so the player can verify solvability without having to watch the replay?

Allow multiple versions of tiles in the same NL installation? If no, how to play old levels? If yes, can you put two tennis balls in your level, one with Icho's TA, one with ccexplore's TA?

Well, isn't it what the "malware" is for?

The malware solves only one half of the problem. When a level needs style version 1 for solvability, the malware can fetch version 2, because version 2 is the newest; yet the level remains unsolvable.

-- Simon

[Nepster]

I have no idea how one can solve this problem. How can we inform users that they have an old version of a style? How can we inform them, that a given level was created using an old style version?

Well, isn't it what the "malware" is for? If you let NeoLemmix checks online, it should be able to tell you what it believes the latest version of a style is, and therefore whether an older or otherwise mismatched style is in use.  It doesn't have to download anything to do this, you just have to let it do a check at least.  Ask for this as a feature if it doesn't exist yet.

Unless I am misinformed, the "malware" only checks if the style does not exist in the player's subdirectories (and only checks for new versions of the player itself). I certainly had the online feature enabled at some point and it didn't complain about my old L2 styles.
Adding this functionality to the online feature is a possibility, but how often should it check? With V1.43 it could possible have checked at the beginning of each level, whether there is a new version of the style available. This would only have led to lots of unnecessary checks.
With V1.47 it would have to check for new versions of all styles that are used within one level. Currently this is only theoretically more effort than checking just the main style.
But when we change to single images for each terrain piece and object, this would lead to lots and lots of online checks. So we probably would have to change to something like: When starting NeoLemmix, the game gets from the online repo a list of hashes for all images+meta-infos and then checks once at start-up whether the hashes are the correct ones.

But even with all of this, one problem still remains: How to warn players regarding levels that were made for the old version of the style. (Simon was faster posting this)

PS @ccexplore: The first half fits better in http://www.lemmingsforums.net/index.php?topic=2936.0, because it relates as well to the question where trigger areas for inverted objects should be placed. I reposted it there with proper attributes.

[ccexplore]

Sorry, I probably did post too fast (and not read enough) and miss a thing or two here.

I'm not sure of the details of how the current NL online checks work (I keep forgetting it is very primitive), but it sounds like fundamentally there are at least three things going on:

1) The current system do not have a notion of "breaking changes" and how to detect/track them.
2) The current system do not keep track of the original versions of sets that a given level is using.
3) The current system cannot handle (or does not handle very well) having multiple versions of a set coexisting side-by-side.

#2 could be a good start (though I was under the impression it is already done, or was I mistaken on even that?), though likely will introduce many false positives.  Basically all version mismatches will be warned, even though some (many?) may be okay, particularly in the case of playing old levels on newer sets assuming set designers are more mindful of breaking changes.  #1 helps refine things by helping to weed out some cases where the level is provably unaffected.

#3 is required if we don't want players to have to compromise between being able to play old levels versus new levels in cases where a breaking change has occurred in the set, but could also be intentionally omitted as an admittedly rude forcing function to encourage set designers to be very careful about introducing breaking changes, or for level designers to be better at reacting to such breaking changes (by updating their levels accordingly).

I would also like to point out to set designers to think very carefully about introducing breaking changes to a set that they have already made available in public, especially knowing that other people have started using them.

===========

Regarding the subtleties Simon pointed out, no I don't expect a 100% foolproof system that can detect whether a level is affected with 100% accuracy.  My idea of a "breaking change" is more along the lines of these kinds of things:
  - the terrain piece identified as X no longer exists in the newer version
  - for the terrain piece identified as Y, in the newer version the pixels at <list of locations> have changed from terrain to air, or from air to terrain
  - for the object identified as Z, the trigger area or the object type is different between the newer and older versions

So basically changes where it is possible to construct a level that would be affected by the changes.  Of course there could be many levels that would be unaffected as well.  We accept that the warning is not perfect and is merely an alert that the player may want to check further with the level designer and set designer first before investing more time in the level.  Think of it as "proceed playing at your own risk" kind of thing.

---------------------

[edit: I reread my first post and it isn't actually that far off.  I was never suggesting the current implementation is a perfect system capable of warning at 100% accuracy with 0 false positives or false negatives.  I was just suggesting whether the existing online checks could at least start off telling you if there is a version mismatch.  It may be a benign mismatch for sure, but at least it's a first step.]

[IchoTolot]

Yes there need to be a change here.

My idea would be:

- NL checks for updates and informs the user if there is a newer version avialable.
- When it is a critical (physics changes involved) update the author must give a note with the changes to namida.
- NL informs the user about a critical update and the given note gives the details on top.

I don't know this could be stupid, but hey it just came to my mind

[namida]

If you let NeoLemmix checks online, it should be able to tell you what it believes the latest version of a style is, and therefore whether an older or otherwise mismatched style is in use. 

Currently, yeah, it does not check for updates. It just checks for missing styles altogether.
The downloadable styles do have an update date listed (currently, I update this manually). This is so that I can implement a method of actually checking for updates; but so far, I haven't got around to actually doing so.

[ccexplore]

- When it is a critical (physics changes involved) update the author must give a note with the changes to namida.

Note that while it's perhaps a bit of work to implement, with the kinds of criteria I gave above, I believe it should be possible to determine in a purely automated, programmatic manner, if an updated version of a set has breaking changes relative to the current online version about to be replaced.  Or a tool can be provided for set authors to compare two sets for such changes, though to be fair, the set author probably already knows the answer beforehand, so this is probably more a check in case of an accidental or forgotten change.