[SUG][EDITOR] "Deprecated" flag for objects

[namida]

This flag could be set by adding "DEPRECATED" to the nxmo file, and if set, the editor:
1. Won't display the object in the object selection list (alternatively: won't display by default, but there's a way for the user to override this; even in this case, it should display some kind of warning marker)
2. The level validation tool will complain about the presence of deprecated objects. It probably should not auto-remove them, but could perhaps highlight them.



Possible use cases:
1. If an object type is removed, objects of that type could be marked as deprecated.
2. If a style creator needs to make a significant change to an object, they could create it as a new object, then mark the old one as deprecated. This would make it easier to find.
3. When support is added for eg. locked exits to have both a constant animation and an opening animation, the separate decorative flame objects can be marked as deprecated. (For the record, this feature might be coming pretty soon - because I'm currently working on it!)



Other: Might this be useful for terrain too? Perhaps use case #2 from above is relevant to terrain as well.

[Simon]

Good proposal, including its details 1 and 2, to solve a very hard problem.

It's good even when no features get cut. Despite beta-test engine versions that last several months, level/tileset designers feel rushed to stay at cutting edge. It's good to have several years or forever to adapt a pack. Level pack owners can transfer maintainership 5 years down the road, and the new maintainer is still not rushed to fix deprecation issues.

Multiple animations for a single tile are also good. I believe that all gadgets should animate when idle, especially triggered traps and decoration.

As an alternative to deprecation, we should consider autocorrection: When the game/editor loads the forbidden loose flames, they're automatically deleted, and when we load the half-exit, it's replaced with the two-animation locked exit. But this covers only your use case #3. Autoremoval will silently fail on use case #1 (feature cut), that's very expensive, even if it's rare.

Other: Might this be useful for terrain too? Perhaps use case #2 from above is relevant to terrain as well.

Terrain changes needs a very good reason and happen rarely, but yes, they should follow the same deprecation process. Until you asked this, I thought the deprecation feature was designed for all tiles.

-- Simon

[namida]

Nepster (and Icho, if you're working on the editor): I've made some commits in my editor repo that handle deprecation of pieces - terrain is supported too. Commit 51eb538 is the first one with this feature fully intact.

Deprecated pieces:
a) Will be mentioned when using the "Validate level" feature.
b) Will, by default, not be shown in the piece selection list. There is an option to override this.

I wanted to also highlight them in the level image, but I couldn't quite figure out a good way to do this without either significant modification to, or significant duplication in, the editor's rendering code.

In the latest player commits, all pieces that are no longer needed (either due to secondary animations or due to nine-slicing) in the official graphic sets and my graphic sets, have already been marked as deprecated.