Jump to content
  • 0

MO interface


Smashpatch

Question

Thanks for creating a product that (combined with subjecting myself to truly doing every single step in the S.T.E.P. guide, presently https://wiki.step-project.com/STEP:2.2.9.2) accidentally made me go where my brain refused to go before: into somewhat understanding which files tend to be in mod archives (from the Nexus, mostly), so which files do what and tend to "overwrite" one another from one mod package to another... to another. I can almost see "the big picture" of mod files, thanks to MO.

But I still can't do what I want/need to be able to do, that I think many others will also find crazy useful (and crazy handy too) to be able to do: open mods in the left pane no differently than we can (with arrows and checkboxes next to each file and folder) see and do with each mod when installing them (via the "Manual" button or if MO can't find the mod archive's data folder).

Without the dialog box/window, the interface used to install mods (not right-click, "Information..." > "Filetree". It has no checkboxes to select/deselect any file or folder as the installer interface does and it's also disconnected and unintuitive compared to what I'm proposing), I'd like to see that same internal interface used in the left MO pane by putting an arrow graphic to the left of each mod's checkbox (left pane) so that we can "open" any mod right in the left pane to see what's in its belly (but with no dialog window; just with folders and files inside an open mod displayed right in the left pane as a filetree under the mod's main folder), and with the ability to open two or more mods/folders at the same time in the left pane to compare files and (at minimum) "manually"/tediously be able to see files inside two or more mods are conflicting; right in the left pane.

If the icons/flags for "Overwrites files", "Overwritten files", "Overwrites & Overwritten", "Redundant" (and any more there may be) could also be "choosy" once a mod is "opened" in the left pane (once the new arrows next to each mod's checkbox are clicked on; or double-click, which currently opens the "Information..." interface with the "INI-files" tab selected in my MO. I don't know why double-clicking on a mod would open an ini file interface), so that we could see which mod(s) or even which file(s) (and/or entire folder(s)) in one or more other mods are being overwritten or are doing the overwriting.

Having those icons ("Flags") appear on just about every mod doesn't tell me anything but that I have the typical mess of "conflicting" mods (possibly; it depends if I want to "overwrite", which should be called "override" or "overridden" because MO doesn't overwrite anything, or none of this major bonus feature contemplating would be possible).

By default, I guess it's fine if it's all that can be done at present... a glyph/icon ("Flag") that shows me that just about every mod I've installed is overriding files in who knows what mod(s) above it, and has files of its own that are being overridden by who knows what mod(s) below it. :)

I think that just a single-click/select one mod should put the focus on that mod and then only show the "Overrides files", "Overridden files", "Overrides & Overridden", etc. ("Flags") that are relevant (if any) to the selected mod should be displayed... which would be a gift from the heavens. Imagine those flags changing every time we selected a given mod, clearly showing us which other mod(s) above had files being overridden by the selected mod, and which mod(s) below had files that were being overridden by the currently-selected mod... along with the ability to "open" any number of mods right in the left pane (via a new arrow graphic to the left of each mod's checkbox or double-clicking on it, which always means "open", but not currently in MO) to see exactly which files were conflicting with one another... and via checkboxes, to be able to select or deselect any file or folder "in" any given mod, to resolve conflicts. It would be heavenly. :)

 

We might actually be able to see what we're doing for the first time ever, effortlessly with an interface that just makes sense.

"Hiding" files is very awkward and the interface is totally disconnected (hidden), when it can be in plain view in the left pane and using checkboxes to "hide/unhide".

 

Even if MO has to rename files behind-the-scenes so that Skyrim ignores them, that still belongs backstage behind the curtains. MO doesn't (visibly to users) rename mods that are "hidden"/deselected/unchecked via checkboxes in the left pane, so it should be no different with files and folders in mods... that it just makes sense to be able to open easily from the left pane.

Thanks for reading and for any feedback.

Edited by Smashpatch
Link to comment
Share on other sites

5 answers to this question

Recommended Posts

  • 0

Welcome to STEP @smashpatch

 

You may not be aware, but MO 2 is currently in an alpha development stage and the whole testing/development/bugfixing/improving process is taking place mostly in the GitHub repository.

You might have a better chance of getting one or two ideas included if you post them there, @Tannin only rarely visits here at the moment as his workload is mostly on MO 2.

 

If I may make a couple of observations?

 

A lot of the changes you suggest are based on the assumption that the left-hand pane is a "filetree" window, in the same manner as Windows Explorer windows, or at least a close approximation of one. In reality this pane is more akin to a checkbox that passes selections to the modlist.txt for use by MO's VFS. This is an over-simplification but fairly accurate. That's not to say your changes can't be made, just that the changes necessary to implement those would be significant.

 

Next the highlighting of "overridden" files. Recent versions have already made adjustments to this feedback by adding the coloured backgrounds to mods that are specifically affected by the selected mod. Selecting a mod will show green mods for mods that it overrides and red for mods that override it.

 

As for "hiding" files. I'm not sure what you mean by:

Even if MO has to rename files behind-the-scenes so that Skyrim ignores them...

 

MO doesn't need to hide anything to work, it just uses the files you tell it to. Any files not needed are just left where they are. This is all part of the "Mod-isolation" process.

 

We do really appreciate your input into this tool, although STEP are the custodians of MO's support, we also are avid users of MO and want to see it continue to be the best mod management system around.

Any further feedback here will be appreciated but as mentioned earlier, you may find more success with them being seen by those that will make the changes if you post them in GitHub.

Link to comment
Share on other sites

  • 0

Welcome to STEP @smashpatch

Thanks very much, @GrantSP and also for the quick response and feedback.

 

You may not be aware, but MO 2 is currently in an alpha development stage and the whole testing/development/bugfixing/improving process is taking place mostly in the GitHub repository.

You might have a better chance of getting one or two ideas included if you post them there, @Tannin only rarely visits here at the moment as his workload is mostly on MO 2.

I wasn't aware. I'll give that a try, thanks.

 

As for "hiding" files. I'm not sure what you mean by:

MO doesn't need to hide anything to work, it just uses the files you tell it to. Any files not needed are just left where they are. This is all part of the "Mod-isolation" process.

Thanks for the link. I think I may be able to find some good MO documentation from there. I hadn't been looking for MO documentation, but if I'm going to use the STEP Guide, well it's crossed my mind a few times that it "might be" ;) a good idea to actually know about the mod organizer/manager I'm so happy with, in combination with the STEP Guide.

 

What I mean by hiding is that MO appends the extension ".mohidden" to any file or folder users "hide" (if they can locate the Filetree interface). It may not be necessary to rename files and folders "in mods" (in folders that are the same as any other folders) to "hide" them from Skyrim. Personally, I'd use a data file other than modlist.txt to keep track of which files and folders in mods were selected and not and the ones that weren't I just wouldn't "virtualize"/load into RAM before calling skse_loader.exe.

 

But if it's somehow necessary for MO to rename files, to append the .mohidden extension to files and folders then I'd use the .mohidden extension MO presently uses to "hide" files to determine whether to put a checkmark in the checkbox beside that mod item, or not. Presently, the "Filetree" interface doesn't have checkboxes to show users what is and isn't "hidden" (selected or deselected).

 

And because the Filetree interface is just dealing with files and folders that do exist in the mod folders (left pane), I'd move all of it to the left pane and dump the "Filetree" interface.

 

We do really appreciate your input into this tool, although STEP are the custodians of MO's support, we also are avid users of MO and want to see it continue to be the best mod management system around.

Thanks very much. I appreciate your input as well. Without sound collaboration, neither the STEP Guide nor MO would exist. I'm all about collaboration, which never seemed to be the case around NMM. I could be wrong, but MO has left NMM in the dust, to me. I got evidence that MO is an active, open collaborative effort within hours of posting a fairly involved (TL;DR) well two suggestions for MO improvement with the "Flags" graphics being active/interactive to the currently-selected (or open) mod.

 

Any further feedback here will be appreciated but as mentioned earlier, you may find more success with them being seen by those that will make the changes if you post them in GitHub.

Indeed. Thanks for both. But I'm not sure what to post here now, other than STEP-specific feedback. When I googled "MO support" or the like, I got pointed to here and was told that it's the official site for MO support, which is totally awesome. STEP collaboration combined with MO collaboration is going to change the entire space-time continuum. ;) But I'm not sure what about MO I'd post here now. Is what you suggested to me because MO is pregnant, is about to give birth to a new release, so is in alpha at the moment, or should we always post on the MO GitHub repository with feedback regarding MO?

 

Sorry, but I'm trying hard to get my footings sound, because STEP and MO certainly deserve that much. :) I don't want to waste my time or anyone else's time posting in the wrong place(s).

Edited by Smashpatch
Link to comment
Share on other sites

  • 0

Heavy, intensive work is primarily focused on MO 2 at the moment, so you will have to take that into consideration when offering any MO 1.x related changes.

The alpha is in the stage of finalising the VFS work, trying to get all the "nuts & bolts" work correct, before moving on to more cosmetic changes.

 

So... if you are using 1.x for your mod management then feel free to ask any questions here, after consulting the wiki first or course  ::): , and be assured that the team are more than happy to assist you.

Questions related to changes/adjustments/additions/etc. to MO's workings or interface will probably be better served if asked in GitHub. Either way a few of use here are reading the GitHub issues page and vice versa so I don't think anything will be missed.

Link to comment
Share on other sites

  • 0

Heavy, intensive work is primarily focused on MO 2 at the moment, so you will have to take that into consideration when offering any MO 1.x related changes.

The alpha is in the stage of finalising the VFS work, trying to get all the "nuts & bolts" work correct, before moving on to more cosmetic changes.

 

So... if you are using 1.x for your mod management then feel free to ask any questions here, after consulting the wiki first or course  ::): , and be assured that the team are more than happy to assist you.

Questions related to changes/adjustments/additions/etc. to MO's workings or interface will probably be better served if asked in GitHub. Either way a few of use here are reading the GitHub issues page and vice versa so I don't think anything will be missed.

Understood. Thanks for the clarification and for all of your help.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.