You're Going To Have To Work For This One
I think I might have to switch over to datestamping with this update instead of trying to work out version numbers. Y'see, while I've had this roadmapped out as the '2.5' update for quite a while, as it turns out it doesn't really fit that structure at all. I don't intend to do anything with the current 2.4 releases of the individual body and head packs, and may not even include the results of this update in the combined .esp for them. And this has actually been the plan all along. I'm just having some ambivalence about how to implement it.
Perhaps I should explain.
Back when I first started this project, I got some requests for single-limb versions of the cyborg bodies. I initially dismissed the idea as unwieldly, but when I started thinking about it I realized that the extensive use of zaps I had adopted during the course of my initial conversions of the Edhildil and Gynoid sets could be adapted to the purpose quite easily. Since I had wanted to do some fixes to the Bikini body, which still had its original physically cut body mesh, I decided to go ahead and experiment with using zaps to build single-limb versions from the rebuilt ShapeData model. It worked great, and that got the whole variable limb sub-project off and running.
Right at the start of that I realized that the zap method would also let me cut down on the number of ShapeData models I'd need to use. Since I'd be using zaps to remove unneeded parts, I didn't need to have a separate base model for the Arms and Blades versions. I could just pile the parts for both versions onto the same reference body mesh and use the zaps to remove the ones I didn't need. So the variable Bikini body's ShapeData model looks like this:
This made things immensely more efficient. Every single variant of the body is built from this (or the copy with the breast bones deleted that I had to make to disable the jello metal and/or boobs clipping through the chestplate on the armored versions) with the zaps removing the unused parts for each variant. This also made doing the Combo Blade/Arm versions a breeze, which... Suggested further avenues of thought.
If I can do this for one body, why not for all the bodies?
I mean, ALL the bodies.
The ShapeData models for the variable Edhildil and Gynoid sets looks a lot like the one for the Bikini set up there. Simpler, actually, since they've only got the one set of limb parts to worry about. But that's just because I wanted to keep them independently usable.
What they were originally built on is this:
If you can combine the parts from two bodies and use zaps do combo versions, you can do the same thing with as many parts as you want.
Any parts. In any combination.
I've been working towards this since the first variable limb release with version 2.2. Each successive set was built on top of it, then stripped out to give me a 'clean' base to build the variant BodySlide files off of. So I've basically been working on those knowing all along that I would immediately make them kind of redundant. But I was already pretty well committed to the idea, and they were a very useful learning experience. Both in the general mechanics of how to set something like this up, but also in terms of, well, scale.
I underestimated how many variants I would be dealing with when I decided to make individual armor files for each possible limb combination on the variable sets. I was figuring, oh, maybe a few dozen.
I am very bad at math.
Every single part increases the number of potential variants. The Bikini body wasn't too bad, but only because I punted on the legs. The Gynoid would've been simpler if I hadn't stumbled over the knee thing. And the Edhildil set was always going to be a pain because of the panties, that's why I did it last. Each set saw the number of variants increase, until I had a couple hundred between the three just to cover their basic individual limb possibilities. Then add the armored versions and double that number. And again, that's just for the variants within each set. Mixing the sets together causes the number of possibilities to go up exponentially... While still not even beginning to account for all the stuff I've been building recently.
My current working ShapeData model looks like... This:
Trying to build individual armor files for each possible combination from that would be, quite frankly, insane. So I'm not going to do that.
I'm going to let you do it.
Well, some of it, anyway.
I give you the Dwarven Biological Automaton Framework.
The Dwarven -BAF- for short. ( The -dashes- are to keep it from getting stuck between the Dwarven Cyborg and Armored Cyborg in the inventory list.)
What it basically is is a cleaned-up copy of my working file, with none of the zaps hidden and no parts pre-selected like they are on the current variable limb sets. Each BodySlide file presents you with an unaltered body, and by selecting the zap for each individual part you can mix and match them to create the cyborg of your choosing.
Every part currently built for the Dwarven Cyborg Collection is included, aside from the half-legs from the Edhildil Disassembled model. A couple, particularly the Gynoid knees, require other parts to be enabled to function and are denoted with [brackets] around their name. All have left/right zaps aside from the original raised Bikini legs, which only come in pairs. Both the raised and Disassembled NiOverrride settings are provided for, thanks to an interesting quirk with how the zaps work; The NiO data only needs to be applied to a single sub-mesh in a .nif to produce the height effect in-game, but any sub-mesh removed by a zap is deleted entirely from the output model. Thus the NiO settings can be applied to a set of tokens, small copies of the Sphere's crest mesh buried in the chest and disabled by default, which can be un-zapped for use with the appropriate limb layouts.

The built bodies are named in two numerical series, the Model A series for the Armored versions, and the Model N series for the unarmored 'Nude' versions. These are linked to the corresponding armor entries in the Creation Kit, both as the outfit and as the first-person model, so whatever you build in here will be exactly what you see in-game.
And you can build anything you want.
Along with the Bodysuits and new limbs previously previewed I have also added, for your pleasure, shrunken-down versions of the shoulder spheres from the Bikini full automaton bodies that can be used to connect the Bikini-type arms to the other sets' shoulder caps (it was built for the Gynoid set and is labeled as such, but it works fine on the one from Edhildil's too), and alternate breastplates via the Sexy Vanilla Armor and UNP Spice sets. The Sexy breastplate is similar to the Remodeled version I've been using, aside from being a bit more open at the shoulders and missing that little backplate, but is a much higher-poly mesh and as such should work well for those who like more weight up top. The Spice breastplate's comparative broadness sadly conflicts a bit with the Gynoid shoulders, but that shape gives it a certain... something.
Of course, doing it like this presents certain problems where the extremities come in. I can't second in meshes to the armor entries or block off slots, because I have no real control over what limbs you're going to put on any given model, and the existing hands/feet sets for the variable bodies don't cover all the new combinations. So the -BAF- gets its own collections of hands and feet.
Like the bodies, these are all built from a ShapeData model with all the relevant meshes piled in, and the variants generated in Bodyslide. My initial thought was to just give you a numeric sequence and having you build your own like with the bodies, but keeping track of that seemed like a fundamental impossibility. So these are pre-built, covering all the major variants- 100 items in all, currently, making this the bulk of the mod at the moment. I skipped doing mis-matched combos of the Gynoid and Edhildil foot variants, since they'd pump the count up exponentially, but I did do it for the Gynoid's bladed/regular hands as they don't add that much. They're all labeled to denote their combination, left-right, with a simple initial code. LBG for Left Bikini Glove, RBR for Right Bikini Robotic, etc. Ground models for them... might have to wait until the next update, at least for the combos that don't already have one. I want to get this thing out at some point, after all. (Ground models for the bodies obviously can't happen, so they all get the Dwarven Amputee marker.)
I also tossed bare human feet into the mix, marked as H, to provide options for some more ragged-looking one-legged cyborgs. I tried to add human hands as well, but just tossing the models in and trying to get them to conform with the arm sliders did not go well. Might try to get that into an update as well, but I think I have to basically rebuild the entire ShapeData model around them to get it to work, so that's getting punted.
Much more important for the immediate utility of these bodies are the Null parts, LN/RN. These are, quite simply, nothing. They have all the parts on their side zapped off, giving you the 'missing' hands and feet you need for not just the one-armed variants, but all the weapon arms, beast legs, and Bikini set legs.
An amusing side effect of this is that since it doesn't have the gloves incorporated into the armor file like the Bikini body does, you can now have Bikini-style arms with just the bare rod waving around.
Also, a NiO setting for a Disassembled version version of the new Edhildil leg caps was included in the body files. Combine that with the beast arms and Null gloves for some mild hilarity.
In further addition to the regular series of bodies, you may have noticed the 'F01/S01' numbers in that inventory list above. These are dedicated entries for the Bodysuit concepts that I ended up having to do via skin texture swapping in the Creation Kit, the Burned Astrid and Rubber Coated skins. Or as I'm going with here, the Flame-kissed and Shockproofed bodies. They differ a bit, in that you can't see their skin effects in BodySlide, only in-game. The zaps for the other suits are hidden on their files, so when you generate a body it will always have regular bare skin, thusly:
...but will appear with the appropriate skin effect in-game.
The rubber works great (although I rather suspect that the quality of the shape will depend a lot on your normal map) but the burned skin is still a bit on the iffy side. I replaced the re-used Vanilla specular with an entirely half-assed one made by simply greyscaling the main texture, and it works adequately. But there's a further problem in that the burn patterns on the main texture and the normal map don't quite match up.
It's not bad enough to be a dealbreaker, except for maybe the big patch on the back, but it is annoying. I've currently got these allocated three model entries each, but I think I'll cut the F down to two and give the S four.
Which lets me awkwardly segue into one of my points of ambivalence, which is exactly how many of these I need all together. I'm actually quite a few days (further) behind on this due to becoming dissatisfied with how I had been presenting it. 'BAF' was my original working name for this, taken from 'build-a-figure', but I had intended to change it to 'B-A-B', for Build-A-Borg. Had it all blocked out, all the BodySlide files built, was starting in on the CK work... And it just looked too goofy. Too jokey, too far out-universe for my tastes after all. Gave it some more thought and decided that I liked 'BAF' more, and everyone loves frameworks around here, so this is what you're getting. But as a result I had to go back and rename all the stuff in BodySlide, and while I was at it completely restructure the body files because I had also come to the conclusion that I had approached those completely backwards.
The way this was initially built, you started with everything. That third image way up there, basically, and you had to deselect parts to whittle it down to the final body. That's why there's still zaps for removing entire sets in there; that's how my workfile for the variable limb sets was built, and as I said this is basically just that file expanded and cleaned up. But it's expanded too much for that to be a viable method. I did it to build the batch of output models I needed for the CK work, and holy crap was that a chore. Inverting it to an additive process makes it a lot simpler, and I also swapped some things around so the zaps all flow right to left, limb-wise, so they match up more intuitively with the preview. Having most of them the other way around was not helpful for this stage, but I'm afraid that's usually the way I do my masking.
But while I'm quite happy with the results of those decisions, I'm unsure about the last thing that trial run convinced me to do, which was to cut down on the number of model entries themselves. When I was very first brainstorming this idea months ago I was all set to go for the gusto and add in fifty slots each, but going through the experience of the variable limb project tempered that some. Not enough to keep me below twenty-five for the normal bodies and five each for the skin-swappers, though. Part of the reason I've been looking forward to this part of the overall project is that building new BodySlide files for this is so easy, all you have to do is change three numbers. Everything else stays the same! I could pump out a hundred of these things.
Actually running the bodies for a hundred, however, would be a drag. Doing seventy, especially with that initial reductive method, turned out to be impossible. I only finished off the armored set before running out of ideas and giving up, and that took hours. In the rebuild I cut it down to ten each for the normal models, and six each to split between the skin-swappers. The new building method saves a lot of time, but that was still starting to push the limits of my inspiration a bit. I'm loathe to cut it down much further than that because I do want to give people room to be inventive with this, but I can't really expect to push anyone else's limits more than I'm pushing my own.
Probably the biggest upside to using the additive method, however, is that if someone were to, say, negligently batch-build this set they'd just end up with a bunch of basically nude bodies. And not the shambling monstrosity that would be that 'everything' pile.
Or maybe that's a downside.
Either way, if all this has got you dreading the amount of effort I'm demanding of you, fear not. I fully intend to have some 'pre-built' bodies set up for this as well. In their own separate slider group, so you can just batch-build them without any worries. At the very least I'll have some basic sets for the new parts made, especially since trying to roll them in to the existing variable limb layouts is not super-high on my list of priorities. And I've got to give @Holzfrau something to work with, since the 'build-your-own' concept doesn't really work for Augumentation's setup.
I don't have any of those pre-builds actually, well, built yet, though. Not that they're hard, just a matter of some simple edits. I mainly wanted to hold off on them until after I got this preview post up because...
I am throwing the floor open to suggestions.
If you have any particular combination you'd like to see, let me know in the comments and I'll toss it onto the list. Within reason and the limitations of the existing parts, of course.
Now, my other and actually biggest point of ambivalence is how exactly to distribute this. Well, part of that I'm not ambivalent on at all; like with the other portions of this project I fully intend to offer this with its own stand-alone .esp file. I don't know if anyone actually uses the ones for the other body sets, but it's probably something that's a bit more useful here since it offers a chance to use the -BAF- pack by itself as a sort of 'DCC Light'. The variable limbs project had the unintended side effect of making the DCC freaking ginormous. I've lost count of how many individual bodies there were, and having them all built with .tri files takes up 3.65GB on my system. The -BAF- by itself, on the other hand, is currently just 342MB all built, although that will go up when I get the pre-builds in.
But the part all that does make me ambivalent on is if I want to keep this in the combined .esp, where I've been building it, or roll it off to its own completely separate thing like the Extras pack. On the one hand I'm not super keen on .esp count bloat, but on the other I'm also getting terrified by just how much stuff is in that combined .esp's inventory list. The Edhildil variable set kicked me over to two pages in AIM, but the thirty-two bodies and one hundred accessories I've got made for -BAF- so far- and a lot of those hands and feet are, again, basically redundant- push the split all the way up to the middle of the Skull heads. I think I've even managed to well and surpass the item count in TAWOBA. And I've still got those pre-builds, how ever many of them there ends up being, and if/when I get to rolling the new Bikini and Edhildil limbs into those packs... Christ, I might hit page three.
Future plans are also a consideration. One of the things that's been on my to-do list is making some simple NPCs/followers. I initially figured they'd either be in their own separate .esp, or maybe something rolled into and exclusive to the combined .esp, but the -BAF- seems like a more natural home for them since that's what I'd be using to build most of their outfits. But that plan would also require more redundancy as I'd have to carry over any of the accessory and outfit pieces I want for them from the other packs. Honestly, I've been kinda 50/50 on this either way for weeks.
Anyway, I've rambled on for far too long. Just a couple more things to mention, in the form of some more tidbits for the extras pack, as presented by my current tester character as part of her usual outfit:
The Spice pauldrons and Sexy belt (from Diablo's UUNP version) parted off for individual use. The belt works quite well with the modesty plating, and as you can see the pauldrons work in a rather interesting way with the Gynoid's cut-out upper arms.
Quite well indeed.
3 Comments
Recommended Comments