DrakeTheDragon

AndrewRoss26 banned. Reason: Spam account. Reference post

Memenjo banned. Reason: Spam account. Reference post

That's quite an old topic you're responding to. Even the URL scheme has changed since then. But for what it's worth, here's the corrected link to the mod mentioned above, just fixed the pathing: https://www.nexusmods.com/oblivion/mods/15677

One of the simplest kind, actually: You missed a "." between "tarCheck" and "IsActor" in this condition line: elseif tarCheck IsActor == 1 && HasMagicEffect SNPFL == 0

Ah, my bad. Don't know how "SK" slipped into there. I meant "KF" files for the bone-based animations, of course. Sorry for the confusion. ".kf" files is animation through posing armature bones, ".egm"/".tri" is animation through morphs. And sorry, Pekka, but I must correct that slightly. ".egm" files is what makes one helmet fit differently shaped heads in CharGen. ".tri" files would be, if the helmet had movable eye or mouth parts and needs to move them along with your expressions or speaking, or like a woolen or silken face mask for example where you see it when you speak, if you get my drift. Skanti's famous Conformulator, if you recall that name, created EGM and TRI files, not KFs. ".kf" files are mostly only used on actor skeletons or static animated meshes. (Though with the latter I've seen the animation from inside the KF merged into the NIF straight away instead. There are animated NIFs without any accompanying KF files as well. But animating static meshes is something I only dabbled very loosely in myself so far. Elevator like movements of parts of objects or a sarcophagus opening and closing its lid is all I ever did in that regard. And I somehow doubt those bone-based things will have much or any trouble with Pyffi optimizing their NiTriShapes/Strips.)

Just Drake is absolutely fine here. I'm among friends or family in the Oblivion section. That article could be related. It's just a fixed term in Oblivion modding. Animations can be either bone-based (SK files) or morph-based (EGM/TRI files), while the latter is usually used for faces, expressions and such. The EGM file for example contains all potential shape morphs you can apply onto a head mesh, while every slider in CharGen controls the amount for 1 of them. Similar goes for the TRI file, which contains a morph for every facial expression at its fullest and the facial animations control which is applied how much in a merged result. I don't think there's any automated tool for checking if a NIF has morph files present. Others correct me, if I'm missing one. But it should as well be trivial to make one, considering it's just checking for the presence of "path + (filename - extension) + other extension" in this game ("head.nif" has "head.egm" and "head.tri" in exactly the same folder).

Just for reference, I think the problem with pyffi'ing some NIFs causing crashes is due to there being morphs (EGM/TRI files) along with them. Morphs contain offsets over time on a per-vertex basis using vertex-indices for connection. You already cannot use several of the deformation or optimization tools inside Blender on these meshes for that reason, as everything that even remotely alters either vertex count or order completely breaks the connection to the morphs, which is also known to cause CTD. For instance the vertex order is already changed the moment you import or export the NIF, why these meshes can only ever be imported as OBJ with the option "preserve vertex order" checked. I think it's not just an estimation that any such optimization steps Pyffi applies will also completely f-up the vertex order, thus break the morphs, thus create CTDs. Never touch NIF files with morphs, unless you completely know what you're doing or are prepared to re-do the morphs from the ground up.

One thing though, you won't see it in NifSkope at all. NifSkope does not use the correct textures based on race. As there is no Khajiit body meshes (apart from the tail) but only all-races body meshes, in NifSkope you'll always only see Imperial skin. You need to go into the CS to see it. And then you're sadly not looking at the current in-game setup of racial texture paths either, I'm afraid. The only way to really check this out, is by going into the game. Well, this or reproduce your "entire" load order in the CS, which will make it break no doubt. And yes, you can of course also use Blockhead to fix this issue. The steps will be exactly the same as I already instructed, just with a different target filename and path. I for one though don't think there's much sense in having a Vanilla foot texture lying around in your folders still, when you're no longer using Vanilla bodies anyways but Robert's M & F. As always it's a thing of personal preference though. Whatever it is, there's always multiple ways to do it in this game.

Nothing wrong there at all. And I think I don't really yell anyways. Though it won't fix any purple meshes, as that's physically missing resource files, not invalidation or load priority. But you're responding to a topic from 2012, back when SkyBSA wasn't even thought of. :no: Mysticshadow needs to explain their problem in more detail, as it's most definitely not the same situation on their drive now as ryanra's was back then, almost a decade ago.

Hmm, I don't know of a "mod" fixing this particular problem (OCOv2 not providing the proper textures or settings for Robert's Female Khajiit). But no, you don't need to "re"-do anything. You already installed the body mods, Robert's Male and Robert's Female, first, as instructed, then the OCOv2 main file, then the OCOv2 texture compatibility add-ons for Robert's Male and Robert's Female, so all files should be the way I posted above. The only thing left now is fixing the incompatibility between OCOv2 and Robert's Female Khajiit not fixed by the compatibility add-on. Simply copy&paste&rename "textures/characters/Khajiit/male/footmale.dds" + normal map (the female body textures from Robert's Female) over "textures/characters/Khajiit/female/footfemale.dds" + normal map (the Vanilla female foot texture the OCOv2 main file installed and its plugin makes the game use). Then hope for the best. (If there's no other plugin loading later, which again changes paths around, it should've fixed the issue.) You can even make it a mod, which replaces the "footfemale.dds" and its normal map with the "footmale.dds" ones from Robert's Female, for those inclined to have a manager control everything and never do anything manually.

Yes, that certainly looks like the wrong Khajiit skin texture used on the females. There is a Vanilla Oblivion issue, originating from male and female Khajiit originally using one and the same texture for feet, "textures/characters/Khajiit/male/footmale.dds", and now body replacers using the foot slot for their full-body textures, thus female Khajiit have male body textures. However, this is usually a problem with only Exnem/HGEC, as those are the only body replacers "not" coming with a plugin required for fixing this. There are no plugins in the texture compatibility packages of OCOv2, but there's also no Khajiit textures in there to begin with either. I don't recall how OCOv2's plugin was set up with regards to separating male and female Khajiit textures. I know both Robert's Male and Female plugins do fix it though. But I think you were told not to have them active when using OCO? Regardless, we're left with following files and paths from Robert's Male and Female setup: "textures/characters/Khajiit/male/RTfootmale.dds" for the males (So it does not conflict with the file Exnem/HGEC uses for females without a plugin.) "textures/characters/Khajiit/male/footmale.dds" for the females (Robert's Female apparently keeps it at the Vanilla setting.) "textures/characters/Khajiit/female/footfemale.dds" containing a female Vanilla foot texture replacement coming from the base OCOv2. The question now is, if OCOv2 comes with a separated female foot texture replacement, won't its plugin also contain a re-pathing to exactly this file for females? This of course will mess with Robert's Female's way of still using the male texture for female Khajiit. And I think that's what you're seeing here. OCOv2's plugin makes the game use "textures/characters/Khajiit/female/footfemale.dds" for the females, while the correct skin texture from Robert's Female is "textures/characters/Khajiit/male/footmale.dds" still. A quick and easy fix would be replacing the female one with the male by copy & renaming it to there. But it also begs the question why OCO's compatibility measures don't already do this. And of course it's always a question of what "other" race-changing plugins you might also use and how efficiently your bashed patch is configured to keep the correct path in use at the end of your load order.

Additionally, this is "not" a mod. It is just a package of resource files, mostly skin and face textures, both in DDS and other formats for you to edit and work with. A modders' resource. Installing this on its own will do nothing at all. You need to create your own plugin, create your own custom race, or edit an existing one, and assign those textures to the right slots.

Yeah, as there is no slot for back items per se, some authors use the tail slot, others the amulet slot, especially since equipping a tail slot item on a tailed race will remove their tail. And yes, there are certain types of NIFs, or contents of NIFs, which cannot be set to every slot. Certain setups will only work when mounted to 1 slot but not with others. While meshes oriented and rigged to a normal skeleton setup can usually be mounted on every slot, meshes assigned to certain bone nodes through other means, like PRN (I myself only know the name, not what it really is), which is often used for helmets or amulets especially, can only be mounted to a select group of slots. A look into the NIF would probably tell, why it works only on the amulet slot. But I don't think that's really that important anymore now either.

Did people also say what exactly needs patching from your mods or the overhauls? Are your items' stats wrong or unfitting when used together with these mods? Or is it more simply your items no longer being inside leveled lists when also using said overhauls? The latter will be due to in this game only 1 plugin at a time ever having its effect on a singular leveled list, and for multiple plugins editing the same leveled lists at once, your users needing to use Wrye Bash to merge the leveled list changes from all their mods into their bashed patch themselves. As for patches towards compatibility between 2 or more mods, requiring the mods they patch to be installed and used in order to work, these are generally considered a-okay, but only unless an author of one of the mods patched contacts staff and complains about it: The technical aspect of making patches is actually quite simple. You simply open the CS, go into Data Files, "don't" select an active plugin but do select the plugins/masterfiles your plugin is meant to patch. This will make it so it creates a "new" plugin, which will have access to all records from the other plugins/masters without changing them directly, and all changes you do to them will only be saved inside the new plugin, the patch as we know it. The other plugins or masterfiles won't be touched in the process. However, please keep in mind the Vanilla CS "cannot" save plugins with other plugins as their parents/masters. Only masterfiles (ESM) can be used as parents of plugins in the Vanilla CS. This is most easily fixed by using the Construction Set Extender (CSE), an OBSE plugin, instead, though it will require OBSE of course. And of course the work that's needed to be done for the patch to do its thing will vary, too. Like making it so NPCs coming from OOO will have your new items in their leveled lists as well, if they're "not" already using a Vanilla leveled list, and other means.

There's a few problems with this. If you edit the backpack NIF and only move the "Bip01 Spine2" node around, it most likely won't change much about the result in game. The node inside the NIF is used more for reference than placement. The relative distance to this node is used to relatively distance the backpack to the skeleton's node in game more like it. And if you edit the skeleton.nif so the "Bip01 Spine2" node is moved more forwards, this will affect much more than just the backpack. Additionally any locational or rotational changes to nodes inside the skeleton.nif are undone by every Vanilla game animation playing at the time, as for whatever reason the Vanilla game's animations always contain both, location and rotation, for every bone node at every time, effectively undoing everything done to the skeleton nodes. The only way you can get the backpack closer to the back in a way that actually works is by editing the actual mesh and moving the vertices closer. This can be done in NifSkope, by selecting the NiTriShapes/Strips and through first editing the location and then applying the changes. Or it can be done in a modeling app like Blender or 3DS.

A scripted MoveTo or MoveToMarker would be how teleporting NPCs is usually done. But take a look at the scripts for the quest you're talking of and see how "they" actually did it as well.

Hmm, not anything I know much about, but as a luck shot, did you do anything to the exported mesh in NifSkope after export? If I recall correctly, there are heads/helmets/similar which are not oriented around the origin (0/0) but at the neck connection point, but those need/have an un-applied offset on their NiTriShape/Strips node, so ingame the head/helmet's position will still be around the origin locally, thus morphs will still work correctly, but it's offset to the correct place above your neck. Depending on if or if not you did something similar to your resulting export, this might explain a few things. However, I don't even know exactly what you mean by "floating around the head", as we aren't seeing any pictures or similar.

As a rule of thumb, even if you used the exact right combination and version of modeling app and NIFTools im-/export scripts with exactly the right settings, you should still run the resulting NIF through NifSkope for some necessary post-export sanitization magic. It is very easy to mess the structure of a NIF file up beyond what the game can understand. Luckily it's most often fixable just as easily, if you know what you need to do. So you imported an existing lowerbody NIF (was it clothing/armor or a bodypart from a body mod by the way?) into your modeling app (which one?), then changed something about it and exported it again into a NIF (how? which tools?)? Some more details about the steps you took, and if all else fails a link to an upload of the NIF file causing the CTD, will definitely help.

What's the filename before and after the rename? Which filename crashes and which works?

The only "stupid" thing is never to ask. :thumbsup:

Did you already try entering the "name" of the mod and waiting for the suggested matches to pop up and click on? I recall some types of mod interdependency selections worked on entering the name, not the url or id, so it's worth a try in case translated mod selection works the same.

Additionally every OMOD can be turned into an archive via OBMM, which can then be extracted, used for manual install or restructured into something one of the other managers "can" install. Ever since I switched back to Wrye Bash (BAIN) for my last and current mod install, I personally extracted countless OMODs myself, read their install scripts, picked my options and reproduced what the scripts were doing to create a manual install package fit for Wrye Bash / BAIN in the end. That's why I always say all Oblivion mods "can be made" installable with every manager there is. It just takes some manual restructuring sometimes.

It can also be done through the CS. If you select one file as the active plugin on loading, you can also use the button on the bottom to see more details about the file, and to the topic, set "ignore" flags. Loading a plugin with certain records ignored will load it without these changes, so saving again will save without these changes, too. As long as you can keep track of what the records displayed are and which are the ones you intentionally edited, it was always my first approach to getting rid of "accidental" changes.

BSA Redirection is just the one approach to Archive Invalidation which removes the very need for archive invalidation itself once and for all. Archive Invalidation, no matter which approach, is what tells the game which external (loose) files to use over internal (BSA) ones. Yes, the Vanilla game can't have conflicting files in two or more BSAs. The order in which they load is not defined. You'll never know which BSA's file will take precedence over the other or at which time, as it's also reported to change from start of game to start of game. That's why BSAs are never used in "replacement" type mods. The UOP can't have replacement files in BSAs. What it can have though, been a while, can't check, is new files in different places made used in place of the originals through changing the paths inside an ESP. There's several replacer type mods doing it this way, without even touching the original files at all. And yes, SkyBSA makes "all" of this needless in one go, Archive Invalidation, BSA load order/conflicts, loose files always having priority over all else, everything is told to be exactly like in Skyrim when it's used. Yes, you can have an unlimited number of BSAs "autoload" with just 1 single ESP. As long as the filename "starts" with the ESP's, it doesn't matter what else you append (or so I've learned). Turning BSAs into 7-Zip, now there's an interesting idea. People have extracted their BSAs to loose files for decades with always mixed results. Some reported improved performance, some decreased, some no changes at all. Turning every BSA (or multiple BSAs together) into a mod (.7z) managed by BAIN... can't say I've ever heard that idea so far. Sounds interesting. Unlike with BSAs, those definitely will have a set order in which they load and priority which conflicting/replacing ones will be used at the end. But there won't be a "need" for extracting even the game's own Vanilla BSAs, if you're going that way. Properly set up Archive Invalidation, or using SkyBSA, will be all that's needed for this idea to work. Oh, but, one thing I almost forgot... You know how Wrye Bash's BAIN is operating, don't you? It "extracts" all its mods (.7z) directly into your Data folder, where everything will lie as loose files, just as in good old times. So it's not "exactly" the same as having BSAs. The compression aspect is gone once you "install".

If, for whatever reason, some tool deactivates the DLC Shivering Isles ESP, (despite it being an "empty" one) this will lead to the BSA auto-loader no longer loading the DLC Shivering Isles BSAs, thus a whole boat load of missing meshes and/or textures in game. Which "mod sorters" were doing that nonsense, mind I ask?