wrye-bash / wrye-bash

A swiss army knife for modding Bethesda games.
https://wrye-bash.github.io
GNU General Public License v3.0
479 stars 81 forks source link

Improve static help text and colors for installers, saves and mods #462

Open Infernio opened 5 years ago

Infernio commented 5 years ago

In the Mods tab, when you hover over some of your plugins, static text in the status bar will helpfully explain what the colors mean (e.g. ESL-flagged, Is Master, etc.). This could be expanded to cover the Installers tab as well. Taken from the General Readme:

For example, a complex installer with no subpackages selected and a wizard attached could have the following static text (just an example, we don't have to use this wording):

No files installed. Complex installer. Wizard installation available.

As another example, a simple installer that later gets a plugin overwritten by another installer could have this text (again, just an example - this is probably too verbose):

One or more plugins are mismatched, see Mismatched & Conflicts tabs.

Reasoning is that a lot of newcomers see the orange / yellow status icons and get worried that they mean something bad, so showing a full text explanation in the GUI could help.

Assigned to 308 because I don't want to mess with the GUI while #190 is in full force.

Utumno commented 5 years ago

👍 especially for the 308 part - was buried in my Todos too but would need the ui refactoring to be finished yes - this has priority (to eventually move to 3)

leandor commented 4 years ago

I'd want to add something to this issue :)

There's a thing that triggers my OCD like hell... it's when a mod has an orange mark, as it's normally is a signal that the ESP was modified.

The issue is that you have two sources of that modification:

  1. As mentioned, another package override that the same ESP/ESM
  2. Or the actual file in the Data folder was modified via cleaning/ESLifying, etc.

IMO, perhaps those two different cases should be differentiated?

For once, you'd want to know (IMO) that you have a modified file in the Data folder, since you might not wanna lose it and thus it'd be helpful to remind you of the fact that you either need to repackage a mod absorbing the change, or add a new project with the modified file so you don't lose it.

That little bit of knowledge is hidden atm, and you have to see the Conflicts section to realize, this case is 1. or no, this case is 2. for each archive that's orange.

It's just an idea, not requesting anything :)

Infernio commented 4 years ago

Maybe we should make yellow mean 'not all files from this package are conflict winners', regardless of whether a plugin is involved, while orange could mean 'some files from this package, despite being conflict winners in BAIN, do not match their version in the Data folder'? That would mean BAIN-internal conflicts are always yellow, while external conflicts are always orange.

For example, I have three Animallica packages in SSE, of which two are marked orange because the next one in line overrides the main plugin. I don't care about this at all, and BAIN can pretty safely assume that because I installed them in that order.

leandor commented 4 years ago

That sounds good to me, Infernio. I'm not seeing any possible con from doing that, atm.

In my mind, the fact that many mods release a big package and then several small updates, make the 'orange' installer syndrome very common :) I often started to disable ESPs on the overridden archives, so they would turn yellow... but there are a few where you can't do that, due to presence of voice files, or else the whole package gets marked as dirty.

So if those cases were to be converted into a mild yellow mark, it's perfect in my mind... hope that I'm not missing something obvious!