[SUGGESTION] theme.nxmt overrides

[Dullstar]

This has definitely been brought up before, but I'm not sure it's ever been made its own thread, so I'm going ahead and creating a thread for it.


Problem: A pack might want to have certain items provided by theme.nxmt consistent for the whole pack, e.g. Lemming sprites. To do this, currently one must set all levels in the pack to the same theme. However, theme.nxmt also affects things such as one-way-walls, pickup skills, builder colors, the background color, which we would probably still want dependent on the level's information, and not the pack's. So if we want to have custom lemming sprites for the pack, but retain other style properties given by theme.nxmt, we must create a theme for every combination of custom lemmings and styles that we might want!

Proposed Solution: A pack could provide a theme.nxmt file that isn't required to be complete. Anything present in the pack's theme.nxmt replaces the equivalent fields provided by the level's. Ranks could also provide these, too, although this would raise the question of what happens if the pack and the rank both provide one. More on that later. This still leaves individual levels out (I still might want the custom lemmings in an individual level, after all!). Theme.nxmt is a pretty small file, though - if we really want to override it in an individual level, we could simply embed one within the level (alternatively, a file with the same filename as the level but different extension). Of course, this would result, as implied earlier, at least 4 potential sources of theme to go through, so how would we decide what gets priority?

I'd suggest going in the following order, where the first item is the one that's processed first, and then each subsequent item overrides the result of the previous operations:

Level's specified theme.nxmt -> Level's embedded theme.nxmt -> Rank's theme.nxmt -> Pack's theme.nxmt

I haven't actually checked if subranks are a thing or not, but if they are, we'd just work our way out starting with the level's subrank to its parent, continuing until eventually reaching the theme.nxmt of the parent pack.

Finally, if we really wanted to be able to stop overriding at a certain point (perhaps we want a specific level's embedded theme to take priority over the pack's), we could mark fields as "FINAL" which would block that field from further overrides.

[namida]

A pack could provide a theme.nxmt file that isn't required to be complete. Anything present in the pack's theme.nxmt replaces the equivalent fields provided by the level's. Ranks could also provide these, too, although this would raise the question of what happens if the pack and the rank both provide one.

A "rank" in modern NL is just a pack inside another pack - there is very, very little distinction on a technical level.

By extension, the established order of priority is "smallest first". So for example, let's say I have a pack called "Lemmings", with a rank called "Fun", with a sub-rank called "Derp". If "Derp" has a postview texts or music rotation file, that will be the one used while playing levels in Derp. If "Derp" doesn't have its own, "Fun" will be used, and if Fun doesn't have its own either, "Lemmings"'s will be used. If even that doesn't, it falls back to default.

I cannot see any justification for breaking the established convention here.

Partial-loading of themes could get very messy, especially if there's an expectation that we'd be merging (rather than just picking a single one, to be used in its entirity, to have priority). There's also the question of how to handle it in the editor, in the case of per-level things.

Overall, I'm not saying this couldn't happen, but I'm very wary of the complexity it could add, and I'm not even remotely convinced that the benefit would be worth the effort even if it were likely to be widely used - which in and of itself I somewhat doubt.

[Dullstar]

The main usage I'd expect to see would be to allow use of custom lemmings without coupling the lemming selection to one-way wall colors, builder colors, background color, etc.

A simpler implementation might be to only allow the lemming selection, and nothing else, to be overridden.

The alternative, of course, is a proliferation of pack-specific themes that are basically "Theme A but with MyCustomLemmings", "Theme B but with MyCustomLemmings", "Theme C but with MyCustomLemmings", etc.

[namida]

The alternative, of course, is a proliferation of pack-specific themes that are basically "Theme A but with MyCustomLemmings", "Theme B but with MyCustomLemmings", "Theme C but with MyCustomLemmings", etc.

Is there actually more demand for an override on lemming sprites, than there is for the other parts of the theme file though? Keeping in mind that "custom" lemming sprites could also be different recoloring for the default ones (in the vein of eg. the L2 styles, all of which point towards the "default" style for Lemmings, but specify some recoloring thereof). It would be more work to restrict the override to "lemming colors only" than to allow all colors.

It should also be kept in mind that certain types of interactive objects have lemming sprites baked into them. Graphical oddities will arise when the style / lemming sprite correspondence is broken. Sure, it's already possible to do that, but at the moment - even if not technically enforced - the general custom is that a level's theme should match its predominant style. This feature would strongly challenge that. The counter-argument could well be that this disconnect already occurs in the case of zombies / neutrals (but the flipside to that is that doing something about it for zombies / neutrals is practical, and likely to happen sooner or later, whereas it borders on impossible to handle this for outright custom sprites).

[Proxima]

I made a similar suggestion earlier but for different reasons.

I do agree with Dullstar's reason for wanting this suggestion, but from the opposite direction -- I would personally be more likely to want to use custom styles whose themes dictate custom lemmings, but with default lemmings. I have no problem with entire packs such as Lemminas or Millas that use custom lemmings, but it feels weird to me if lemmings are different from one level to the next, and for my own packs I would certainly want default lemmings throughout. Conversely, I could understand another creator wanting a particular set of custom lemmings throughout a rank or pack, so I'd be happy to support that.

[Simon]

Like cascading stylesheets, but for NL. Sensible, but needs good documentation. It makes stuff behave on more files than now, and levels behave differently based on where they sit.
 
-- Simon