DrakeTheDragon

Hmm, sounds like it could be a faulty NIF file. Would you mind sharing it here so some of us could have a look?

Looks to be still available and also quite current to me: https://www.7-zip.org

Lot's of things in OR were changed through workings of OBSE. Some Oblivion.ini changes have to be made for it to work correctly to begin with, but mostly none of its features are achieved through mere changes in the Oblivion.ini. Most things changed by OR, like inventory menu idles and similar stuff, cannot be undone through just reverifying the game files. But if they kept it the way they started it in the past, most all features and changes of OR can be toggled or fine-tuned through their own numerous INI files. It won't hurt checking your Oblivion.ini, but if that doesn't lead to any results, definitely check OR's own INIs next.

Hmm, I'm not using the mod myself, but it looks like it's an ESP-based replacer, that is the ESP switches records from the old resources to the new ones in the game. This isn't about new options to hair choices for certain races, so other race-changing mods loading later mostly shouldn't be undoing it. Only other mods changing the same hair records will. But does it change Vanilla game hair records now or OCOv2's? Whatever, it doesn't seem to be an installation issue (replacement files not in proper places or for other reasons not replacing their originals). A plugin conflict would be the most likely culprit, so either faulty load order or requiring a bashed patch which isn't properly set up yet. (I was always a little perplexed by what OCO's page listed as "incompatible mods", knowing full well myself a properly configured bashed patch, and maybe some missing Bash Tags fixed, can definitely make it work. But these last years I anyways got a feeling people no longer know what the bashed patch is about and what all it can really do, if configured properly. What with all those "compatibility patches" of late, fixing incompatibilities with another ESP each, which a simple bashed patch inclusion could've fixed just as well? Is knowledge really getting lost for good here?... Ah, forgive my rambling.)

What I don't have an answer for is why the problem isn't more widely reported. That skeleton.nif (or it's variants) are probably the most widely used, or at least close to it. That leads me to think there needs to be some other factors at play that determine whether or not the problem is seen. Which problem do you mean exactly? From my point of view I'm not seeing a relation between the actor skeleton in use and a mod the first few comments of which are talking about the weapon's physics being broken and it not dropping to the ground.

Going by the comments on that mod from back in 2012 it reads like this is a known issue. Maybe the porter did a mistake when they ported the NIF from Skyrim and now the Havok feature on the world model is faulty or something. Would have to take a look into the NIF to know for sure, but my lack of free time won't allow it.

Did you by any chance happen to read M48A5's advice to DovakiinV (it is right above your own post)? Doubt. It is usually too much of an inconvenience to read previous posts. But the advice you gave previously is false though and does not answer the question, That's because it was given 2 years ago, when it was still correct and valid. It changed again some in the mean time, but following the link in my previous post still leads to the right place. It's now under "Site preferences" in your avatar pull-down.

Wrye Bash is the kind of Mod Manager which you can close before launching the game in any other way you like.

Hmm, the way this is glowing, that is actually emitting light, doesn't come from the textures but from the material of the mesh. Glowing surfaces in Oblivion comes from the "emissive" property of the mesh's materials, and then the glow map ("..._g.dds") is laid over it as a kind of mask, to remove glow where it's black and control intensity of glow in other places through grey scale. I don't know what happens though, if you have the surface still emit light but the glow map completely black, apart from it not making any sense of course. The alpha channel of the normal map ("..._n.dds") controls the specularity, that is basically a factor to all shine and reflection effects, but these only work by reflecting light. In your picture there is no light to be reflected, and it also doesn't look like just the reflection of light, so I'm pretty sure it must be the mesh's light emission instead like explained. The mod you linked doesn't have a replacement for the models, only textures. So the emission must come from some other mod, or it even was already part of the Vanilla game's Spider Daedra model to begin with. Oh, and, the body inside and the armor it's wearing are probably separate pieces inside the NIF, so you might be able to turn off the emission of only the one you don't want to glow and keep the glowing red parts and eyes.

Yeah, a lot of the older managers had these quick'n'easy "launch game" buttons in the past without actually needing them. You could still launch the game whatever other way. I don't think the buttons in Wrye Bash will even work with the Steam game though. The Steam version of the game came long after those buttons were already a thing. Yes, check your installation. If in doubt, reinstall the OBSE files according to the manual. Especially mind any newer or up-to-date instructions for using OBSE with Steam, as Steam and Windows 10 have a habit of breaking existing integrations between OBSE and the game. There's still always one functioning way to launch the game with OBSE and Steam left, it just appears to be regularly changing slightly as to how exactly it is done.

Hmm, in your case, using Steam, messing around with the "obse_loader.exe" file in any way is mostly immaterial, as you're never going to touch that thing. It's for non-Steam games only and will even throw up an error, if the game is from Steam. The only use it could ever have to "you" is when you want to create mods yourself and write OBSE scripts inside the Construction Set. I wonder how setting and/or unsetting compatibility mode of the game executable and the launcher could really mess up the OBSE interoperability. Is the launcher executable even still called when launching from Steam? Changing the game executable could mess things up. But why just (un)setting compatibility mode? If you did somehow mess up the "obse_steam_loader.dll" or however it's spelled during the process, yes, that could hurt the integration badly. Dynamic link libraries like these shouldn't really be touched, or can't. But not seeing the extensions by default on many newer OS can of course lead to disaster quickly when people are told to change files around. This sentence of your's got me confused, which is why I replied: 'Cause like I said, running Wrye Bash does in no way necessitate any different way to start the game. However, you cannot really use the OBSE Steam Loader either, as it's not an application, just a library. It's a DLL Steam needs to be able to automatically launch OBSE when the game is run through Steam. And then you said you were "not" using the play button on Steam, which made me wonder 1) why? and 2) which way else you use instead then. 'Cause using the button to launch the game is the only way "I" know to get OBSE working with Steam. I'm not a Steam user myself though, so I don't know all the details but from reading them in these forums here.

You need to use the "quest's" name in the INI file, not the name of the "script". Quest script variables can be accessed from everywhere, also inside these INI files, as the quests serve as global references, but they need to be accessed through the quest names, not the scripts'.

Why exactly can't you launch Oblivion from inside Steam exactly the same way as before, only because you're now using Wrye Bash? Using Wrye Bash as a mod manager or for the Bashed Patch doesn't in any way, shape or form alter the way you have to launch your game. Wrye Bash is a tool you launch, add or remove mods in or create the Bashed Patch, then close and forget about until next time. It's not virtual like Mod Organizer, where you have to launch the game through the manager for the mods to be present in game. It's physical. Installed mods and load order stay intact still when closed. You can choose whichever way you like to launch your game then. And if OBSE launches only when using certain ways, by all means keep using these ways to launch your game.

A couple things. What type of script is this saved as? Quest, Object or Spell? There's a drop-down to select this either at the top or bottom of the script editor (depending on if using CS or CSE). Then, depending on which type of script it is, it also needs to be assigned to something so it will actually run. A quest script needs a quest to be assigned to and the quest needs to have "start game enabled" checked or be started during the game by other means. A spell script needs to be assigned to a spell effect, which a spell of needs to be cast during game. An object script needs to be assigned to an object and said object has to be within a cell with the player, of some actor of quite high processing priority otherwise, for it to run each frame.

No, but clicking save on a script will automatically compile it, thus also triggers the syntax check. It won't save, if it can't be compiled.

The link doesn't work. The url is abbreviated just like the text. The crucial part, the mod id, isn't intact, so I can't even correct it now. But from what you're saying it sounds like the compiler doesn't know the term "string_var"? That would mean you started the CS without OBSE support, as that is an OBSE variable type and thus the script was probably made with OBSE code inside. You need to launch the CS "through" OBSE for you to be able to compile scripts with OBSE code. Usually calling "obse_loader.exe -editor" will do the job. But it sometimes also depends on what distribution of the game (Steam, GoG, disc, etc.) you're using, just like the means to run the game with OBSE differ between some.

Now that's a weird place to take the version from, if it's already written in the file name all over the place. But did Bethesda really mess up the internal versioning of their patches like that? Version 9.0.2 of the version 1.2.0416 patch? Why even doing that? They never cease to amaze me. So, do I get this right, you're using an already patched GotY version of the game with most of the expansions, including SI, already installed, yet still try to install a Shivering Isles patch to bring version 1.2.0416 to version 1.2.0416? One question then, to make absolutely sure. Before you installed any official patch, just after installing the game as is, did you already have DLC Shivering Isles in your plugins/data files and was the version already 1.2.0416 at the bottom of the main menu title screen or not? 'Cause if both was the case, then you don't need to install any official patches anymore.

Hmm, actually IsAnimGroupPlaying can be called on every kind of actor, capable of playing anim groups of course, not just the player. I think the error you got with your attempt was more originating from where this "Actor" was coming from. If it wasn't a "ref" variable set to some actual actor before the call, or an actor reference in direct writing (like "Player" is), then yes, it can't have worked.

Hmm, it works and does the job. There should also be not much room for improvements performance-wise, but I'm no expert in this. You can get rid of the "== 1" in all cases, like I said, as these are mostly Boolean functions here. And you could save the last comparison/condition by just making it an "else", so it'll be processed whenever none of the above checks succeeds. So whichever animation group you're switching to after dodging, the ghost effect will be turned off, not only when switching directly to Idle, like it is now.

What is the script type set to in the script editor? If it's not set as a quest script, it can't be selected in a quest. It depends on what CS you use where this choice will be (top or bottom of the window, usually on the right). It shouldn't be hard to spot some dropdown that says "quest" or "object" or "spell" though.

The syntax notation of SetGhost in the Wiki is quite confusing and non-standard compared to the Wiki's usual notation, but "iGhostFlag" is just meant to say the function has an input parameter that's the ghost flag and of type integer, an additional remark saying it can be either 0 or 1 as well. SetGhost iGhostFlag ( 0 or 1 )So usage by "player.SetGhost 1" or "player.SetGhost 0" is totally appropriate. If you use "iGhostFlag", however, I guarantee the compiler will complain about an unknown function or variable for that. The script so far is looking quite fine to me, and even though it didn't have any turn off of the ghost status, yet, it should've at least made you a ghost the first time dodging. You can simplify the "ElseIf" line by simply making it an "Else". No need to check for dodging "again", when it's simply an "is or is not". Oh, and one more thing, watch the return type of those "Is..." functions. In most cases they're Boolean (0 or 1, true or false) and can be used without comparison. "If (Player.IsDodging)" for the "is" case and "Else" for "is not" will definitely suffice. But if it's still not doing anything, you should definitely take care the script is actually running. If it's a Quest script, it also needs to be bound to a quest, and the quest needs to be started with the start of the game (there's a flag for that in the dialog in the CS).

Take a look at the Vanilla game's hairs. There's a bunch of, I think, 4 different texture files going along with each. At least 2 of them are even weirder suffixed than normal meshes' texture files. I think to recall there's been some documentation flying around about what each of them is used for, but I can't recall where exactly that was, most likely buried somewhere over on the CS Wiki pages. At least one of these was used as another mapping/mask telling the game which part of the singular texture is actual hair and which parts should not recolor along with it. Another was used by the special hair shader to create the shine in strands and such. But that's going way beyond my own knowledge now, just some stuff I stumbled upon when making my dragon horns. I changed their material to "skin" and mapped them to a section in the Robert's Male/TFF full-body texture back then, as the skin parts of them re-coloring along with the horns was less desirable than the horns coloring along with body skin and skin parts always matching.

Actually it's called Archive Invalidation, that is telling the game which internal files from inside its BSA archives are to be invalidated so external replacement files will be used instead, through several different means. But I also recall talk of things being to be done differently again regarding archives and invalidation when in MO/2. So it can't hurt asking those guys, too.

It could also be you're mixing morphed and non morphed meshes, or two morphed ones even, while keeping their morph files (EGM/TRI) untouched. The EGM/TRI files with the same name as the NIF file always must contain only 1 single, and specially positioned, NiTriShapes/Strips block, or it'll mess up/not show up in game. If you remove the morph files (EGM/TRI) though, or change the name of the mix-up NIF so it no longer matches, then you can safely mix together multiple NIFs into one file. However, you'll also have the problem of morphed meshes from NIFs with matching EGM/TRI files not being rigged to a regular armature like non morphed meshes from NIFs without such. It might need work in Blender or a similar modeling app to properly mix them in that case, as they need at least re-rigging and re-positioning, if their setup differs too much as explained.

"Activate" inside a script will activate what it is called on. As it is called on nothing specifically (like "myChest.Activate"), it will activate the object the script is running on, in this case the riddle chest that's to unlock/open only when the right answer was given. However, when this is about rewriting this script so it does something else on something else, not intended to be opened (or activated in general) anymore, then it is indeed no longer making sense to still call "Activate" in there. Now, I don't exactly know how shrines work on the inside (and can't look into the CS to find out), but it's definitely to do something else scripted -in place of- the "Activate" call.