migal130

When BBLS was pulled with the rest of my mods, some users came to my discord and told me it was removed from their Vortex archives so they couldn't re-install it. They were trying to figure out how to get it. I don't use Vortex myself so I can't say exactly what happened.

Moving an abode/building from one location to another is no easy task. All the landscaping has to be redone. This can range from minor to major work. The point I'm making is that it's one thing to port an abode mod for SSE, but it's an entirely different thing to port the mod then change its location.

Removing the facegeom nif files should solve the problem. But, if you are modifying vanilla NPCs, those files should not be in a folder named after your plugin (even though the game puts them there when you save your plugin). Those files should be in Skyrim.esm, Dawnguard.esm, etc..

Alternatively, you can just press <ctrl-F4> and it will put the files in their proper folders. However, something is different between that method and the automatic method and I'm not yet sure what it is. When you force a facegen export by pressing <ctrl-F4>, the resulting files will be a significantly different size than if the same files were created just by saving the plugin.

The old CBBE and UNP both work fine in SSE. Even those modified and saved by Bodyslide will work. Just copy the files over to the corresponding SSE directories. Furthermore, Ousnius stated that the new version of CBBE for SE will have compatible UV maps, meaning it will be able to use the old CBBE textures. And if that isn't enough, CBBE textures look fine on the vanilla body mesh, so long as you don't remove all the clothing, which would display the under-breast shading. As with the old game, UNP textures are likely to show some nip on low cut outfits, but otherwise look okay.

What you're requesting isn't really the way Skyrim's AI is designed. Skyrim uses AI packages, which are pre-programmed behaviors for NPCs. Generally speaking, unless they are traveling, on guard patrol, or performing a specific scene, most packages are of the sandboxing variety. Sandboxing packages cause NPCs to interact with interact-able objects within a given range of their environment. When you come home and see your wife sitting in a chair (or your housecarl, or a bard in a Hearthfires home, or one of your children, etc.) it just means that their sandboxing package randomly chose the chair for interaction. If you removed all the chairs from the home's interior and instead had nothing but alchemy tables, rest assured, the same sandboxing package would cause the NPC to use one of the alchemy tables. You create schedules with packages by having a lot of different packages set to run at different times of day. However, packages cannot be shorter than one hour long, so there are only so many an NPC can have. A package can be designated to interact with a specific target. For example, you could create a package that forced an NPC to use a specific blacksmithing station at 12pm. However, they would be using that blacksmithing station for a minimum of an hour, because of the minimum package length, unless you created cut-off packages and placed them higher in the NPC's package stack, either directly or via quest alias. Packages with specific targets are good for things like making sure an NPC sleeps in a specific bed. The NPC is going to be there a while, so the minimum package length doesn't come into play. If you want an NPC to start doing things like making potions out of ingredients for you, it's going to involve quest scene creation and scripting, which is significantly more complicated. And even then, I'm not sure it would be possible to do everything you described exactly how you imagine. I'll put it another way. The original Skyrim is five years old and there are a ton of amazing mods for it, but I don't believe there is a mod for it that does what you want.

I don't believe this will be truly available until SKSE64 is released. My mod for old Skyrim, BBLS, allows you to do it (create legitimate custom NPC outfits and assign them to NPCs via dialogue), but making it required both SKSE and the SKSE DLL plugin, PapyrusUtils. Vanilla papyrus functions/commands provide no options for such functionality. If you give an NPC something to wear, they will only wear it if it is a higher value than what they are currently wearing, and only if they are following you at the time. When you dismiss them, they will switch back to their default outfit when you change cells (get a load screen). I can't fix this until SKSE64 is available.

I've converted my bards mod and it wasn't necessarily easy. I had to figure some things out. NPC mods that used the old RaceMenu plus NifMerge to make custom facegeom NIFs are not going to be compatible. You have to load the ESP and save it in the new CK. Do NOT press <ctrl-F4> and force an export of the facegeom. Then you have to copy over the old facegeom NIF and modify it to work with the new game. This involves adding the Has Tangents vector flag to all head parts except the head itself. If you see a mod with particularly cute characters, that's how it has to be done (for now, anyway). Those faces weren't made with the old CK's sliders in the CK. They were made with RaceMenu or ECE. I don't know if this includes the Bijin series (I haven't checked yet to see how he made them). It will definitely include the majority of Asian NPC mods and a lot of follower mods. FYI, after converting my mods, I spent almost a week trying to figure out why the heads were a slightly lighter shade than the bodies, no matter what texture set I was using. Then I removed my mods and all texture sets and looked at a vanilla NPC. All vanilla NPCs, both male and female, are also showing a lighter head than body, even when using the vanilla textures and NIF files. Nice job, Bethesda.

Your first sentence may be true, but the second sentence is definitely not. SSE facegen head nifs are a different structure and are made to work with the new shader and lighting system. They also won't allow certain geometries the old game's head nifs would allow. If nothing had changed regarding facegen, then we could use NifMerge to simply convert the old game's head nifs into head nifs for the new game, but we can't. NifMerge can't even open head nifs made with the new CK.

Hi, Sydney. I haven't figured it out yet, but I've been working on it for the past few days. - The black head seems to happen no matter what. - The new CK auto-saves facegeom data in a folder named after your plugin when you save the plugin. But, it does not auto-save to the folder named after the original (vanilla or DLC) plugin, where the old CK would put them when pressing <ctrl-F4>. - The new CK will work like the old CK when you press <ctrl-F4>, it will put the facegeom data in folders named after the original vanilla or DLC plugin. - You'll get the black head no matter which way you do it, or if you do both. - It's possible a bug in the new CK is involved regarding saving of the facegeom data. It would make sense for them to change it so facegeom data was saved in a folder named after your own plugin, because then you could get rid of the old grey face bug by simply adjusting your load order. That may have been their intention. - Or, it's also possible it is supposed to work exactly like the old CK and facegeom data is always supposed to be saved to the original vanilla or DLC plugin folder, meaning the auto-saving to a folder named after your own plugin is the bug. I've seen some opinion that this is the case, but I can't verify yet, because no matter where the facegeom data is saved, the heads are too black to see what the face looks like in game. - Head nifs from the old game will work in the new game due to a degree of backwards compatibility and they will not exhibit the black head problem. However, if the head nif was the result of a RaceMenu/NifMerge session and includes custom mesh paths for things like eye geometry or 3rd party hair, those geometries will be missing in game. This may be an issue having to do with quads verses triangles, but I'm not sure yet.

Same.

A condition frequently used for this is factions. If an NPC is in a faction, then they get the dialogue.

BBLS (my mod) has a lot of tifs. Testing so far indicates it can raise the count by up to a thousand. But, it's very hard to tell the max for sure. I probably have over 300 quest aliases in the mod, although they are never all used at once (maybe 40 max can be employed simultaneously). There are a huge number of scipt fragments from topic infos (several hundred). However, the real offender might be the follower stats display that comes with the mod. You can ask a follower to show you their stats and you get a display of all their spells, perks and other stats. As you can imagine, those scripts required a large number of properties, somewhere in the neighborhood of 500. The display is useful, because it allows a player to know what kind of gear they should be giving a new follower. But, if having that one quest is causing a string increase in the save files that corresponds to the number of properties in its scripts, then I should probably remove the feature from the mod, which would disappoint some users, but allow me to avoid as many potential string complaints. Going to start following over at LL where it looks like most of the conversation has taken place.

If what I've seen here about quest properties getting saved even before the quest has ever been run is true, it means the only way to control a potentially high impact quest would be to remove the quest, not manage whether or not it is running. So, if I understand correctly, topic info fragments offer a degree of immunity because their string increase is temporary. Quest advancement fragments do not. I'm wondering about fragments attached to other things, like AI Packages. And if topic info fragments are handled better in terms of the string count, does that mean it would be smarter to place properties and what would normally be main script function code inside topic info fragments rather than the quest's main script? That is potentially a ton of raw code duplication. The irony here is that we're discussing a possible best practices scenario that goes totally against the way game company itself operates. I've seen the number of globals and unnecessary private variables in the Hearthfires DLC and it is astonishing.

If any of you are using Dudestia's Multiple Marriage mod or his NPC Clothing Maintainer mod, both are known to break the pool's stripping effect and that's why they are mentioned on the BBLS incompatibilities list. Also, any kind of mod that makes NPCs undetectable by traps. That's what the Suite's beds and pool are, they are basically clothes-stripping traps. I'm not talking about the light-foot perk. That only matters for pressure plate traps and doesn't effect the way the pool works. I'm talking about a mod that might make NPCs invisible to regular geometric trigger objects. I don't know if such a mod exists, but if it does, it would be incompatible.