Hi folks, welcome back. Last time I promised you that I'd take you through setting up Advanced Animation Framework as well as rebuilding the body replacers to use the newest versions. However, that experience turned out to be no very bloggable; it basically involved following The Fucking Manual, packing up the loose files into BA2 archives, then doing a quick test run to make sure everything worked out of a BA2. Spoiler, not everything worked. The English-language (or whatever language you're using) interface and strings elements for AAF need to remain loose to work properly. ZaZOut 4 also had some strings with the same naming convention as the ones from AAF so I unpacked those as well, just to be safe. I'll continue doing this in the future if more appear. I also left the entire Ultimate AAF Patch unpacked, as I'm willing to pay the small performance cost to ensure everything from that mod consistently wins conflicts.

 

 

Once I fixed the strings and interface issue, I ran through a quick test run of the game up to that point, and I was able to get AAF Violate to trigger a scene with no problems, which tells me that the passthrough there is working right. Currently, I have pretty limited AAF integration; just AAF Violate, Commonwealth Captives, and of course manual activation of animations through the AAF UI menu. But that's fine for now - if other mods are going to expand on that, I'll be adding them at a later stage in that build. With the AAF install complete, I got a bit side tracked turning the magazine add-on I made during the midst of Charley's Story into a standalone mod, which you can download at the link below.

 

 

As I proceed with building up the custom content for the world in the future, I'll try to continue spinning the different modules into their own mods so that everyone can enjoy those bits of Charley's world. Unfortunately, I do perceive some permissions related barriers that may require me to downgrade some features for use in the public version, such as bespoke builds of TheKite's outfits. Its possible I may be able to get permission for the BodyTalk3 conversion based on TheKite's FAQ, but even that's kind of iffy. That's one of those things I'm going to have to take one step at a time and I can't make any promises about being able to fully share that content. 

 

Today my big goal is to integrate Sim Settlements 2, especially in light of the release of Chapter 3. I'm eager to finish the Sim Settlements story, since I've only played the entirety of Chapter 1 (I had planned to play Chapter 2 later in Charley's story, but that build ran out of steam before I could reach that point). Today we'll begin by getting the mod's underlying framework installed and then loading up the core files for each of the three chapters.

 

 

And of course then I wasted a bunch of time, because it turns out that Chapter 3 actually contains an AIO download that contains all three chapters, and for the sake of tidiness if nothing else I'd rather use that version  Fortunately once I sat through the extra download time, almost everything installed smoothly. There's one little thing I'm seeing that I need to keep an eye on, this asset conflict here:

 

 

If I observe issues with ZaZOut, I'll need to take a look at these text files and see if I can merge them, but I'm not going to get too worried about that for now. As far as plugin conflicts, it was almost entirely top-level cell data, and benign TLCD issues at that (some previs data from one of the DLC was getting its version control data rolled back - I patched it to be safe, but I'm pretty sure this wouldn't break anyone's game).

 

 

Once we got back to Chapter 2 (I was doing conflict resolution in reverse order) there were a few object reference issues, mostly involving UFOP changes being reverted, so I patched those to ensure full compatibility.

 

 

Finally, the original SS2 also had a few little quirks that needed patching. It was almost exclusively cases where SS2 made an object persistent and reverted its other attributes back to the vanilla FO4 master data. Patching these records resolved the issue.

 

 

One thing that really stood out - especially with the interior cell records - was that partial forms cause xEdit 4.0.4 to generate false-positive conflict status. I believe I read that 4.1.5 is a bit better on this, but that experimental branch is still a little rough in some areas so I haven't updated to it yet for FO4. I'll use modgroups to prevent these false positives from coming up on future conflict resolution passes, but I still need to look at them all at least once to ensure nothing else is awry with the records.

 

 

Let's hop into the game real quick to make sure everything is working. Initial boot time and new-game start time were both long, which I believe is a consequence of adding substantial new mods to the game (and in turn thwarting private profile redirection's normal salutary effect on load time). I'll only be concerned about that if it persists over multiple starts in the same configuration.

 

 

AAF started up fine, always a good sign. I do think I need to install Start Me Up Redux after this test so on future runs I can bypass the pre-war sequence and get to testing faster. That'll be good for my new playthrough, too.

 

 

Looks like some MCM translation data inadvertently got packed in the BA2 for AAF Violate. I'll go check on that once I'm done with this test.

 

 

I observed some NPC blackface issues during the opening sequence, which as I'm sure I've said a million times is related to memory issues. I'm not too worried about this currently, but I do need to monitor how frequently this happens during normal gameplay (and not a highly scripted opening sequence with lots of startup activities happening in the background at the same time). And since I canceled the starting video, there was even more startup stuff going than strictly intended. But I digress. The TL;DR version is that hopefully this won't be a big problem in-game, but if I can keep load times under control, saving and reloading will fix it anyway by flushing the memory.

 

 

Saved and reloaded once we reached the Vault. Load time = 5 seconds, well within tolerances and actually a little better than some of the ones I'd timed earlier, which were coming in at 5.5-6 seconds.

 

 

Further examination revealed that saving and reloading did not fix the blackface and it was affecting all female characters and no male characters. So this may actually be a texture mismatch issue, which we'll need to investigate once we're out of the game. Though I have to say... I'll actually be happy if this does turn out to be a texture issue. The memory related black face bug is so frustrating to deal with, and a texture issue is the sort of thing that can be fixed through good asset management in one fell swoop.

 

 

Frame rate is good outside and complex parallax is working, so no signs of problems or overload on the rendering front. Let's go into town and start the Sim Settlements quest.

 

 

I had a little bit of a WTF moment finding those black and white background swatches in the build menu. I may end up pruning those out as I suspect they're not intended for normal gameplay. Otherwise, SS2 started up without any problems. 

 

 

The SS2 tutorial plot built out just fine - no issues there.

 

 

I ran down to Concord next and deliberately botched the combat to trigger an AAF Violate scene. I found it interesting that the raider females also had messed up facegen, even though the screwed up face and body textures were both different. There's definitely something funky going on here.

 

On a brighter note, the collision and placement of the Vioxis strap-ons is much better than my last build. That mods seems to have evolved considerably since the earlier verision I'd used. Real Handcuffs integration is also working well.

 

 

Male NPCs are sill having some issues with properly animating the erections. Requires further troubleshooting.

 

 

Handoff to AAF Bad Ends worked correctly, as did rendering ZaZ fluids. So it looks like gameplay is working properly, but we need to put some time and effort into resolving the face texture issue. First things first though, let's find the over-packed files for AAF Violate.

 

 

There's the interface translations. I'm only going to unpack the English ones so that I can keep my overall loose file count as low as possible.

 

 

And there's the missing descriptions for the MCM, so it should work better in the future. Now let's investigate this face texture business. The Vault-Tec staffer with particularly swarthy skin in the intro is CB1D5, let's open up her facegen mesh and look at the texture paths. 

 

 

Her diffuse map is using a custom texture rather than the facegen texture that my body texture replacer uses. While the game does theoretically generate facegen "live" on entering a cell, it has premade facegen like this loaded into the vanilla BSA files, probably as an optimization measure. I'm going to try a little experiment - let's load up the CK with our character appearance stuff loaded (we'll force the BA2s to load using the CK ini file) and regenerate just her facegen. For now, we'll leave it in the overwrite folder.

 

Hmm, the FO4 CK might actually correctly loads archives and doesn't need a manual override, because there isn't an ini field for forcing archives. Let's try it out.

 

 

No, that doesn't seem to be working. I think we'll have to manually load the assets loose to get it to play nice.

 

 

Now there's a visible difference. Let's see how this looks in the game. Incidentally, as expected (hoped) boot time was much faster on this session compared to the one that followed the big configuration change.

 

 

That's better, but still not quite matching up. It's particularly noticeable when the actor's clothes are removed, causing a "bib" of darker skin that runs quite a way down the throat and upper chest. 

 

 

Then again, I'm not using the latest version of the asset so maybe I should update it before I get too concerned. This mod is also built upon the Ruby Skin mod, so I might also consider rolling back to that version and building against it to see how it looks. 

 

 

That's a bit more extensive of a change than I was expecting. I knew it was intended for use with the Gappy Overhaul mods - and indeed I'm interested in using some of the assets from that series - but I don't think this will fit in very well with my worldbuilding plans. How about with the original Ruby Skin? Though I'm starting to get a bad feeling that I'm going to be forced to switch to the high poly head and just use a different skin than the one that I'd been hoping to go with.

 

 

Still got a very visible neck seam. Let's try one more thing, which is using the vanilla facegen with the Ruby body texures.

 

 

No luck with that approach either. Next stop is to read through the Fusion Girl support thread to see if anyone else has solve this issue. I seem to recall this was a problem with the previous version as well and I fixed it that time by using the high poly face meshes. 

 

 

Fusion Girl 1.8 skins with vanilla facegen almost look right. I want to try one more thing before I resort to using the high poly face. But nope, I won't bother sharing the shots as they're basically identical to the ones above. They didn't look any better.  I think I'm going to call it a night for this session and when we return we'll be drilling into these face texture issues more vigorously. I have a few more things I want to try that might save my ability to use the skin I want, and at the end of the day if those don't work, it won't kill me to use the high poly head - I just wanted to avoid the extra overhead of using it (and the reduced compatibility with some skins).

 

See you all next time, folks!