z929669

Thanks for the info, sheson. You are a big help ;)

Actually see 2. What this Means for You > Mod Makers (here is the updated version) Lojack recommended not using BSAs and also not to repackage assets into BSA .. meaning that (Lojack reverted his initial recommendation) ... HOWEVER, if you have a 500 MB BSA and want to update one small asset, you would need to re-create the entire BSA and upload it to the Nexus again. Big PITA (and waste of bandwidth), yes, but the solution is NOT to add this one little loose asset ... just maybe consider not using the BSA (my personal opinion)! Did I mention that I really hate BSAs? ( UPDATE: I am writing up something more comprehensive along the lines of this topic and will provide a link once I am finished ....

This will graduate to wiki guide format once we get sufficient community input ... I am creating this thread to address some important information about BSA extraction and related modding concepts that come up over an over again with respect to STEP's use of Mod Organizer (MO) and MO/STEP critics that disagree with STEP's general advocacy of BSA extraction and MO's BSA-extraction functionality. In order for this to be meaningful to all users, I am providing some background information required for understanding the ramifications of BSA extraction and why STEP advocates it while other respected modders do not. WARNING: Extracting BSAs deviates from the intent and expectation of the respective mod provider, so it is fair to expect that once a user extracts a BSA supplied with a given mod, that mod's author has every right to refuse support on the basis that the user implementation is no longer the same mod. Further, if a user extracts vanilla Skyrim BSAs, ALL mod authors and the modding community at large have the right to refuse ANY support to said user! NOTE: The STEP community follows Wrye's cathedral model of modding, and since we advocate experimentation and an open modding approach, we also try to encourage 'creativity' (but not flagrant stupidity, TYVM) and users are welcome to support each other in this community, and we'll do our best to help as we are able, particularly with regard to what we advise in any of our guides. After all, modding is a largely creative endeavor and a learning experience! Executive Summary STEP provides instruction for a range of methods to mod Skyrim. Novice users can follow the STEP Guide, which is pretty straight forward and adheres to conventional modding methods. More advanced users or users that want to take it further can follow the additional guides and employ some more advanced and less conventional techniques (like BSA extraction and texture optimization) that we have found to be viable and optimal for the 'perfectionistic' or 'adventurous' modder. Some of these techniques are traditionally the jobs of the mod providers rather than the mod users, but we encourage and empower our community to take on these tasks if they wish, because many mod providers do not optimize their mods, and we advocate customization of mods by the user. STEP advocates BSA extraction because it allows for more granular control of the modded Skyrim (but see 'cons' below). Critics object that this practice 'breaks' the fundamental standards of install-order and load-order methodology that many mods and modding utilities are built around. Nevertheless, I and many STEP staff and members have not found this to be the case and propose that these concerns likely stem as a result of Mod Organizer users having problems and complaining and blaming the mod authors on mod threads like the USkP when something goes wrong with their game. Why MO users? Because MO is the only mod manager that exposes BSA extraction to any user that installs a mod with a BSA in it (basically, all MO users).STEP advocates BSA extraction (given the user understands the ramifications!)It is a prerequisite to texture optimization (NOTE: repackaging vanilla BSAs is possible with CK's Archive.exe but problematic with BSAopt)Used properly, it does not cause any load-order issues at allIt allows more granular control of a modded setupIt can theoretically lead to excess disk fragmentation (HDDs only, not SSDs)It can theoretically reduce in-game performance if most/all game assets are loose files under a heavily-modded gameBSA extraction is not 'bad' (NOTE: it can alter the intended behavior of a mod's interaction with other mods if used improperly)BSAs are not 'bad'simplify mod distributionsimplify user maintenance (NOTE: particularly for manual installation and traditional mod management ... but NOT for Mod Organizer users!)simplify support by mod providersBSAs are the future trend in Bethesda modding, so best to get used to them Install Order vs Load Order A word about game assets: Game assets are any files (resources) that get used by Skyrim. Plugins (*.esm & *.esp) are special assets that are used by Skyrim to call upon other assets and to provide instructions for their use. Thus, plugins are the 'brain' of the game. The only plugins needed to play Skyrim are Skyrim.esm & Update.esm. Other plugins are from the DLC add-ons or other mods made by the modding community like the USkPs, etc. Install order: The order of mod files installed onto disk. If two mod packages contain the same file names along the same file paths (e.g., textures/blah.dds), then the last installed version overwrites (i.e., overrides) any previous version and is thus the version that will be used by the game if it is called upon by the game (via a plugin). These mod files can be anything at all (e.g., text, images, ... whatever), but only certain file types are used by the game: textures, meshes, scripts, plugins, etc. Therefore, install order affects what resources the game will use. (NOTE: MO does not install mods to the data directory, but rather mods are extracted into mod folders within a user-specified location. MO creates a virtual /Data/ that appears to Skyrim as the actual /Data/, and it populates this virtual directory with mod assets from the install directory as specified by the MO installation priority. Otherwise, there is effectively no difference between MO and other mod managers, but this difference is fundamental and confers a significant advantage to MO users). Load Order: The order that plugins are loaded into the game. Like install order, the last plugin loaded overrides all previous plugins. Since plugins reference assets within /Data/ by file name, there is potential for two different plugins to reference the same named resource. Additionally, since plugins provide instructions as to the use of these resources, load order can also affect game behavior. Therefore, load order affects both what the game will use and how the game will use it. What are BSAs? Mandatory reading: read this important background information! BSA: A proprietary archive of game assets that mirrors /Data/ directory structure. Thus, a BSA file is an archive exactly like a folder that is simply packaged as a file. The same is true of any ZIP or 7z archive. How do BSAs Work? For Skyrim to be 'aware' of a BSA, it must either be registered in Skyrim.ini or loaded with a plugin of same name. Once recognized, the game sees any BSA as part of /Data/ itself; however, when conflicts exist between files contained within a registered BSA, a plugin-loaded BSA or within /Data/ as loose files, things are a little trickier:Registered BSAs: These load at Skyrim start in the order that they are listed in Skyrim.ini, last loaded BSA 'wins' in event of resource conflicts of contents within.Plugin-loaded BSAs: These load when a new or saved game is loaded after Skyrim starts. Each BSA is loaded at the time the plugin of same name is loaded. So any BSA with content resource conflicts corresponding to a plugin will 'win' if its plugin is loaded after the conflicting plugin. Basically, these BSAs (and all of their asset content) are referenced by their plugin and loaded according to plugin load order. Plugin-loaded BSAs always 'win' where they conflict with Registered BSAs. The only exception is with respect to resources required at Skyrim start but before savegame (or new game) load, like No Menu and Loading Smoke.Note about loose files: Loose files always override same files inside of registered AND plugin-loaded BSAs! Summarizing in terms of prioritization and load order ... Skyrim asset priority: Loose assets always win Plugin-loaded BSAs win all but #1 (EXCEPTION: plugins are only loaded when a new or saved game is started, so plugin-loaded BSAs have zero priority with regard to pre-game assets) Registered-BSA assets lose to all #1 & #2 Registered Skyrim BSAs and other official content and DLCs behave no differently than "after market", mod BSAsPlugin/BSA load order: Registered BSAs load according to list order in Skyrim.ini Plugin-loaded BSAa load with respect to the corresponding plugin load order Plugins load according to %USERPROFILE%/Appdata/Local/Skyrim/plugins.txt, which is managed by BOSS/LOOTBSA Pros: Keep the Data directory clean and uncluttered (NOTE: this does not apply to MO users though, since MO uses the virtual file system).Allow easy mod management, since all of a mod's files are much simpler to identify and update or remove (mitigates user error= less support burden)Make it easier for mod authors to distribute and maintain control over how the mod functions (mitigates user error = less support burden)UPDATE:Better performance (NOTE: a lot of loose files slows down game startup, especially when using MO)Less disk usage (NOTE: BSAs can be compressed; HDD fragmentation is less of an issue)BSA Cons: Removes an element of user-level control ... and many mod users are control freaks (STEP especially)Users can no longer efficiently see contents of a mod (NOTE: although Wrye Bash does expose this information, albeit with a performance hit ... is this functionality inherent or is it off by default??)Incentivizes mod authors to provide BSA 'hotfixes' as loose files (NOTE: This has undesireable ramifications for MO users due to behavior of BSA extraction in MO ... BSA extracts last, so loose file hotfix is overridden by original version within the BSA! EDIT: this is fixed in the current beta and next release of MO)Mod authors are forced to upload all files (the entire BSA) for any updates (all files are contained within a BSA), and users are forced to either download again or deal with the issue just previous if the mod author has supplied a 'hotfix'-type update.BSAs & Steam Workshop Steam Workshop only allows mods that use the BSA + ESP format. STEP finds this overly restrictive and unnecessarily 'controlling'. I personally resent it and only deal with Steam because it is the wrapper for Skyrim (unfortunately, IMO). The Steam Workshop and Steam-Skyrim community are valid entities that do not deserve to be totally ignored, but STEP does not recommend that it be used as a primary source for mods or modding information. The Nexus is the STEP-preferred source for all modding needs. For information, STEP is a good primary source, and we point to the best alternative sources, but here are a few others: TESAllianceBethsoft ForumsUnofficial Elder Scrolls Wiki (UESP)SkyrimSearch.comTamriel Maps BSAs & Mod Organizer Since Mod Organizer allows users to extract BSAs during mod installation, MO potentially obviates any functionality of registered or plugin-loaded BSAs. Thus, any mod that uses a BSA is effectively constrained henceforth by rules pertaining to loose files, so its assets are no longer linked to hierarchies of BSA registration order or plugin load order. This and the fact that all or user-specified mod resources can be loose and manageable by MO confers a clear advantage to the user. BSA Extraction Pros: MO users have a much more granular level of asset control and can prioritize BSA contents at the loose-files levelIt is a prerequisite to texture optimization (NOTE: repackaging vanilla BSAs is possible with CK's Archive.exe but problematic with BSAopt)Other issues can arise though, so only informed users that understand the ramifications should be using this functionality (unpacking BSAs). Following are some things to be aware of when unpacking BSAs (that mod authors intended to remain packed as delivered!). UPDATE: There does not seem to be any need for standard users to extract mod BSAs in MO, because once can subvert the constraints of the standard load order/asset prioritization system from the Archives Tab: Plugin checked, BSA checked - Follows mod priority order for conflict resolution. Plugin does not affect the situation at all.Plugin checked, BSA unchecked - Follows plugin load order for all unchecked BSAs. All loose file assets will "overwrite." OTHER checked BSAs will NOT overwrite, which is why unchecking BSAs can lead to unpredictable results or dificult-to-resolve conflicts (hence the warning).Plugin unchecked, BSA checked - Follows mod priority order for conflict resolution. Plugin does not affect the situation at all.Plugin unchecked, BSA unchecked - As if the plugin and BSA don't even exist in the mod setup.Furthermore, MO will scan all mod BSAs (aside from those in /Data/) and include these assets in the Mod > Information > Conflicts tab. So in MO, BSAs effectively behave like loose files when checked in the Archives Tab! Mod developers will still find the BSA extraction functionality handy for testing purposes during production of updates to their existing BSA-packed mods or when developing new ones dependent on assets contained within BSAs. BSA Extraction Cons: BSA assets are now given loose files priority, so this alters the mod author's original design intent and may introduce false 'bugs' that nobody on any forums will likely want to or know how to diagnose or fix ;)BSA extraction in MO happens after loose files are installed. This means that any loose 'hotfixes' would be overwritten by the BSA version, which is outdated. EDIT: this is fixed in the current beta and next release of MOMO exposes BSA extraction functionality using a prompt when a mod containing a BSA is first encountered. This functionality can henceforth be "always allowed" or selective, based on user preference in response to this prompt. Users that do not fully understand the ramifications of BSA extraction on the specific mods they are using together should not use this feature. If "automatic BSA extraction" is in effect, it can be reset from Settings (click the wrench icon in the toolbar) > Reset Dialogs > click 'yes' at the prompt. First, STEP recommends that users NEVER "always allow" automatic BSA extraction ... why? Because there is no need to do this at all, since the granular functionality already resides within the Archive Tab. More importantly, because many unknown or unintended prioritization issues can come into play as described previously. It is always safer to use the BSA unless it will cause a de facto undesirable result. BSAs that have optimized textures and can be overridden completely by downstream mods should stay inside BSAs (or repackaged using CK's Archive.exe). If assets from inside a BSA need to overwrite some mods and be overwritten by others, then sometimes it makes sense to extract the BSA. MO has a beautiful tool accessible from within its Archive Tab. If a BSA is present in the load order, it will appear in the Archives Tab. Leave it unchecked to allow it to behave normally and be loaded by its plugin (if the plugin is active), and check it to extract the BSA to the mod folder and effectively confer loose-files prioritization. Critics of Mod Organizer and STEP (for Officially Advocating BSA Extraction) Some within the well-respected modding community are at odds with the idea of BSA extraction advocated by STEP and facilitated by MO. The most notable contingent is the USkP team. This is relatively old news and nothing that should be shocking, so please do not treat it that way. The reasons are not unfounded and actually valid. I bring this up solely to address the idea to remove BSA-extraction from MO that Tannin suggested if MO-detected load order issues are not resolved properly (by submitting a ticket). In fact, I created this thread to address this one issue as much as to address the knowledge gap that is the real cause of any issues associated with BSA extraction. Some modders are more or less happy with MO's ability to invoke BSA extraction. Generally, mod authors who have gotten a lot of grief with respect to their mods --for problems caused by the ramifications of rampant BSA extraction-- seem to have more of a problem with MO (see note below!). This has been somewhat problematic for STEP and MO with respect to outsiders privy to the argument but not privy to STEP or MO ... never mind that the 'fault' should be shouldered solely by the unwitting mod user for invoking BSA extraction without understanding the ramifications of doing so ... and ours for not properly educating our user base to that effect (hence this thread). Let it be said that the STEP modding community and the vast majority of modders are the kinds of users that use PCs instead of Macs and tend to be somewhat removed from computing 'norms' imposed by Apple and Microsoft and their ilk. In general, we do not like our control restricted in favor of provider control over our resources to make their lives simpler. We are generally in favor of digital freedom, open source software, and the honor system. Big Brother and his methods are generally unwelcome. Demonizing BSA extraction in general and removing it from MO in particular in order to enhance level-of-conrtol by mod providers would be a big mistake, as STEP itself somewhat relies on this feature (and will to a larger extent in the future). However, I think that it is very important that our users understand the ramifications of using BSA extraction, and we need to address explicitly in the STEP Guide. The MO user base (not its 'critic' base) should guide Tannin's direction of MO, IMHO ... I want to explore what we do (and do not) know with regard to the ramifications of BSA extraction to our MO users and how best to make MO a broadly accepted utility among all within the modding community ... not just STEP. In order to do so, we must not dredge up combative arguments. Constructive argument is good for all respective modding endeavors, so what has been said in the past is water under the bridge. So keep it lively and fact filled ... but keep it polite and considerate! Please report bugs as Tannin requests using the link above. Also please post to this thread and help us to improve the breadth and accuracy of this OP!

DoubleYou is correct: A mod author should not have files that conflict between loose and BSA within the same mod package .... this is most definitely a mistake. Furthermore, it just does not matter if the conflicting files are identical (@Ubeogesh: did you check?). That would be a housekeeping mistake on the part of the mod author. If the conflicting files are NOT identical, then that is a more significant problem if the intended file is the loose file. From the mod author's view, this would be an effective way to override his own BSA version of the asset (this would be a lazy mod author that wants to avoid the hassle of extracting and repackaging a BSA). This "low-maintenance" approach has ramifications that differ according to end user experience (but only with regard to MO users): Novice mod/MO user: this would be transparent and not an issue, but only if these users do not enable BSA extraction (these users have no business enabling BSA extraction, but they likely will anyway).Semi-advanced mod/MO user: This could be a problem, because these users will likely enable BSA extraction and not notice this conflictAdvance mod/MO users:Trusting, expedient: This could still be a problem, because they WILL enable BSA extraction, and --even though they understand the risks-- they don't want to bother checking every single BSA-packed mod for this type of mod-author blunder.Untrusting, anal retentive: This would not be a problem, because they WILL enable BSA extraction and they WILL NOT trust that mod authors do things properly. Hence they will look for suspicious loose files within all BSA-packed mod packages.PS: a BSA-packed mod should really only have a BSA and a plugin (and possibly documentation). Otherwise, the BSA would have to be registered within Skyrim.ini. Additional loose files are nonsensical, as they should also live inside the BSA.

Just FYI: Mega is pretty nice, but it lacks one hugely important feature: One cannot link to images dynamically. For example, I cannot use the image tool in this post to paste a link to my image so that you all can see it here in the forum. I can only point you to the image so that you can view it on their site. Copy is better for sharing images (as is DB) ... however, Copy does not retain the file name in the public URL, which is a problem too. Generally, sites want to restrict this kind of content to jpg or gif so that it cannot be abused or used as a predatory tool for breaking a site. DropBox DOES have a bandwidth limit. They cut my service once due to my exceeding that limit ... probably because of my hosting some highly viewed screenshots on these forums a while back. This is also a problem. In my XP, DB is easiest to use (and so is Google Drive, but it suffers same as Copy)

For the record, as DoubleYou mentioned earlier, this is not necessary. Change only uGrids and leave the rest alone. Also use the Stable uGridsToLoad mod so that it can be simply reverted later without savegame problems when the user finds problems at excessive values. @sheson With your permission, this can be run on a standard mod setup like STEP:Core and the ESP distributed to our users, correct? (Assuming identical plugin order across users). This would be a major convenience.Also, once we (you) verify that this works as intended, is it not a 100% replacement for any other 'distance' mods? There should be no need to use SDO or Distant Detail, no?Why would we use the TES5LODGen tool in conjunction with this (you mention a bit earlier, but I cannot fathom the benefit of doing so)?

I like the format. If we used this format for all Patches (Packs and Extended), that would be great. We could create templates for the format for use in the Pack SMW and elsewhere.

This mod really needs a good FOMOD to allow all combinations of all options (like the BAIN installer does)

Skyrim has needed a dynamic LOD generator for some time now (although some good mods have helped to compensate). I will be looking at TES5LODGen as well as this with anticipation :licking chops:

I seem to remember having issue with the Windows calibration tool and my driver config. I think that every time I would make an adjustment via the Windows config, it would turn off my driver preset. I think they are mutually exclusive (at least for me). I recommend following the guide and using the image I linked. That page describes exactly what you should be doing.

Basically, as Manga alludes, there are three places to configure color saturation, temp, brightness, contrast, gamma, etc: your monitor's built-in config Windows color management your driver config utilityThe settings of one affect the settings of the other, and depending on the quality of your monitor, #1 could be very good or just so-so. The #2 and #3 settings should be standard though, since they are made to work across various monitors. It just makes sense that your #1 is set to "the middle ground" with respect to all settings. Having extreme settings in your monitor's config could potentially constrain the driver config. For some, wetting all #1 to mid levels will be best, but for others the 'autoconfig' will be best (this may not set all #1 to mid settings). They you have other autoconfig options that may be based on various presets. Whatever seems most "middle of the road" is probably best for #1. Then you need to calibrate using #3 (or you can use #2 utility, but this is also redundant with the driver settings, so I would run #2 and ensure all settings are also "middle of the road". Then I would fine tune all using my #3 using a reference image like this and in a room with no direct lighting that could affect what my monitor shows (you want a not-too-bright, diffuse-lighted room ... ala "middle of the road" ... see where this is going?). The main config should be left to #3 once they are given a mid baseline 'canvas' to work from. I will update the calibration instructions (again) in the guide for 2.2.9. EDIT: I just updated the guide :P

I too see the algorithm-etric intelligence of LOOT as both a strength and a weakness, but it will ultimately allow user-based rules to be incorporated ... AFAIK, it does so now, but the submission process is not as simple and transparent. If you look at the masterlist, it seems editable, so I am assuming that LOOT is just BOSS with more automation based on a rule set (and less built-in user functionality ATM). It might mess up some things that don't obey the rules, but it should require much less user-integrated input. I have yet to see what it does with my Requiem build. That will be the true test for me, as BOSS requires about 35 user rules to sort it properly. I'll post back when I look at that.

I think a STEP Video Guide would be awesome. IT would be a bit of a project though, depending on how you did it. I would advise that you consider waiting until we release 2.3.0 or even 2.3.1 though. Then the methodology will be more stable I think. We have some changes in the pipeline. Feel free to PM me about this when you want to think about it more.

C64? Amiga? ... try Pong, Space Invaders and Atari

Discussion thread: LOOT by WrinklyNinja Wiki Link LOOT is an advanced Load Order Optimization Tool that scans your plugins and suggests a possible load order.

The install instructions for WAF and ICH will be updated and vastly simplified sometime TODAY. Thanks Kelmych, DoubleYou and EssArrBee (and others) for all the clarification. This gigantic discussion born of convoluted instructions can hopefully rest beginning shortly ;)

@nickrud I agree with your suggestions ;) @Tannin OK, I was only thinking about the "Overwrite Mod" in terms that it is actually writing changes to disk ... it is not overwriting the source though, so I am guilty as charged for spreading this misinformation. I agree with your assessment of how MO works. This is a good and simple explanation. However, with respect to speaking conversationally about how mod managers work, I think it is important to use a static nomenclature with respect to them all (i.e., overwrite / override, load order / install order). Where this is not possible with respect to MO, then it seems prudent to create an analogous term that is unique and not conflicting with the traditional paradigm. Hence, Skyrim modding "overwrite" = MO modding "virtual overwrite" and 'override' means the same, regardless. One area of complete confusion to anyone not intimately familiar with MO (whether they are modding novices or experts .. or perhaps just me) is the conflation of the concept of "overwrite" and the term "overwrite mod". By your explanation above, the "overwrite mod" could be "maximum priority mod" or even "MO Mod" just to avoid this conflation of terminology (one describes an abstract concept and the other describes a concrete thing). Just a suggestion. Oh, and Truth is Truth and is not constrained to physics and math IMHO ;) I only meant to address a thing that constantly frustrates the hell out of me: the human tendency to name things whimsically or based on some convolution rooted in tradition rather than using logic and reason to dictate what we call things. Case in point: the idiotic 'tradition' of naming databases after Greek gods and godesses :O_o: ... rather than based on the data they contain. For the record, I don't think that you are in any way doing anything analogous to this with respect to MO ... regardless, your program, your call. It is still a valuable tool. We are only talking about semantics here :P Regardless of what you decide to do or not to do, I will not have any trouble following along. I did when I first started using MO though.

Tradition should never trump Truth, IMHO ;) The 'Overwrite Mod' term is 100% accurate. Files are actually changed and overwritten on disk (this is the definition of 'overwrite') The definition of 'override' precisely means that one takes 'priority' over another where they would occupy the same space (be it virtual or physical), but neither is altered as a result. As I interpret it, the virtual directory is assembled on the fly by MO from physical sources that are never altered (except for the Overwrite Mod). This means that all mods and their assets are virtually prioritized as a series of overrides. This differs from the traditional concept of layering game assets on disk and letting the game engine manage only the plugins in a series of virtual overrides. One exception about the traditional physical management of mod assets: BSAs contain assets that are virtually managed, and they can NEVER override a physical asset, but they can be overridden themselves by loose files or by other BSA assets. This is not something that changes anything, but I thought it worth bringing up so that we can be all inclusive about terminology and to what it applies. Now, in order to allow mod-management discussions to include MO along with other mod managers, it is important to be able to refer to a common terminology; therefore, I think that it is important to distinguish file-management virtualization and the differences of MO right up front and then it is probably simpler to use the term "virtual overwrite" wherever "overwrite" would be used when referring to traditional TES asset management. Then all else can remain the same with respect to 'override'. This way all discussions can remain consistent and compatible, regardless of the mod-management mechanism being discussed. SOOOO, I propose changing only all instances of 'overwrite' to "virtual overwrite" and NOT to 'override' for clarity and "nomenclature portability" (except when referencing the "Overwrite Mod"). Otherwise, discussions could get very confusing.

We should be looking at the plugin sort order of STEP:Core and STEP:Extended under LOOT versus BOSS in order to determine which is most efficient and 'correct' with respect to conflict resolution and simplification of creating the STEP Patches. Since MO is supporting LOOT now and not BOSS (AFAIK), then we should take the hint and climb on board ... and we currently are not making any amendments to the BOSS sort order for STEP, which I am certain must have some issues too. Or we should be explicitly defining the correct plugin order in the STEP Patch ReadMes and the guide

Not really clear on the issue. Is this a browser issue (test with a different browser), a site issue (try at a different time) or a profile issue (PM or email nexus support)?

OK, sounds good. Because this is all version specific, we can't really tie your work Semantically into existing Packs and Mods (since they are not version specific). Otherwise, that would be a good way to do this. If you are willing to keep it all up to date and relevant, then it makes sense, but I assume that it could all change as the USPs and mods get updated, no?

Thanks for reviving, DY. For the record, I think Tannin's final proposal is a good one

I like the format, but it seems to be missing some components (sections) that can be reused for all custom STEP plugins> Description - What is it? Why is it needed? Who needs it? I will add a couple of comments to your wiki page ... but are you going to rewrite the other ReadMe to match this format? Consistency of presentation is my big 'thing'. What about this and the Git ReadMe? I'd like to create a uniform look / feel for all documentation and simplify maintenance for updates if you don't mind. Regardless, your work on this is much appreciated

I agree that short and focused videos are the best approach for people like me (and for most others, I would guess). Once Tannin indicates his preference, we will host accordingly. Thanks for taking the time to make and maintain these videos

I have pointed Tannin and the other MO mods to this area for comment, but I generally agree with Keith's comments: MO's primary utility lies in its integration with the Nexus mod catalog and its virtualization methodology. The former makes it super simple to manage mods and mod versioning, and the latter resolves all of the issues associated with file loss and data corruption, which is a huge problem to mitigate with other mod management systems (I used to periodically scrub /Data due to lack of confidence that WB was 100% effective in maintaining file priorities and overwrites ... in fact, I 100% know that WB and other mod managers do not handle this perfectly). WB is still the best tool for learning mod management though, IMO I have not seen the videos (I personally do not typically take the time to learn by video), but I want to recognize that creatiing them requires a lot of work, so it is appreciated. Can anyone confirm that Gamerpoets' videos are indeed linked form within the MO application?