[?][SUG][ED] Auto theme

[Dullstar]

Ever since the introducing of style mixing back in whenever-that-was, the theme (which affects things like colors, lemming types, etc.) has to be tracked separately from pieces. For this reason, when building a level, it can be easy to forget to change this, leading to orig_dirt's color schemes basically becoming the default since "oops, I forgot to change it to match the primary style!"

I'd suggest creating an "auto" setting for theme, and making it the default for new levels. When auto is selected, the theme will be taken from the style from which the most terrain pieces and objects are taken. This might not always get it right - for example, if you have a primary style with a few really big pieces decorated by many smaller pieces from a different style - but you'd still be able to explicitly specify.

A possible edge case would be if there are any ties. If this happens, use something like alphabetical order to determine the result. If the result is determined during player runtime, I wouldn't suggest using something like styles.ini - the final result should have an objectively correct answer that's not dependent on the player's settings. However, the editor could bake it into the level (in which case the player would not need to know about it) - though this has the disadvantage of losing auto when the level is saved for the first time. This could be countered by having the editor save the result of auto in the level, but also store the fact that the theme was set to auto; the editor would then load auto, while the player would load the result.

[WillLem]

Allowing default themes Editor-side could also help with this, for example if a level creator has a preferred theme they like to use in most of their levels.

[Dullstar]

While a user-selectable default could be nice, it's also not really the same unless you've got a custom lemmings theme for your levels (e.g. WillLem's Lemminas). I definitely have some specific styles I use a lot, but there are multiple of them that I use, and usually I want the theme to match the main style, as while I sometimes style mix, I usually do it lightly rather than extensively. The matching colors for stuff like builder stairs are rather nice, I think.

Although it also controls lemming sprites, which isn't always what you want, since if you want specific lemming sprites and also theme colors you have to make a lemming/theme coloring pair for each, which is a bit silly. Though you could include those with a pack download or something, if your pack has custom lemming sprites with it. Of course, then you'd probably also want an auto lemming selection, which would default to taking lemmings from the current theme (which could also be set to auto...)

[Proxima]

Allowing default themes Editor-side

Pretty sure that's as simple as going into the styles.ini in your styles folder and where your preferred default style has "Order=XXX", changing the number to -1.

[WillLem]

Allowing default themes Editor-side

Pretty sure that's as simple as going into the styles.ini in your styles folder and where your preferred default style has "Order=XXX", changing the number to -1.

[namida]

A possible edge case would be if there are any ties. If this happens, use something like alphabetical order to determine the result. If the result is determined during player runtime, I wouldn't suggest using something like styles.ini - the final result should have an objectively correct answer that's not dependent on the player's settings.

Alphabetical order works fine, this should be very much an edge case anyway. A default may need to be created to cover cases where no suitable style exists (eg: the edge case of an empty level, or where all used pieces come from styles that don't have a theme.nxtm file).

[WillLem]

Just giving this a bump. I'd like to look at adding it in the next Editor update.

A few questions:

1) When should the Auto-theme be applied? Every time a piece is added? Only when saving? Either way, what if the Auto-chosen theme has a wildly different background colour, for example?

2) If the theme is set to 'Automatic', does the Editor ever need to know what the output theme is, or should it be handled entirely by the Game? If the latter, again - what about wildly different background colours, or other potentially unsuitable theme properties?

Alternative suggestion:

Leave the theme blank by default. Then, let the existing Validator system handle un-set themes. Yes, it means showing the user a popup, but prompting them to choose a theme would perhaps get users into the habit of always choosing a theme as part of the level creation process.

Users can disable the Validator, or not use it. In this case, we set a default theme which is as universal as possible.

Thoughts and suggestions welcome.

[namida]

The issue with letting the game handle it is that the editor would still need to set a fallback for 12.14 compatibility. If the editor can determine a fallback, it may as well just handle the entire auto-selection logic.

My thought - the main use case for this would be "user does not need to manually select it, they just start placing pieces in their preferred style and the theme is assigned automatically". As such - I would say, invoke the automatic decision when a level:
- does not have a manually assigned theme (when loading a level, it could in practice just be assumed the theme was manually assigned)
- and does not currently contain any pieces from a style with an associated theme
- and the user places a piece in it that comes from a style that does have an associated theme

In the event of a copy-paste causing pieces from multiple eligible styles to be pasted at once, I would say determine it by whichever such style has the highest number of non eraser pieces, and break any ties with an arbitrary factor such as alphabetical order or which one has the first (relevant) piece in the raw data. Keep in mind that this is a convenience feature, not a critical one.

Alternatively, it could be invoked when first saving the level if it doesn't yet have a theme assigned. In this case, determine it based on which style has the highest proportion of non-erase pieces.

[WillLem]

If the editor can determine a fallback, it may as well just handle the entire auto-selection logic.

Agreed, the Editor should handle it, and it should be as visible as possible to the user.

With that in mind, if the theme is set to 'Auto', could it still change even after the level has been saved for the first time? Is there any point at which the Editor decides 'this is the theme for this level' and then stops assessing for an Auto-theme, or is it an ongoing process?

There is also the following scenario to consider:

User places 10 pieces from l2_sports (a style with a relatively bright blue background) into a level for which the theme is 'orig_dirt' (or some other default with a black background). They place fewer than 10 pieces from other styles, leaving l2_sports as the most likely 'Auto' candidate.

They then save the level, at which point the Auto-theme is applied. Suddenly, the level has a bright blue background and the user doesn't necessarily know why.

Or, if we set the theme on a per-piece-placement basis, the background colour keeps changing as users place pieces from different styles. Granted, this one is a fairly unlikely scenario, but it could happen.

I'm thinking the best way to handle the problem of 'user never set the theme during level creation' is simply to prompt for it when saving. A custom dialog with options to always use the chosen style as a default, etc, could suffice. It's also fairly easy to grab the colour values from the .nxtm and preview them in the dialog for the user to see.

Another idea would be to explode 'Theme' out into its own tab. This tab has the dropdown, plus some panels showing the theme's main colour scheme (background, masks, etc), maybe other information like whether it has custom sprites, etc. This wouldn't be too difficult to do and would certainly make it stand out as 'this is important, don't forget to set it'.

Should the user not want to have to worry about theme, let them choose a default, and let the default default be as universal as possible.