DrakeTheDragon

Well, this tutorial was made by one of the "other sources who know better than me" I mentioned in my 1st post above, so I'm pretty sure their tutorial is still valid. But they already said it won't work with the Vanilla head mesh and only with Head06. Now, I don't know whether Ren's head was made from scratch or reshaping the Vanilla head, but chances are it's the same reason the tutorial won't work for the Vanilla head, if it runs into issues with Ren's head now. Coming to think of it, it could even be their one deviation from ThrottleKitty's path they mentioned responsible for the issue with eyelids. The heads in this game have specific "unapplied" location and rotation properties, exactly for the reason that they appear far away up from the origo in game while their internal location is close to the zero point still, so morphs will work. All this talk about eyelids dropping down to feet in their comments makes me think their head's internal location is no longer around the zero point for some reason, so the eyelid morphs will move them down to the feet, where the zero point actually is. But that's just speculation on my part based on the context of what I read. I'll have to give the tutorial itself another close look first, before I can possibly see where exactly the eyelid issue might be coming from or how it could potentially be prevented. But from what I recall (from when I looked into it closer the last time) and read on the page and in the comments, it sounds like it contains lots of exactly what I was telling above: Not to directly import and/or export from or to NIF but to use OBJ instead to keep the vertex count and order intact, not to use any scripts to prevent changes to vertex count or order from happening, and not to do any major changes or new unwraps even to the UV map either for exactly the same reason. Unless they leave out one particular important point or do something else important differently in a way that would mess things up, I'm not seeing why their tutorial for reshaping Head06 meshes all of a sudden would no longer be valid, only that it also might not apply to Ren's head either.

Hmm, going by these pictures it looks like apart from the Sui GUTS mod everything else is set up and working correctly already so far. Even Archive Invalidation seems to be alright, as these are proper HGEC body meshes and textures I see. The only thing I don't see is the Sui GUTS stuff. So we should really check that one's installed correctly next.

Hmm, that's actually how modding this game works, or loose file replacements specifically. A Vanilla game doesn't have any of the folders and just loads all assets from inside the BSA archives (well, they are archives, like ZIPs, but writing it "Bethesda Softworks Archive archive" like I just did looks odd). With proper Archive Invalidation the game will use individual replacement files from folders of identical structure to the BSAs' over the internal ones, but it won't use an empty folder when there's still other files for inside that folder in the BSA. It's basically pretty good in "merging" those things. Now, there could be an issue with how your Archive Invalidation is set up, which could cause the issues you see. But if it's set up properly, then the issue with the pink sky and other assets must lie elsewhere.

Hmm, your question, or intention, doesn't make much sense, but I think I know what's going wrong here. Do you have "Archive Invalidation" properly set up already? Without it a retail disc version game will not use replacement textures over its originals, and a Steam, or GoG, version game will not use any types of replacements at all. I take it you're still seeing a regular Vanilla body when nude, meshes and textures still the old? Then, what distribution of the game are you using? (Steam, GoG, retail disc, etc.) And what's your choice of mod manager, if you aren't installing manually? Most, if not all, mod managers I know will be able to apply correct Archive Invalidation by the press of a few buttons (when there's options given, it's always "BSA Redirection" or "Archive Redirection" or other similar names, just not "... Alteration" or the antiquated traditional way). Only a few, or one, will be able to fix the wrong file dates of BSA files downloaded from Steam or GoG though, which will counteract any attempts at Archive Invalidation or replacement files. The game will not use an older replacement file over a file inside a more recently dated BSA. And those distributors often date them with the time of their download, thus way too "new" for any replacements in existence ever to be considered newer. If you need help with that part, let me know, but then also give the answers to the questions above as it will change the chosen solution like explained. And now why the intention or question as expressed doesn't make much sense: There's 1 body model (4-5 sets of NIF files) per gender but for "all" races, and the skin textures are set up on a per-race basis, and not necessarily fitting the models at all. So there's no connection between the texture and the model inside the game, or the texture controlling which model to use. Only the race saying which texture to use on the one single model for all. But that's just technicalities. I think we should make your game use the correct body replacement first. Once it does this we'll also have fixed it not using the correct textures, too (same cause). edit: Oh, my, and just now I realized that mod isn't exactly packaged in a regular folder structure either. So we might also have to check if everything's "installed" correctly to begin with. The instructions in the description are not much more help, as the crucial file paths listed have been stripped off their separators ("/") on save.

Hmm, I can't identify the source of this "Oblivion_Character_Overhaul_UP.esp" that loads after your bashed patch, as it isn't from the "Oblivion Character Overhaul - Unofficial Patch" in your installers, at least not the one I could find on the site, which contains an ESP meant to "replace" OCOv2's, not patch it. But this is also rather unlikely to be the culprit here. We're talking of something undoing the head mesh NIF file replacements OCOv2 does, and there's nothing like that coming in your installers after it. OCOv2 replaced the Vanilla Argonian, Khajiit and Orc head NIFs, so how can they be Vanilla again now? It is only those 2-3 races and not others, especially not all as well? (No replacements working at all I could explain, but only a few not working, and in this set of installers and order, is hard to find a reason for.) There is a bunch of plugins loading after your bashed patch, so they can mess up your perfectly mixed and made compatible setup afterwards, but even if the race settings were messed up, this would still not undo the physical replacement of the head NIF files. And there's nothing loading which looks like it'd "redirect" the races' heads to meshes of its own, or even have meshes of its own. Did you try disabling all other race changing plugins but OCOv2 already and see what it does? If I recall the install instructions correctly still, you were to not use the body mods's plugins ("MaleBodyReplacerV5.esp" and "RTFemaleReplacerV12.esp") anymore either when using OCOv2, and they're still at least merged into your bashed patch it seems. But again this can only mess up race settings, and race settings shouldn't really be the reason for mesh replacements to not work. "OCO DLC Faces.esp" and "Reworked Race Relations.esp" shouldn't be affecting the head meshes either. My "ScriptedArgonianFeet.esp" certainly doesn't, though why is it loading that late? It's only scripts after all. Oh, well. But for the sake of completeness you can try running your game with my plugin disabled, too, if just to confirm it's really not it causing this. It shouldn't, and doesn't in my installation of OCOv2, but you never know in this game. My Argonian Beautification doesn't contain heads or faces, and you have OCOv2 installed all over it later anyways, going by the install order I see. Why you have certain patches to OCOv2 installed before OCOv2 is beyond me, but they're only additional plugins (apart from the unofficial one, if it's the one I found) so it won't make a change. And none of it is in any way related to the issues at hand. You have OCOv2 pretty late in your installers. Can you check if its files are really all installed and there are no conflicts/overwrites other than by the "texture compatibility add-ons" installed thereafter? Otherwise there should be a means to just re-install it as well I'm sure. To make absolutely sure none of OCOv2's files have been overwritten/replaced by something else later and all are installed correctly. You will have to only reinstall the texture compatibility add-ons later. edit: Partly ninja'd again by Striker, while I was still typing my reply and looking into all those mods' archives. :sweat:

Sorry for the interruption, but be careful with "removing" glow maps. It will mostly have the opposite effect. The glow doesn't come from the maps but from the emissive property of the material set in the NIF. The map now just prevents it from "glowing everywhere" by putting an intensity filter over it. Removing the filter will of course make everything glow the brightest it can. The problem I'm seeing here is that the good old Race Balancing Project (the requirement for Integration and where all race cosmetics come from, I was using it myself for years) is like a mixture of multiple different, and conflicting, assets, which only work together correctly, because the ESM/ESP makes it so they don't mix up, every race has only those meshes and textures which work together. Otherwise even having a mixture of Vanilla, Capucine's and/or Ren's eyes on one and the same race at once would be a nightmare scenario, as there can only be 1 set of eye meshes per race but a multitude of possible eye textures, which need not necessarily all work with the 1 set of meshes at all. Whereas Nuska's OCOv2 set out to keep things streamlined and standardized, so it uses only 1 single set of eye meshes for all and no conflicting eye textures either. Mixing OCOv2 and/or RBP with others/each other now does inevitably cause conflicts, even if they didn't overwrite anything from the other per se. Introducing only 1 additional eye texture into a race record the eye mesh of which is incompatible will cause issues aplenty already. And as for the problem at hand, I haven't yet investigated too deeply, but while OCOv2's eye meshes "all" have a string emissive property, so they all glow and need glow maps for all eye textures to not light up like a paper lantern, RBP has "some" eye meshes which don't glow at all, so quite likely also won't provide glow maps for all its races' eye textures. This is what's causing the issues presented. The race uses an eye texture not meant to be used with its eye mesh, created by mixing up resources and records from 2 different and conflicting cosmetic mods. And just to think of it, you can consider yourself lucky you haven't yet run into any of the much more severe "googly eyes" encounters, as several of the eye meshes in RBP even have a completely different texture "layout". Now, I'm pretty convinced they can be made working together, either through a bashed patch with properly configured bash tags on their plugins or master files or through a simple self-made compatibility patch, but I sadly don't have the time to look into this in detail or I would do it right away.

While that is definitely true, I'm still not seeing these fixing any of the issues from above. I'm also not seeing anything immediately in the load order given, which could possibly cause something like the explained. Decorator Assistant maybe, but only if you jumped onto the altar yourself and its scripts weren't secure enough to detect and prevent such a case. After all, it's not meant to put "the player" into place somewhere in your houses, or any NPCs for that matter, so I would expect it to be designed in a way that's preventing this. The only one I really couldn't find anything about, not even its origins, is this "Emporium.esp". But why would it mess around with collision toggling in such a chaotic way that not even "tcl" will help you get out of being stuck inside geometry? ...How is that even technically possible for that matter? (Unless there's some script automatically toggling it back on each time.) It still doesn't make any sense to me, so I'm definitely still missing something important here.

Okay, now we "really" need to see your mod list and/or load order. Repeatedly glitching "into" any kind of geometry is totally unheard of as far as I recall.

Hmm, I'm afraid from what I know so far, if you imported the head mesh directly from a NIF into Blender and then exported it again directly into a NIF after you were done with your changes, then it's very likely the vertex order already got changed, and as such the connection between the NIF and the EGM or TRI files is broken beyond repair. I know of no way of intentional and aimed changing of vertex order in order to get it back in sync with the EGM and TRI's, as much as I don't know in which way exactly im- and export into or out of Blender actually changes it. I only know from having read writings on the topic and my own observations it definitely does. If there is a way to re-do your changes to the neck after importing an original unaltered head mesh from scratch but first converting it into an OBJ (import into Blender from OBJ gives the critical option to "keep vertex order intact"), exporting it back into OBJ as well and only from there into a NIF, then you should be able to fix it. But if re-doing your changes is too much work, I'm afraid things don't look good. But like I said, I'm not an expert in this. It could very well be there's new knowledge, tools or means to work on this available by now and it can be done much easier. I just don't know of them, yet.

Well, this isn't exactly a very active section anymore, sad to say. The people still actually responding to help requests in here I can count with at most 2 hands I'm afraid, and those aren't always around every hour of every day. One or more of them definitely will respond at their earliest convenience, as also has happened by now. Then, you will of course get lots of views without a response, no matter what you wrote in your title already. The absolute key to being able to help you with your problems is knowledge about your background and the context in which the issue occurs. As you already found out yourself, due to the lack of search results in Google to your issues, it's not exactly a common thing, so the first thing to find out is what makes "your" case different to everybody else's. For example, when I saw your topic title about Benirus disappearing, I may have known what your issue is, but I was still clueless about "why" you're encountering this while I haven't yet even heard of anybody else ever having experienced the same before. So I went into your topic to read your opening post, in hope to find some more information for your described issue to start making sense... alas, I didn't. You're not exactly giving away much in any of your posts. Now don't get me wrong. There's those of us, myself included, who usually go out of their way asking through, digging their way down, step by step, until the reason becomes apparent. But keep in mind there's not exactly many of us, and we don't always have the time to do that right away. It's not surprising people come into your topics, thinking that, perhaps, they would find something they realize as the cause from reading your opening post, but then step away again once they found out they learned nothing new and still have no clue... and they're not the type going to ask their way through. Back to the case at hand, you haven't even given the most important part of information everyone going to help is going to ask for first, your list of mods and/or your load order. Without this we won't have even a slight of a chance to find what's the culprit in your game and only your's. However, in case of your missing Benirus you seeing a green quest marker when outside and a red one when inside the inn means that Benirus himself at least also is already outside. My first bet would be him somehow having become stuck inside the geometry on zoning out the door, either due to a conflict/oddity with some mod altering the interior of Anvil more or less significantly, or simply due to a high load of game and a serious drop of performance at the point of his zoning out. While these things "can" happen in a regular Vanilla game simple due to lag, script lag or it simply acting up occasionally sometimes, it's still far away from likely or a regular thing. So mods being the fault is the more likely explanation. And then, the first response you got, giving you means to find him, respawn or move him to you, was also already going that way. Well, I hope this explains things some and helps you finding help better in future.

I'm not sure using this function with type 70 (inventory items) is really what is thought it is. I for one would rather use the slightly newer inventory reference walking for the second loop to do the trick: http://obse.silverlock.org/obse_command_doc.html#Inventory_Reference Trying to adapt your script to an example would make it: ref someActorRef ref iter set someActorRef to getFirstRef 69 1 Label 100 if someActorRef foreach iter <- someActorRef iter.RemoveMeIR someContainer loop set someActorRef to getNextRef goto 100 endif But as you seem to want to remove "all" items from the actor to the container, the good old Vanilla function RemoveAllItems would be a much more performant way to the goal... unless we're talking "unplayable" items here. ref someActorRef set someActorRef to getFirstRef 69 1 Label 100 if someActorRef someActorRef.RemoveAllItems someContainer set someActorRef to getNextRef goto 100 endif I'm also not a friend of the Label and GoTo approach, but it has its merits and I can't think up a better way in the short time I got for writing this. Hope it helps. P.S.: Keep those links at hand. The function references are invaluable when it comes to finding the best solution for a specific job.

Good catch with the SI ESP, Striker! The empty dummy plugin does of course not contain any records/ids. Hmm, how do you normally start your game, and manage your mods for that matter, in case you only used Wrye Bash to read up the plugin index? Because it really sounds like you're running your game with a different list of mods than what you set up in Wrye Bash. One of the virtual managers immediately comes to mind, like reading indices up in WB but running your game through MO/MO2. But then, where do those other mods in this list come from, if all mods were installed through MO/MO2? That makes no sense. Unless you installed some mods twice, once manually by other means and then again through MO/MO2, for whatever the reason may be. I take it you're NOT running an auto-sorter like BOSS or LOOT right after looking into WB. That could again change the load order of course and you would've read up the wrong. Or is it an issue with CBash, maybe in combination with overzealous OS like the latest Windows and/or permission issues? You could also try using double quotes like so: player.additem "0B00BF78" 1But it should also work without them, or so I've heard. What's your game version anyways? Many plugins will be "silently ignored", if you're not on the latest 1.2.0416. For the game it's as if they weren't there, so of course the load order inside the game will again be different to Wrye Bash's. Otherwise I'm running out of ideas here, too, as you seem to be the only one having this problem right now, or who I know of that is.

Oh, well. I'm not sure it can be done "just" with Blockhead. Can the latest version of Blockhead also switch out the actor "skeleton" per race? You will need to have your actor use the creature's skeleton as well as animations. And as far as I know Blockhead can only replace animations by now. OBSE does have a function to switch out a player's or NPC's skeleton, but it will require some scripting to make it work, as it needs to be re-applied every time the game was launched again. I think to remember the playable creature mods were already using "that" solution though, or they used a plugin-based switch without a script. But that switch is only actor-based and not affecting whole races at once. And yes, the last problem will be the appearance. Yes, Blockhead will want separated body parts, while creatures usually have at most the head alone. Nobody's saying you can't just split a creature mesh into the 4 (5 counting tail, the head's usually already separate like I said) body parts respectively though, and then it can work. Just nobody's done that so far. The most commonly used approach to playable creatures is still the same old I sued for my creature dragon shape shift approach. Make a "mountable" version of the creature, spawn it, turn the player invisible and make him mount. Of course you're then maneuvering it around like riding (you "are" riding it after all), but it's the easiest way. Once you unmount, turn the player visible again and de-spawn the "mount". But yes, with a bunch of work, script-controlled switching out of the skeleton (which also switches out the animations) and Blockhead-induced custom body parts, you should very well be able to create a playable creature race. Can't say I've ever gone about it that way though.

Well, it's not what I'd call a conflict, but rather a lack of support. As a little background: Skin textures are different on a per-race and gender basis, but body meshes are one and the same for all races, only different by gender. The problem comes from your custom races having only Vanilla textures. They don't have the proper texture layout to wrap correctly around Robert's meshes. Thanks to the above you also cannot have only your custom races use different body meshes. (It may be technically possible by now, but comes with a lot of work and drawbacks to get done right, and even then it's still not perfect.) Your best bet would be to get a hold of fitting skin textures for Robert's Male bodies for your 3 custom races and exchange their "footmale.dds" and "footmale_n.dds" (Robert's Male uses only the foot texture wrapped around the whole body for seamless coverage, unlike Vanilla where it's 1 separate texture for each body part) respectively. All your races' skin textures must be fitting Robert's Male bodies, or it will always look like that. edit: Robert's Male V4 doesn't contain replacement skin textures for Golden Saints, Dark Seducers or Dremora. But Robert's Male V52 does.

Is it this one? https://www.nexusmods.com/oblivion/mods/24088 Doesn't look like a functioning mod, but the resources are there.

Most mods with OMOD files will also provide a download version without it. Those who don't can simply be "opened" once with OBMM and converted into an OMOD-ready ZIP/.7z. There's no need to be using 2 mod managers at the same time, as, yes, that's really unadvised. edit: Ninja'd by Striker, but with a much more detailed reply.

Then let's move it there, leaving a link in the Newbies forum, so it can still be found from both places. :thumbsup: You're in very good hands with Striker there. He can definitely walk you through. Though from what you wrote about your past experiences I suspect a bunch of misunderstandings in the correct use of some tools. But I'm sure this, too, will be solved in time.

Ah, yes, totally forgot that. Shows my current install of WB is still a bunch of major versions behind the latest release. Never change a running... never run a changing... ah, you get it I think. :sweat: I'm still running the sorters all externally, not through any of the managers' tool buttons instead. But yes, "lock load order" needs to be turned off for a sorting run to work. I usually turn it back on immediately afterwards, or after I manually tweaked the order myself that is.

Hmm, were you to use OBSE, there'd be the MessageEX function and the "%n" placeholder instead, or the GetName function directly even. I'm still searching for a way to do it without OBSE though. It's such a simple thing, and it's done internally in topics, too. Though I'm sure that's an entirely different framework there.

What choice of mod manager, or manual, you use is totally up to you. OBMM is fine for automated guided installs, its wizard-like scripted installs (.omod) being key to many more complicated sessions otherwise. Wrye Bash's BAIN is more like "automated manual install". The mod packages are split into many optional, and overwriting, pieces, and each one of these is just a manual install pack, put 1:1 into the Data folder. They're named/numbered in a way so you can pick&choose, and BAIN will install the combined outcome of your choices. In Vortex, and previously NMM, you had FOMOD (originally from the Fallout modding scene) install directives, which again resulted in a step-by-step make-your-choices install wizard, or even with C# scripts. I heard rumors Vortex may even understand the .omod format and/or a BAIN folder structure. I'm not yet using it myself though, so I can't say if it's true. You will run into mod packaged in a way "no" manager on earth will be able to correctly install, or others only certain managers will be able to understand, while others won't. That's just the result of these mods having been released long before mod managers were even an idea, and things like a standardized folder structure were not yet heard of. "Most" mods can likely be installed fine by whatever manager you choose, especially simply structured ones, where it's only an excerpt from a Data folder with no options or choices inside. OMOD files can be opened with OBMM and exported into so-called OMOD-ready ZIP files, which can then be installed manually or by another manager of choice, provided it understands the underlying folder structure, which thanks to scripted installs can be whatever the author had in mind and make totally no sense. OMOD-ready packages (containing an "omod conversion data" folder with an optional install script inside, which you can easily turn into an OMOD in OBMM), however, in the past have killed NMM, as it was mistaking the OMOD script it found for a FOMOD script and failed to understand the first function call it tried. You absolutely had to remove the folder from the packages first for them to be usable in NMM. Not sure about Vortex though. You can always take apart a BAIN-ready install, as those aren't special file types but simply folder structures consisting of a bunch of "install me manually" individual parts. These are also easy to convert into whatever other manager's folder structure you need or to install manually. I myself have started out with manual install (as back when I started there was no other option, yet), later got into OBMM and its fancy OMOD installs, then came NMM where I had to convert many mods into fitting folder structure and to convert OMOD scripts into FOMOD directives, and now I'm with BAIN for a while, as the work involved to make these old mods installable in the newer managers is more hassle than to take the few complicated installs apart into manual install and/or BAIN structure. But I "can" work them all around into any manager ever I want to try next at any time. Nowadays OBMM is handy for its tools, like BSA browsing and/or Archive Invalidation. Wrye Bash, the Swiss Army Knife tool of modding, is of course still invaluable just for that, its abundance of tools for managing conflicts (the invaluable bashed patch!), unbloating save games, fine tuning game settings without the need for an extra mod, and that's just the start of what all it can do, whether you also use its BAIN for managing your mods or not. And yes, it also has an option to apply Archive Invalidation to your game. Vortex/NMM also have some tools available which might come in handy even without using them for install. At least Archive Invalidation is something they all can apply. And managing your load order is something they all can do. Vortex even has integrated LOOT, if that's your choice of auto-sorting tool. For all others you can either use LOOT or its predecessor BOSS run stand-alone. Wrye Bash, I think, though can also run BOSS from inside. The only tool completely worthless for managing load order is the "Data Files" menu from the official Oblivion Launcher tool. This one doesn't even show plugins in loading order but in alphabetical instead. Completely useless for the most vital task. And as to Archive Invalidation/BSA Redirection, yes and no. No, it's nothing to do with what FNIS or similar do in Skyrim. In Oblivion you don't need any tools to get custom animations working off the bat, just a mod with a plugin for putting them into the game. However, yes, it's definitely as vital and inevitable as such a tool, because in Oblivion, especially when from Steam or another digital distribution platform, for external loose files to be used over the Vanilla ones inside the game's BSAs, proper Archive Invalidation is an absolute must. In other words, "no" replacer mod ever will work without it properly in place, textures, meshes, animations, whatever. And yes, BSA Redirection is the only sane and still advisable approach towards Archive Invalidation nowadays. All others come with unnecessary risks or drawbacks. And all mod managers I know can apply it one way or another. What it does is simple. It puts an empty dummy BSA into your Data folder and edits your Oblivion.ini so this one's loaded at a special place in the "sArchiveList" entry. It's not quite clear as to why, but this in effect makes it so from then on the only remaining BSA file needing Archive Invalidation for external files to be used over its internal contents is just this empty dummy BSA, which respectively invalidates the very need for Archive Invalidation itself once and for all (or until either the dummy BSA or the changes to the Oblivion.ini become undone). Special care has to be taken with installations from Steam or other digital distribution platforms. They have the habit of putting "last modified" dates on their BSAs which are way more recently than any replacer mod in existence will ever be. And in Oblivion file date trumps everything. No replacer mod with a file older than the BSA will ever have a chance to work, Archive Invalidation in place or not. This is when another feature I've only seen in OBMM so far comes into play: In its Archive Invalidation dialog there's a button "Reset BSA timestamps", which you simply press once before applying BSA Redirection to fix their dates. Without it you'll have to use a 3rd party file re-date tool, which was likely massively discussed on Steam Oblivion modding forums or similar. Uhh... that's again become quite a lot longer than I had in mind. I hope I didn't forget anything else important now. :ermm:

The NIF file sure can't hurt, either as a file for download or a picture of the NIF tree at least, but helmets are anyways rather different. Yes, some are standing alone with only the head node in the NIF and rotated to strange angles, so it rotates back in-game to the right orientation, but not unlikely these also have "un-applied" offsets and/or rotations in the NIF. Maybe check other existing helmet NIFs which were made that way to see any offsets (=location) and rotations (=angles) of the NiTriStrips/Shape node. Then I've also seen helmets made so there's a complete skeleton armature inside the NIF and the helmet is sitting upright at the correct location on the head. There then are no un-applied offsets on the node, if I remember right, or only if the helmets are also morphed. In any case it's always the best idea to look at existing working helmet NIFs to see how it's correctly done. Especially said un-applied offsets and rotations are easily overlooked from only a short glance at the tree. Oh, and, for some explanation: - "Applied" transforms are when you edit the transforms first, then hit "apply", they will zero out again in the node but directly modify the vertices themselves, so then the location of the helmet will be 0,0,0 again, but the vertical position of every vertex inside will have the offset of the helmet from the origin/ground added onto. These then can no longer be morph-controlled, as the morphs are usually made with only the helmet in mind and based on the head node at the center/origin! - "Unapplied" transforms now are when you edit the transforms as the last time, but then "don't" hit "apply". They will be directly affecting the helmet node itself, while the vertices inside it remain unaltered. These can still be morph-controlled, as they are zero-base oriented around the head node as their origin still, as most head morphs require it to be the case. But that's very technical now and not really needed to know.

Do you have some more information about what you did/are doing? What race is this? What textures/DDS files are used? On a first whim this looks like a missing normal map ("..._n.dds"), but face textures are kinda different in some points, not sure they always need one as everything else does.

Hmm, that's not quite how this works. Vanilla resources (almost) can't be "overwritten" by normal mod install means. They will always be stored away inside their BSAs safe and sound, external loose file replacements only used "in their place" while present. A Vanilla Data folder is almost empty. I think it doesn't even have a "meshes" or "textures" folder at all. So first we'd have to find out "what" exactly the mod replaced, as it shouldn't have been the Vanilla files, and then "why" the game won't fall back to the Vanilla files, after you uninstalled the mod. What means of "Archive Invalidation" were you using by the way? Without Archive Invalidation a Steam game will never use an external loose file replacement over the one inside its BSA, so you must be using one or another. And there's still advice around to archaic and/or issue-inducing older means, which unlike normal mod install can very well damage the Vanilla files beyond repair, apart from through Steam's "Verify Integrity of Game Files" of course.

These directly align with the "Double sided" attribute and the specularity of the material used. You can remove them directly in Blender, and they won't appear in the export anymore. (I just don't know it completely exactly what material setting and/or what value thereof creates the NiSpecularProperty right now.)

The way OBSE plugins (DLLs) work is made so either, the game and the CS, will try to load them all, but not all of them are meant to be used in both. There's no way of telling them, so the system relies on either of them identifying the wrong plugin as "incompatible during query" for it not to load them. In your case the two plugins "AVUncapper_CS" and "Construction Set Extender" are both meant to only be loaded when you start the CS, not when you start the game. So the game will report them as incompatible and not load them, while the CS will load them fine and perhaps do so for others instead. In other words, those errors in the OBSE log usually only mean it's working as intended and shouldn't possibly be the cause for crashes.