BodySlide is wonderful and terrible, especially inside of MO2.

 

I've a few hundred mods deployed in mo2 and maybe a third of them are active (because, like, I was using CBBE for a while, and now I'm trying FG .. thankfully BodyTalk is pretty stable and I have been comfortable with it... so far. Swimmer body ftw.)

 

Anyways... problems (part 1):

 

• Zaps are a pain (and inadequate -- sometimes I want to move stuff from one mod to another mod, and zaps do not support that), and zap settings don't support batch processing
• MO2 used to let me put output files in a destination mod. That no longer works for me, probably because of changes in the underlying windows apis
• When a mod references a missing nif, bad things happen
• Each mod has documentation and procedures with rules which depend on what other mods I have installed (so enabling or disabling a mod can be... complicated)
• Figuring out what I am selecting when I choose a slider group is... difficult. Some mods don't even provide slider groups.

 

So, batch build tends to do arbitrary things which mess up all my careful work. But not using batch build means that I am likely to overlook something, leading to game crashes or whatever.

 

Of course, all of these problems have "good reasons". For example, we can change the defaults for zaps in outfit studio. (Except some mods don't distribute the outfit studio project necessary to perform that edit. And different mods organize themselves in different ways. So even when this is possible, you sometimes have to figure out the system used by the mod to figure out which outfit studio project you need to work in).

 

Bleah...

 

I cannot solve all of these, not right now. But I can make a dent. So here is my plan (subject to change, but I'm also leaving this here in case it turns out to be helpful for someone who does things I like):

 

1. I can auto-generate slider groups for each mod. This will pollute my group selection with a bunch of detail, so I should prefix the names of these groups to ... group them together. (I want to do this.)
2. I can also more manually build slider groups that represent collections or dependencies for other mods. (I am not sure I want to do this.)
3. I can manually change zap defaults. I rarely care about zaps, so doing this manually should be fine.
4. I can find most recently exported files and copy them to a mod which I can backup (and can make sure overrides any conflicting mods).

 

 

 

---

---

---

 

Details:

 

In MO2, there's a profiles directory and each profile has a modlist.txt which lists the mods I have active (these are just directory names in the MO2 mods directory, but I only want the ones with a preceeding +). That's most of what I need to go find recently updated .nif files.

 

---

 

A piece of armor which I can choose in BodySlide will be a .nif file for the game. But the part that I am choosing is a SliderSet. 

 

A SliderSet gets stored in Tools/BodySlide/SliderSets/SOMENAME.osp

 

The .osp file is really an xml file and it contains a list of slidersets. So I mostly don't care about the name of the SliderSet (except I have to hope that each name is unique).

 

The parts I care about in the xml payload are:

 

The name attribute of each SliderSet element. These are the sliderset names (duh).

The SourceFile text and the OutputPath text. These identify the nif that would be generated from that SliderSet. (Or, if I was working with skyrim: the pair of nifs).

And, occasionally, a Slider which has zap="true". Here, I might want to change default="0" to default="1" (or the other way around).

 

Mostly, for this effort, .osp files are reference material which I would not change. (And, when I do change one, I would change it manually. And maybe I will have to reinstall the mod if I horribly screw up in my edits, so maybe I do backups of them if things start getting messy.)

 

---

 

SliderGroups get stored in Tools/BodySlide/SliderGroups/SOMENAME.xml

 

These are really simple xml files:

 

<?xml version="1.0" encoding="UTF-8"?>
<SliderGroups>
    <Group name="FIXMEgroupname2">
        <Member name="FIXMEslidersetname1"/>
        <Member name="FIXMEslidersetname2"/>
        <Member name="FIXMEslidersetname3"/>
	...
    </Group>
    ...
</SliderGroups>

 

So I can use the mod name to create a group name and list all the slider sets I find in that mod. Some finicky details here, but the concept is trivial.

 

---

 

Finally, there's the issue of missing nifs and my default choices. The key artifact here is BodySlide and Outfit Studio/Tools/BodySlide/BuildSelection.xml and I need to care about the OutputChoice elements in that file. 

 

I might need to do a batch build of everything, to make sure that's populated. then go back over it to make sure that batch build would pick the right options.

 

It would be nicer if BodySlide would give me little reports: .nif files which it could generate which have not been generated (along with the corresponding slider sets), and also the current choices (in a copy&paste form which I could edit or in a proposed BuildSelection.xml form). 

 

But I can probably anticipate a lot of this by working through the .osp files myself. See above.

 

---

 

Anyways, this is a plan? Or, ... almost?

 

---

 

Update: So... of course it can't be that simple.

 

Specifically, I built per-mod slider groups. And it turns out that I also need to populate SliderPresets for these groups, at least some of the time.

 

For now, here's my throwaway code (a cygwin shell script) for building per-package slider groups. I'll need to figure out how to do presets though. It's not useful for what I want, but it illustrates some of the concepts, I guess.

 

And, I probably really want my bodyslide sliddergroup names to identify which preset(s) they support or maybe I need to name my groups based on which preset which i want to use which the members of that group support... Just figuring out here what I am even trying to do is... challenging.

 

#!/bin/sh
# run in mo2 profile directory
trap "echo FAILED." EXIT #
# note: this script must be saved in unix file format
# next line will be invalid if lines end with carriage return
set -e

grep '^[+]' modlist.txt |
	sed 's/^[+]//; s/\r//' |
	while read modname; do (
		d="../../mods/$modname/Tools/Bodyslide/SliderSets"
		if [ -d "$d" ]; then
			cd "$d"
			set *.osp
			if [ -r "$1" ]; then
				tag="$(echo "$modname" | tr -dc '[0-9A-Za-z]')"; export tag
				mkdir -p ../SliderGroups
				cat *.osp |
					grep 'SliderSet.name=' |
					cut -f2 -d'"' | 
					cat <<ENDXML >../SliderGroups/LocalSynthetic-$tag.xml
<?xml version="1.0" encoding="UTF-8"?>
<SliderGroups>
    <Group name="z Local - $tag">
$(
	while read sliderset; do
		echo "        <Member name=\"$sliderset\"/>"
	done
)
    </Group>
</SliderGroups>
ENDXML
				echo generated Tools/BodySlide/SliderGroups/LocalSynthetic-$tag.xml
			fi
		fi			
	) done
trap "echo done." EXIT

 

 

---

 

So... it looks like each SliderPreset lists the groups which it can be used with. So when I generate a new group, I should create an updated copy of the sliderpreset I want to be using with that group. (And, I guess I should write that to mo2's overwrite directory.

 

So... new plan: my synthetically constructed groups are going to be named for the preset I want to use. And, the group file will collect slidersets from a bunch of mods, so the group definition goes in the overwrite directory instead of the mod directory.

 

This exposes the hole which I wanted to address, which is bodyslide outfits which are dangling -- for whatever reason they don't have a good group for me to use. So I also need to build a list of those, for manual review. (And, manual update.) ((And, since I'm going to be patching mods I'll need to add to the mod's Notes field and I'll need to back up the mod in MO2. Sadly, reinstall in MO2 wipes notes from the previous install.)

 

---

 

Further update:

 

I cannot manually edit the zap in the sliderset apparently because the outfitstudio generated .nif also needs to be updated. Ugh...

 

(Modular design failure in OutfitStudio.)

 

---