z929669

Post links to all wanted assets, and we can maybe add some.

SMIM is a comprehensive mesh fix mod, so I think that it would best be covered by that mod ... regardless of who actually does the work (and consistency of quality is ideal ... Brumbek's work will be consistent whereas others' may not be with Brumbek's work).

Indeed. Consensus rules, and users can ultimately do whatever they want for specific choices (although this is unsupported). And who knows? ... maybe the author will release a variant that sways the vote? VW is not perfect or 'better' after all. I just think it is more appropriate for STEP.

I don't advocate Windsong for several reasons as indicated in my posts. Not true to vanilla really, IMO. Too shiny, too much makeup, softens characters, overly feminizes facial features ... too beauty oriented. It also alters the vanilla underwear in a weird way and bundles a lot of stuff that we just don't need. Were it not for the skin tone issue, XCE would be best. The recipe that Tech linked is my favorite combo for pure vanilla compat for STEP:Core, but I still want to look at alt3rn1ty's UNP. The vanilla mesh is the biggest issue. If someone would just fix the low poly issues of the vanilla mesh (jagged polys in hip and armpit areas and elsewhere) whilst maintaining compatibility with all vanilla clothing/armor ... that would be ideal (@Brumbek ... why not?) @roots The Core mandate does not explicitly preclude non vanilla bodies that require mesh compat ... although it is inferred: STEP:Core is NOT about ... ... mods that have a high likelihood of having "data conflicts" with other mods. This would be true; however, downstream conflicts would only pertain to Packs that alter clothing, armors or bodies (a specific subset of Packs). If this is problematic, then it would be a STEP:Extended solution I guess.

Ideally, we want to avoid armor/clothing mesh worries, but if any good female body replacer also comes with or points to a comprehensive set of clothing/armor meshes, that would be fine. The problem is that there never seems to be a simple, comprehensive set of compatibility meshes. they are typically incomplete and scattered across multiple mods, each of which can change at any given moment. not to mention that our users would then need to peruse multiple adult mod pages and confusing file options. PITA.

Just chiming in here ... late to the party (sorry). Realism is good, but this is a fantasy game, so fantasy lighting and looks (and contrary exceptions) are warranted. Nevertheless, I do think that all things in Skyrim --with regard to behavior and appearance-- should do its best to emulate reality wherever possible and wherever it makes sense. Adhere to the laws of physics wherever magic is not inferred. That said, I think that Rustic Windows ('RW' is conflated with Realistic Water) is just too bright in many cases, particularly in the daylight. Nice mod, but not something I would necessarily use for my own game. Windows don't glow outside in the daylight! i have the same problem with fire and lightsprites in the daylight. These are some of my biggest nitpicks ... these are also elements that can be controlled by ENB (often improperly), but ENB is strictly not our concern in any screen compares, and it should not be used. I am assuming that Tech's screens have all been under vanilla lighting, so my argument stands. Based on the info presented in this thread, I think Visible Windows is just more believable all around and that it also looks better in most situations. More detail is not always better IMHO. I also vote this down for STEP:Extended for same reasons. DISCLAIMER: Ultimately, I would have to play extensively with this mod to decide for sure.

Yes, I basically rewrote the entire installer a year or two ago and just did not have the time to replicate the FOMOD this time ... I just reproduced the entire installer for Requiem option :P Since the BAIN installer is not the most used version and those using it are likely more experienced modders, I did not sweat it. As I have said previously, any assistance with improving the installer would be most welcome. Ideally, the BAIN installer follows the FOMOD exactly behavior wise. Also, if anyone comes up with some 'good' custom choices of their own, they can be added to the gamut of presets. The 9 presets I created are the result of many hours of work to replicate sort of the Morrowind treatment of soul gem colors, but there are literally trillions of variations! EDIT: I will create a patch for IS if/when we begin using that ... I actually just learned how to mess with languages and patching in updating this mod, so it is actually kinda fun

Fair nuff

The new MO version is working fine for me with a few caveats as described by others. In order to fully understand the functionality though, I think we need to use standard versions of official content and USPs (i.e., BSAs) and a fresh profile. Then we can begin adding our custom optimized vanilla files and work out a best practice for standard users.

Looks good! Thanks! I just moved all folders up one and repackaged to BAIN format ... wizard doesn't work otherwise ... FOMOD does not seem to care either way though o_O Uploading now.

Good point ... download from Copy. I also corrected the metal Orange thingy, so you should use this version as your new source nd make any changes needed to that going forward. If you could also add in the several presets I created (see BAIN Wizard), that would be great for users. These are some good presets and corresponding images like we have on the mod page. I spent a great deal of time deriving these from the huge number of combinations, so they should be part of the installers. Wizard and FOMOD are almost identical now (except for the lack of 'good' presets in the FOMOD). EDIT: So what was the 'fix' for the external installer?

I just updated the BAIN wizard as well as the FOMOD. I caught some of the FOMOD errors myself and updated info.xml file version as well as some of the text description in the FOMOD installer ... and added a clearer image set for Requiem support. @Tech, could you re-download the version I have on the Nexus and make any corrections you have made since to that? Then I will re-upload. EDIT: reuploading again, so it may be a few minutes EDIT2: Metal - Orange has no image, so if someone wants to provide one, I will use it. Substituting Orange is false advertizing ;)

This looks really good. Thanks guys! I will upload to the mod page now ... wizard should be a relatively simple matter I think.

Awesome. I will try it out when I can ... in the process of selling/buying homes, so I am not spending much time at the keyboard anywhere but at work ... I am anxious to hear input from TheBloke, Keith, Neo and the STEP team though.

I was going to say that people should always use Firefix, but after the pale Moon suggestion ... I am likely switching to that rendition of FF.

I am locking this thread. We have mod threads for discussions of mods, and it isn't necessarily respectful to pick on any mods for whatever reason. No issues with anyone, just closing this.

I heard from Arthmoor that Skyrim no longer uses the file name trick to attach BSAs to plugins ... e.g., modA.esp loads modA - 1.bsa AND modA - 2.bsa. According to him, the file names must match exactly to the left of the extension. This was standard in Oblivion though, so maybe it still applies ... ? It could be tested though.

@Keith I think maybe TheBlokes second post is more comprehensive ... and I do like his theoretical solution if Tannin wants to go with that. I also agree with the notion of user warning 'pop-ups' when a not-so-best-practice situation is discovered. @All I also like Tannin's thinking about managing assets within /Data/, and I agree with his logic on file name as the key to the plugin-BSA match. Furthermore, I like the idea that asset and plugin prioritizations can be optionally coupled (loose or not). Lastly, Tannin continues to allude a very important point: MO should play nicely with other mod install methods, and it should preempt user ignorance wherever possible. This is plenty validation for the idea that MO includes methods of dealing with mods within /Data/. I am just going a step further and postulating the situation where the USPs are also installed that way (think of it as an option for those that want to think of the USPs as official mods ... like me ... because I don't agree with any argument that the USPs are doing or fixing anything 'incorrectly', but that is a debate for another thread if anyone wants to have it). Maybe Tannin's ideas about MO recognition of previously-installed mods within /Data/ are also compatible with TheBloke's proposal. @Tannin Making MO more considerate and accommodating of 'old-school' practices (under Skyrim's revised tenets) and exposing the mechanics to doubters/naysayers and all user classes seems like a worthy endeavor and ultimately why I started this beast of a thread (and no, I am still not ready for the quiz). It seems like you have some good ideas (based partly on others' good ideas), so let us know what you need, if anything.

@Keith Sure, a warning is a good idea. I should be more specific I suppose ... I am advocating special treatment of mods within /Data/. If MO can be made to automatically decipher mod names based upon their plugins, that's fine, but it is not necessary. What I really want to see is MO special treatment of the USP content as if it were official content. If this can be accomplished by auto-detection based on file name (or CRC check), fine ... but for the love of Whatever, please allow MO to recognize and specially handle USP content such that it is treated as if it were Bethesda content located within /Data/ This resolves our issues. If this treatment can be applied to ANY mod within /Data/, that is fine by me, and it can be associated with a warning (and also using special font styling). It will allow us the flexibility required to achieve the desired end result and possibly apply priority 0 rules to other mods as well (and it should be made very obvious that using a 'dirty' /Data/ should be considered Taboo and that the USPs are exempt as 'dirt' ... meaning that nobody should ever install loose assets within /Data/ and that any plugin/BSA mods installed within this location is acceptable, but not necessarily recommended practice). My wish list: I want MO to inherently know how to prioritize plugins and assets associated with the official content and the USPs (priority 0, however Tannin wants to implement ... location within /Data/ seems obvious). I would also be perfectly happy with the idea of 100% coupling asset prioritization with plugin prioritization (as long as decoupling by mod [and globally] is possible). This makes for a very clean and organized and largely automated mod setup. I would also like to see clear GUI indicators of 'special' mods (see #1) and mods that have coupled versus decoupled prioritization (see #2)

I agree with Keith on all points, but I actually prefer option #1 Also, we need to get off the whole SSD/compression debate unless it directly pertains to the topic at hand. It is a sidebar that is detracting from the real issue. Since it has not been addressed: I very much like this idea. It can only help. I also don't see any major reason why you could not eventually implement your original idea (all mods, loose and BSA sort with plugins), especially if we have the option to turn off this feature at the mod level (and globally too would be nice). Action only on mods with BSAs does not make sense, since any mod could (and maybe should) bepacked within a BSA. What is and is not affected would then be arbitrary and nonsensical. I favor the original idea of prioritizing ALL mod assets with plugin prioritization as a toggleable feature. This is a feature ADD, not a detraction. Also, see my previous post about differential text/background colors of mods managed this way versus not in both mod and plugin lists. This way users can tell what list prioritization is relevant to mods in the corresponding lists. I also agree with DoubleYou.

I very much like this idea. It can only help. I also don't see any major reason why you could not eventually implement your original idea (all mods, loose and BSA sort with plugins), especially if we have the option to turn off this feature at the mod level (and globally too would be nice). Action only on mods with BSAs does not make sense, since any mod could (and maybe should) bepacked within a BSA. What is and is not affected would then be arbitrary and nonsensical. I favor the original idea of prioritizing ALL mod assets with plugin prioritization as a toggleable feature. This is a feature ADD, not a detraction. Also, see my previous post about differential text/background colors of mods managed this way versus not in both mod and plugin lists. This way users can tell what list prioritization is relevant to mods in the corresponding lists.

Good question, and I would propose that (if implemented in whatever form) the plugin prioritization list SHOULD NOT translate to the mod prioritization list. Rather highlight (or gray out) the text or background of mods ... ... in the mod prioritization list that are prioritized by plugin list, and ... do the same for plugins in the plugin list that have content that is managed by the mod prioritization. @Tannin Thanks for being accommodating to STEP and all users I like TheBloke's latest ideas about MO 'special' handling of vanilla and USP content with autodetection, auto-sort and text indicators (first option, not the second, less customizeable rendition) I agree with Tech that STEP does not support NMM as a mod manager, although NMM is a proxy for Wrye Bash methodology and should be assumed to follow the same basic principles of WB. (I am currently assembling my thoughts about Tech's concerns and Tannin's revised, "compromise" proposal, so more from me later).

I respectfully disagree with krypto (and you) on that one though. If a vanilla DLC imposes a bug on a conflicting record that did not exist previously, then that is a bug that should be fixed, IMO, however insignificant. Since Beth does not have sufficient quality control or investment in their released products required to fix this themselves, it is within the purview or the USP project to do this. Even for little things. STEP seeks to resolve all such issues outside of what the USP has fixed. I think that mod authors should make the appropriate changes to accommodate properly, given the fix ... after all, mod authors should be finding this stuff and submitting bug reports to the USP team, right? Nobody is perfect, so it is totally understandable that these details are overlooked or even ignored, but in the end, we are talking about mod maintenance and mod authors' work affecting the work of other mod authors. The USP team does keep pretty detailed records, and if I were a mod author (which I am not qualified to be ATM) I might keep abreast with the USP and involve myself in their workflow. OK, this is may be an unfair opinion ... I'll let it stand though and beat you all to the punch by declaring to myself that I shut my pie hole and not tell mod creators what is best for them!

The main plugin should dictate, not the add-on plugins. For STEP, the mod would (should) not have any plugin reference and so would behave as a 'decoupled' mod I hope.