DrakeTheDragon

OBSE can only be an enabler, not a cause, as on its own it doesn't do a thing. OBSE-dependent mods on the other hand though "might" be at fault. They will cease functioning when the game is run without OBSE, so it "looks" as if OBSE was at fault.

HUD Status Bars can use Quest variables as source for value display. You would need to add a local counter set to 0 at the start of the loop, incrementing for each non-dead creature found, and update the quest variable's value to this one's after the loop. So, if the above is in a quest script already, just introduce 2 new number variables: int iNumCreatures int iCount Begin GameMode set iCount to 0 set rItem to Apple set rItem to GetFirstRef 36 1 while (rItem) if rItem.GetDead == 0 ;Actor is alive, do your stuff set iCount to iCount + 1 endif set rItem to Apple set rItem to GetNextRef loop set iNumCreatures to iCount End Then you can tell HUD Status Bars to use "<your quest name>.iNumCreatures" as the display value for the element. (I'm doing it with 2 variables instead of 1, so you won't see the number repeatedly starting by 0 and going up, which you would do, if you used "iCount" directly for display instead.)

I won't be of much help here either, but I recall some of the issues described in the OP. The being unable to look around in 1st person view could definitely be some drawback from UVIII's own 1st person view implementation. If so, I think to recall it can be turned off in the INI file(s) for a quick check. I don't know what else mods are in use, but if it's, for example, Oblivion Reloaded, this one's own camera control could also be at fault. It can be fine-tuned to the utmost detail in its INI settings, so it's quite easy to have it wrong especially in combination with another mod / UVIII. The item you're having in activation focus in 1st or 3rd person view isn't exactly the same pixel you look at with the camera. There's a bunch of settings / game values that can be fine tweaked (or already have been by some of the mods you use), which can easily mess this up. I've run afoul of that myself already somewhen in the past. Most of the combat mods, like UVIII, usually increase the distance by a lot for their special moves or attacks. This can keep the wrong object in focus even when it's actually far enough away. But I'm for some reason still unsure the activate button is the only way to trigger a stand up from a chair. I know it can also easily be scripted in an own mod to have you stand up, and only stand up, by the press of a -different- button than activate.

This isn't helping? https://forums.nexusmods.com/index.php?app=core&module=usercp&tab=core&area=ignoredusers

Hmm, not an expert, but it looks like both, the hair and the armor, seem to have a NiAlpha property inside the NIF. This will cause fighting for which one's in front every time strongly depending on the angle in which you look upon it, thanks to Oblivion's absolutely terrible implementation of transparency effects. (As a rule of thumb, no 2 transparent meshes shall ever be seen overlapping in a scene or this will happen. Your hair will also vanish when you stand before or behind a waterfall for example.) The hair must have it, but I don't know why the armor also should. It doesn't look like anything about it is transparent to me.

Hmm, sadly I also don't know of any ways to get the texture slots or models of a "race" like that. I haven't yet found any means to edit or even create a race record itself while in game either. There's also no function I know on how to obtain race-based attributes like texture slots and body part models from an actor/NPC. Blockhead can apply several overrides of multiple such attributes on an actor/NPC through script, but even Blockhead can only retrieve what overrides are currently in place and not what those attributes are without an override. However, depending on what exactly this all is meant to achieve in the long run, there may be different means to go about it. For example, a while ago I managed to create a working shape shifting, or I should better say "race" shifting, approach myself with just a few simple tricks. I can change the race of my player character (or any character for that matter) on the press of 1 of many buttons, including hair style and eye textures. Switching race will switch skin textures, head mesh, tail, voice, etc., and will even trigger race-based script recognition from other mods. I can for example run around as a Breton and nothing will happen, but as soon as I switch to one of my dragon races, their scripts will kick in. Blockhead, too, will kick in as usual and apply all overrides configured for the race. It will "not", however, give racial abilities or spells and the like as when you started the game "as" said race! The trick is quite simple. I have a set of reference NPCs stacked away in a remote holding cell, which I use as source for several "Copy..." OBSE function calls. Namely "CopyRace", "CopyEyes" and "CopyHair" will work really nicely with this. If you copy eyes and/or hair before copying the race, the latter will even trigger a render-update and the visuals will immediately change. I haven't yet found "any" means to also copy FaceGen data in any way though. Well, apart from age that is.

It's only on the games sites, but should be hard to miss, the tabs under the section "More Mods" where there's "New Today", "New This Week", "Latest" etc. This also makes it so you only get new comments filtered by game.

You should also automatically be tracking your own mods. So the tab "Tracked Content Updates" should show you "<member X> commented on <your mod Y>" with links for you to click through. I always visit this tab when I saw there were new comments in the bell dropdown.

If it's not yet published, it also won't show on the member's public profile. You need to pull down the "Mods" menu when on a file site and click on "My Mods". This gives a complete list of all your file pages, public and hidden.

I think we will need a mod list/load order to know what all could be interfering here. I know a bunch of situations where animation overrides through one way aren't working, because there's already some in place through another means. Blockhead is a major source for this in my own observations, as I'm using Blockhead and my own animation overrides in some of my projects, and I always have to toggle Blockhead's overrides off before applying my own for any changes to take effect. And I know of quite some other mods which could be similarly affecting this. Nowadays though the cleanest and safest approaches to animation overrides on race or gender or only player basis are those applied through Blockhead. I set up an entire set of replacement animations for just about every movement, action or idle for my main character and his companion. Whether I play one of them myself or have them following me, they always use their own custom animations and nobody else does. And it's just a bunch of KF files appropriately named, no scripting or plugin necessary.

Quite late to the party, but there's one other quite important point I haven't seen mentioned, yet. Under original conditions the game knows no load order when it comes to BSAs. The order in which they're loaded is said to be erratic at best. Thus the replacer-type mods asked about won't even reliably work anymore, when served in BSAs. A BSA cannot override contents from another BSA. It was even an unwritten rule back then that a BSA of your own doing must not even contain the same files as another or Vanilla BSA. However, with the introduction of some OBSE-loaded framework, bringing BSA handling up to speed with how it's done in the newer games, this is said to be no longer a problem. BSAs can override contents from other BSAs in Skyrim et al, and with said mod it is said to be the same in Oblivion then, too. But I for one think the main motivation for Bethesda to put all Vanilla assets in BSAs instead of having them as loose files was 1) order: no game of a comparable size I know does "not" use archives for that, and 2) mods: that you can (almost) completely erase your entire data folder and the game will just jump back to Vanilla state, is definitely a welcome thing when it comes to handling mods.

Hmm, I'm not exactly an expert in this particular topic, but I do know the way you use the OnHit block it doesn't work. According to the CS wiki documentation the block is used to trigger when the "actor" the script is running on is hit by the actor given as parameter. The script with this block cannot run on the shield. It must run on an actor. However, putting it onto the player actor in the CS also isn't exactly a clean or sane way to go, as only 1 plugin in load order can do that at the same time. I think detecting when the player was hit is nowadays done quite differently. I just can't off the top of my head recall how it's done. And then, your GetEquipped check is totally valid, being executed on "player" specifically. But calling "IsBlocking" when the script runs on the shield will always be false, as the shield will never be in the animation state of blocking. This, too, needs to be called on the player implicitly. I'm sorry I'm not of more help right now. Maybe I'll come back when I stumbled across something more. Can't promise though.

There is a bar labeled "Refine results Found XXX results." on top of the results on every search or list page. When you click it a drop-down opens where you can refine your filtering. Of interest for your intention would be the section "Refine with tags". Doesn't this suit your needs?

There was a full-fledged post reputation system in the past in use for a while. You could +rep and -rep posts once per member. It was also aimed to be used as a means for self-moderation practically, as posts beyond a certain number of negative reputation were automatically displayed as hidden with a means to pull open and read them regardless. Meanwhile posts above a certain number of positive reputation were marked as especially helpful or something along that line. Sadly it took only a short time until the feature was so heavily abused, folks were literally silencing authors on their own comment sections, OPs in their own topics, actual helpful or true replies have been hidden into red-marked obscurity with a warning sign, while troll posts and personal attacks (before they were spotted and removed completely by moderation), pretty much everything that was bashing/hating on an author or OP, was +rep'ed into heavens, got a very visible mark of importance and like an official endorsement from the site to boot. Needless to say the feature had to be forcefully removed at this point. While I still see the people around every day who would abuse even a simple thumbs-up system the same way, with only a thumbs-up and no thumbs-down at least half of the problem would be gone. That's also the reason why there's only endorsing a mod or abstaining anymore and no thumbs-up and thumbs-down on mod pages either. But the most simple explanation would be, this IP.Board framework is just too old for that, now. However, if you want this to be an actual inquiry, request or suggestion of an addition to the forum features, you should post in the feedback, suggestions and questions section rather than here. There's also higher chances a CM or admin will see it and respond over there.

Going by their ref IDs (not looking mod-added) and Google not finding their names (no Vanilla NPCs) I'd rather look out for a mod which named them instead of a mod adding named NPCs. Maybe they're just Vanilla bandits or something but you're using a mod giving all of them unique names, making them more immersive. I've heard of these. Both parts of their names have been in use in Morrowind with different forenames/surnames, so it's not unlikely they were like randomly combined from a database taken from the game to create these new ones.

If you click on "More Reply Options" to switch to the advanced editor, you'll also be able to attach some files to your posts. However, the total number and file size of attachments you can have across the whole site is severely limited. In contrast to uploading to an external host and linking from here instead it's not a feature used much.

I also don't know how it could even technically be a Vortex-introduced issue, if the filename is generated by the game. Though I've read a lot of statements saying the savegame count is "also" determined from the highest numbered save in the folder. Making a new folder would zero that. But wasn't it also said this was done before and the numbers remained the same? But as the number is also stored inside the header of the savegame file itself, I'm not sure if simple renaming will do any trick. And yet, I've also read of people doing just that and it working before. This seems to be quite the oblivion'esque issue situation. We'll never guess the culprit as we just can't believe it is what it is.

This is a completely random idea, and I don't know if it will even lead to something, but if it's not to be found in any kind of "file", did you check in the registry already?

Woah, that's a necro. Almost 9 years apart. But as was started to explain on the previous page, not all music files will get used. They mostly need to be MP3, 128 kb/s would be ideal (don't know if it's required), and most importantly it's known that MP3s having meta data (artist, album etc.) will often be ignored. So one sometimes has to edit the music files some before. Though... What's this pure technical question doing in Spoilers anyways?

My, that topic's old. :ohmy: But yes, I was already going to repeat the exact same instruction when I read you pasted only the NiTriStripsData above. That's like only half of the job and the other half will be mismatching. The tangent space for example is used for texture wrapping calculations, and if the NiBinaryExtraData doesn't match the NiTriStripsData to the last vertex, texture wrapping won't work either. And the NiSkinInstance is the rigging information, that is which vertex sticks to which bone of the armature with which weight. You guessed it, this one must match to the NiTriStripsData as well vertex for vertex. (That's btw. why your vertices were shooting off into infinity in game as if you were using an insufficient skeleton file, which you can't be when it's a simple foot.) Now, of course those other blocks/nodes can also be adapted to the new NiTriStripsData through other means. The tangent space can be recalculated directly in NifSkope even. Don't know about the NiSkinInstance though. There's no rigging information inside the NiTriStripsData after all. You could've copied and pasted over the NiSkinInstance block just as well though to fix at least that. But really, if it's the very common simple "mash-up" deal, using copy & paste "branch" on the NiTriStrips/Shape block is the way to go. :thumbsup:

Huh, now that's an exotic variant they used in that NIF. The other way round "foot:UpperBody" I've seen quite a lot of times. It tells the game to use the foot slot texture but tells the onlooker it's meant to be an upperbody body part. This way around though? What does it achieve? Yes, I forgot to mention the "code name" is case-irrelevant, so "upperbody" is "UpperBody" is "Upperbody" et al. But why adding a remark for labeling it "foot"? It can't be meant to be a foot, or using the Vanilla upperbody texture would be the wrong choice. I can only imagine a mix up, mistake or the creator just not knowing what it means and copying it 1:1 from some other NIF. But then, from where? In which case would the combination of "use upperbody" and "label it foot" ever make any sense? Hmm, but that's both, irrelevant and for someone else to answer. But yes, if it was indeed named "UpperBody:foot", then yes, it was coded to use the upperbody texture slot in game, explaining the observed use of the "upperbodymale.dds". Ah, it's just knowledge easily lost. And I'm certainly not the only one knowing it. I posted it like a hundred times on this very forum and elsewhere for 10 years. I simply can't be. But I don't think it's a matter of keeping us around, as much as it's a question of how long will we still be. I consider this place a kind of second home, and the members of this community as friends I just don't know yet (those few of the ones I do know still around excluded). So far there's not been any movements towards making me no longer feel welcome here either, unlike in many other games' communities, where I'm not feeling like welcome to even join. But with my already limited amount of free time ever constantly decreasing, along with my will or inclination to mod quite sadly, and all those of the old guys of the past who already left, it's simply a matter of fact I, too, won't be able to be around forever, as much as it'd hurt me not to. ...Ah, well, but that's just me getting old I guess. Nothing to worry about. Move along, nothing to see here. P.S.: That "appetite" video was a blast from the past, one of my favorite movies and so, so fitting. Although, should I now feel even older considering I know it all too well?

You should know, as it was you who summoned me. :wink: It was also attempted via a PM, but as usual I checked the topics before reading my PMs. Yeah, I'm witnessing more and more how valuable knowledge such as this doesn't come up anymore in questions like this. I'm afraid what will happen, once the last of us who know all this will no longer be around. Things like this were considered "common knowledge" once. Nowadays it's everything but. :ermm: But let's first wait and see if it actually helped.

Alright, here I am, as summoned. :sweat: Now let's get down to the 1 thing I think all of you were missing so far when it comes to how to make a model an actual body mesh. It is right, the texture assigned in NifSkope "must exist" and must have a normal map as well, else you'll get a "missing texture" or "missing normal map" error in game. And yes, the race records also have to be correct for all of this to work. Though in case of this being about "make a Vanilla NIF compatible to Robert's Male" I take it a proper setup of Robert's Male, thus the race texture records, is already a given, or should not be the immediate problem at least. You can always correct me, if I'm wrong. But as soon as the material is "skin" it doesn't really matter anymore "which texture" was set up inside the NIF. The game engine will take over here and use the texture assigned in the race record for that. This, however, additionally underlies another rule. Which body texture "slot" gets used by which mesh is controlled by the NiTriShape/NiTriStrips node's "name". And this is what I think is still wrong here. Valid "code names" are "upperbody"/"arms", "lowerbody"/"legs", "hand", "foot" and "tail". A ":" counts as a remark indicator, so everything coming after it gets ignored. You remember node names in body NIFs of other body mods being something like "foot:upperbody" or "foot:legs"? That's just additional information for a reader/onlooker of the NIF. The game only cares for the part before the ":", which in most body mods' cases always says "foot", for the reason all of you know. So my first guess as to what's still wrong would be just that, check the name of the skin meshs' nodes in the NIF and make sure it also says "foot", like in every other Robert's Male (-compatible) NIF. (And the code for a thumbs up is ": thumbsup :", or just use the emoticons from "Show All".)

Hmm, don't know which game, sounds like one of the newer ones I don't know too well, but I doubt they changed the fact that records inside an ESM should not "override" records inside another ESM, like the game's master file. In the older games overrides such like changes to Vanilla game NPCs could only be stored inside ESPs, never inside ESMs. Don't know how much, if at all, this changed for the game you're talking of.

Actually, won't TES4LODGen just create object LOD, i.e. rocks, trees, houses etc.? I'd think it'll be TES4LL (Landscape LOD) in this case rather. But then, this could only fix issues created by a previous run of it, which is unlikely here as it wasn't mentioned.