VulcanTourist

Oh, it is indeed irony: the same people who preach the exclusive virtues of MO2 typically also mention LOOT, as if somehow its features are absent in Vortex. When I point that out, or that the lead author of both is the same person, it has no effect at all. Nope, the delusion can easily withstand these mere facts. They aren't truthy enough, they're fake news!

From a Reddit conversation: I'm encountering this sort of skepticism, even bordering on religious fervor, repeatedly in conversations about mod managers. One person described Vortex as "utter garbage". The people who hold this perception cling to it very stubbornly; there's no objective facts that will dissuade them from it. I have yet to see one such person even acknowledge the possibility that their view might be distorted. These are the MO2 Disciples who act as unpaid missionaries for the One True Mod Manager.

I replied to your thread in General Mod Author DIscussion. I thought that I had read recently that SSEEdit might actually be avoiding this complication, so long as you make the effort to load ALL your plugins prior to the compaction so that it can check the other plugins that are present. That of course doesn't eliminate all potential, since there might be other mods you don't have that are reliant upon what you intend to compact. Assuming your mod list is complete and stable, that risk would be minimal. So I wonder if SSEEdit actually does this or if I misunderstood something I read?

Ideally what you are looking for is a variant of Dragonscale armor that has either (a) separated the pauldrons from the cuirass and moved them to another body slot or (b) included a BodySlide "zap" slider that can be used to remove the pauldrons entirely and rebuild the set without them. Both techniques are becoming commonplace now, but I don't know of a mod that does that specifically for Dragonscale.

Wabbajack.org is the only reasonable option suitable for lazy or inexperienced people unable or unwilling to learn.

No one who hasn't been sitting behind you the whole time can offer any useful suggestions when you've offered nothing of substance. A crash log from .NET Script Framework would be a start.

I don't EVER want to merge plugins... UNLESS I have a tool to record an audit trail of the entire process in a reversible fashion, such that when updates appear for mods that were merged the updates can then be applied to the merge. In a discussion the other day, Tannin hinted that he might be trying to conceive how to implement such a thing in Vortex. All I want to do in the meantime is able to Lighten as many plugins as possible. "Possible" has meant, thus far for me, Lightening every ESP that can be that doesn't also require compacting FormIDs; I am wary of screwing things up attempting to do the latter when I don't yet understand the process or consequences. If I had a tool that extended Vortex's "Make Light" function to every potential ESP and not just the most trivial ones, that would be useful to me.

That is an essential ingredient in my mod recipe.

Practically speaking, they have to be installed and "in your load order" before tools like SSEEdit can even see them. Yes, I know that I can just manually extract and drop some ESP file into Data and SSEEdit will then see it, but I have no audit trail at all for that process. Actually installing it (in Vortex) gives me that audit trail. I don't see how this process is harmful unless that load order is actively being relied upon in an existing saved game. Is that what you meant to imply? The process isn't "harmful" in a strict sense. When you compact form IDs and then turn the plugin into an .esl or "ESPFE" file, the plugin will technically work fine. Problem is: Compating form IDs changes said form IDs. And this can be bad in an already existing game. Items you already acquired are gone, because the save game contains the "old" form ID, which doesn't exist any more (or belongs to a totally different object). In fact, in my personal load order (400+ plugins and counting....) there are many files I turned into ESPFEs after I compacted the form IDs. Not a problem for me, since I already start my playthroughs with these changed files. My older savegames however aren't fully functional any more... Have I read elsewhere that compacting FormIDs is potentially harmful if other plugins are dependent upon the existing ones? If so, can that be avoided or resolved to allow it to be done?

I daresay you might lure some modders from the fold devoted to your earlier work if those features made an appearance.

I didn't think it would have anything useful to do (should have specified the game), but I was asking to be sure.

Uh-oh, something else that I didn't discover through simple experimentation....

What the Deployment phase "merging mods" actually do?

As I said, I knew that I had exceeded the limit even before I saw that the text had become invisible: I was actually looking for how Vortex would choose to notify me that I had exceeded the limit, and that is when I noticed it. I know precisely what I need to do to correct it, but I was at the moment more interested in "getting mods into the list" and working out the issue later. At this point I've ESP-FE'd all the easy choices, I'm not yet comfortable with compacting FormIDs to Lighten more, and I'm dead-set against having to merge any mods and create a maintenance mess. There might be a small number that I can consign to the wastebasket; I'm in the midst of a between-games reevaluation. A big - flashing? - warning icon next to it, and/or an explicit notification, would definitely be preferable. The text color change has to survive thematic changes, which is more difficult to guarantee unless the text has its own background color independent of the theme's background. That is, I suppose, another option. This behavior has been developing over some weeks; it might be getting progressively worse. It's not restricted to working with mods or Deployment, as demonstrated by this episode when it was unresponsive while I was trying to alter the theme. In fact, it seems to be UI-related and might be occurring at any time other than Deployment. I have not yet taught myself to check Vortex's log, but that is a wise idea. At the moment, I'm editing the "Colorblind" theme to make it more effective, by copying the color choices of Contrast into it (it resolves the OP issue for me). Contrast seems to have been adapted from Compact, and while I might prefer the denser lists I don't prefer the pop-out menu icons text of those two themes.

It needs some sort of a visual cue to its existence and collapsed state, similar to what the left nav sidebar has, except that in this instance the visual cue will be the entire cue since the right sidebar fully collapses unlike the left. It could be a very narrow frame along the right margin with an interactive flattened arrow in it... a very common tactic. Even better might be to permanently preserve the arrow that already exists to collapse the sidebar, instead leaving it visible in some fashion 100% of the time, as is the one for the left sidebar (though that never collapses fully). A compromise of a bit of real estate might be necessary, but I'd argue that it's a necessary compromise.

That's the mucking that I was attempting, but I didn't spend much time at it because Vortex was in one of its sluggish unresponsive moods, making me wait for an exceedingly narrow window for it to acknowledge clicks, and I gave up.

Of course it's supposed to represent the plugins count as seen in the upper right corner of the Plugins tab, but when the base limit is exceeded then the color of the text changes to this unreadable hue. "A rose by any other hue is still just a rose"... but how can you tell if you've held it up against a backdrop of the same color? I tried mucking with themes for a few minutes, but could not contrive a satisfactory resolution. My resolution must be reducing the base plugin count to not exceed the limit so that the text once again becomes readable....

Practically speaking, they have to be installed and "in your load order" before tools like SSEEdit can even see them. Yes, I know that I can just manually extract and drop some ESP file into Data and SSEEdit will then see it, but I have no audit trail at all for that process. Actually installing it (in Vortex) gives me that audit trail. I don't see how this process is harmful unless that load order is actively being relied upon in an existing saved game. Is that what you meant to imply?

That feature could be better self-documenting. It's not at all obvious that double-clicking in a certain region (only) of a given row will accomplish that. Further, unlike the left sidebar, when the right detail sidebars are collapsed there is no visual indication that there is "something else out there" that is currently hidden.

I exceeded the base plugin index limit in Skyrim Special Edition today (knew I had done so), and I was surprised by how Vortex chose to notify me. Can you read this with ease? Both my wife and I struggled to decipher it. I have red-green colorblindness, but she does not. I also happen to be using the "colorblind" theme, which seems a bit ironic.

@G4M3W1NN3R, you should start and curate a Wabbajack mod list whose sole purpose is to collect every single CBBE armor mod that has ever been published. :-)

From the direction this conversation has taken, apparently the goal was to educate US about the (lack of) need for skeletons rather than request it....

A female modder is more likely to make that happen. :-)

Nope. In order for that to happen, the armor mod would actually have to specify the body mod as a master (assuming that it has a plugin to declare). I don't have a single CBBE-based armor mod that declares CBBE or CBBE 3BBB as masters, and they shouldn't; it's not necessary for them to be able to use the body replacer's assets. Some do in fact declare other masters beside Skyrim.esm, notably Heels Sound.esm. Has there ever been a UNP armor mod that declared the body replacer as a master?

There's also a mod that patches the original's ESP to ignore the original custom body and texture and use vanilla/replacer ones instead: https://www.nexusmods.com/skyrimspecialedition/mods/19441 Something to think about once you're done porting. All you should really need to accomplish this particular port is SSEEdit and Cathedral Assets Optimizer. When you download it in Vortex, Vortex will note that it's "incompatible", but ignore that and proceed with deploying it, as you generally need the files in place in order for SSEEdit at least to be able to act on them. Once you're done, re-Deploy and Vortex will whine about altered files, to which you can respond to Save them, which writes your porting changes back to the staging folder and makes the effort semi-permanent. To make it fully permanent, you would then need to re-archive the contents in the staging folder as a new mod, Remove the original entirely and then use Install From File to import your ported version. That's of course assuming you don't attempt to publish it and then download it again from NexusMods to install it....