DrakeTheDragon

The lore of Elder Scrolls games changes almost completely with every new release in the series. So what lore exactly should one stick to? Granted, things from Star Wars or Star Trek, spaceships or hover bikes on Nirn, is quite a stretch of the imagination, but it's optional, for fun, and who cares can just look away. As long as it's at least remotely explainable to some extent (weasel lore), you just make your own lore. But that's coming from someone introducing a fantasy of Western Dragons from Ancient Earth into the game, so who am I to talk?

I figured as much. That's why I explained. It's all fine.

Wrye Bash basically is a Swiss Army knife tool for modding this game. It doesn't really matter whether you learn all there is to learn about it. Concentrating on only the few select things you'll always need for your own personal aims is totally sufficient already. For example it "is" a mod manager as well at the same time, but someone already preferring another manager is not pressed to even look at Wyre Bash's. Its "bashed patch" you will quickly learn is about as invaluable to getting more than 1 mod running smoothly together in this game than is to us the air we breath. Being able to copy player or NPC faces from plugins to save games and vice versa is a nice thing, but who's really gonna need that? Likewise being able to flag-switch ESPs to ESMs, so the Vanilla Construction Set can use ESPs as masters of other ESPs (it "can't" do that without it, only ESMs) and later back to ESPs before you run the game was a godsend for authors back in the days, but that's not really relevant to any non-author at all either. It does have means to apply Archive Invalidation to your game through the most common available means as well, which will definitely come in handy here. Its manual is really a lot to read. But just limit yourself to what you really want to know and it's all just really simple small features. It's just so very, very many of them. It's kinda comparable to getting used to a Unix/Linux OS command line. Who's ever gonna need to know "all" the available commands, when all you need to do your stuff is "cd", "ls" and maybe "vi"? (Not saying that's all you ever need. That of course depends on your goals. But it's an assumption for the example that you'll only need those 3 for whatever you're about to do.)

Erm, excuse me but what's that to do with anything I wrote? This isn't about file replacements working or not. Of course you can also fix the problem of missing tails by giving the non-tailed skeleton NIF file a tail as well. I wrote that in the second line, agreeing with what you wrote being a solution, too. I was just explaining the backgrounds why by default any newly made NPC, while using Vanilla resources in your game, will not have a tail, as the non-tailed skeleton file is assigned by default. If you gave the non-tailed skeleton a tail, of course the problem is also gone. It doesn't change the fact though that the default selection still is the non-tailed file, is all I was saying. Two distinctive solutions, select the right skeleton in the plugin or replace the wrong one physically, but the underlying cause for the issue is still the same, the wrong skeleton is selected by default.

Well, "ls *.esp" won't be of much use here, as you want to get the resource files (meshes, textures, sounds, etc.) you installed from replacer packs, not any ESPs. The file expects to get entered paths like: meshes/characters/_male/skeleton.nif meshes/characters/Argonian/tail.nif textures/characters/Argonian/footmale.dds ... While there are tools, like OBMM or Wrye Bash, who can generate said "ArchiveInvalidation.txt" automatically, I'm not sure a simple shell script or similar could be cooked up to do the same. What these tools need to do is to either "know" the complete list of Vanilla files inside the BSA(s) or to read them up on the run, so they can then use this list to "compare" which files have external loose file replacements lying around in the Data folder subfolders anywhere. There's no sense in putting files/paths into there which are not inside any of the BSAs. And I'm not sure it won't even be detrimental/harmful to your game to do so in that case either. So it really must be only "Vanilla" files where there are replacements for present in your Data folder at all. If neither of the modding tools which can do any of the above 3 automatically nor OBSE is a possibility, then I'm not sure there's really much more one could do. Coming to think of it, I'm on a Mac myself, and while I do/did use a virtual machine for modding and running the game primarily, there's also been times where I tried Wine or similar wine-based approaches in the past. They all resulted in crashing messes, but that's probably only myself to blame. I do remember though, I did get Archive Invalidation working through a tool I installed into the bottle, or something like that. Never had a problem with replacer mods even inside Wine wrappers definitely. Wait a second... There's been a guy on the Oblivion forums specializing in modding the game in Wine and cooking up detailed step-by-step guides for that. Let's see if I can't re-find that. edit: Ah, yes, it was 1Mac, and their guides are technically for MacOS. It is about modding the game in Wine though, so maybe some still applies. They do not specifically talk about Archive Invalidation either, but they do install all the tools which can do it automatically into Wine. So maybe it helps?

The problem is that in Oblivion races may not have their own skeletons, but actors can all have a different one assigned. If you create a new actor, it will by default use the human skeleton ("skeleton.nif") and the tailed skeleton ("skeletonbeast.nif") needs to be specifically selected first for them to have a tail. Or if you use a skeleton replacement like which Pellape linked, where both skeleton NIFs are basically identical and have a tail, then it won't ever matter anymore of course. But still each actor having an individually selected skeleton independent of their race is the underlying cause of the issue also fixed that way.

Well, the thing is, all these mods or tools applying the BSA / Archive Redirection solution to Archive Invalidation basically do the same exact thing. They put an "empty" dummy BSA file into your Data folder and modify the "sArchiveList" entry in your "Oblivion.ini" to load this in a special place so, for some reason I haven't yet quite completely understood, this empty dummy suddenly becomes the "only" BSA left still requiring invalidation for external replacement to be used over its contents, effectively eliminating the very need for Archive Invalidation itself once and for all. So it shouldn't really help opening this BSA to get its contents, as there are none inside. As a little history lesson, there's multiple different approaches towards Archive Invalidation at least in Oblivion modding: -- The file "ArchiveInvalidation.txt" placed somewhere inside your Data folder -> This is the very first approach introduced to the scene by the game creators themselves. This .txt file is simply used to list all external files meant to be used over internal files from inside the BSAs. Or better yet, to tell the game which internal files from BSAs are no longer to be used and external replacements should be preferred. It basically instructs the game which parts of its "archives" to "invalidate", thus the name. Sadly said approach was soon found out to work quite unreliably. With increasing number of files more and more of them randomly ceased working and the game's Vanilla originals from inside the BSAs were in fact used again. Sometimes even every replacement stopped working at a certain number of files listed, all was back to Vanilla, and then once a few more entries got added suddenly everything started to work again, but sometimes also only for a limited time. ...As you can see, use of this approach was soon discouraged by everyone but very old and antiquated readme's or install instructions. -- The approach named "BSA / Archive Alteration" -> In this a tool basically unpacks and re-packs the Vanilla BSAs replacing all internal files with their external replacements, if present. This way the game will use the mixture of old and new resources without running into any conflicts, as there's only 1 list of files left. This approach has to be re-done every time another replacement gets added into the game or removed from it though, and the worst iterations of said tools didn't even consider making backups of the Vanilla files before editing them. It was changes you could no longer undo unless you reinstalled the whole game. Soon, in times of better less intrusive approaches, this one also quickly became discouraged among the scene, even though some people still swear on it for certain other reasons. -- The approach named "BSA / Archive Redirection", which I completely explained above. And then there's an even newer solution to it all based on an OBSE plugin, "SkyBSA", which completely changes how archives (BSAs) and resources get loaded by the game, making it mimic the way all of it works in Skyrim, where BSAs can even override other BSAs (in Vanilla Oblivion there's no priority for BSAs, so having replacements for Vanilla files in another BSA will lead to random and constantly changing results in game), and especially where external replacements (also called "loose files", the primary base for modding this game) -always- take priority. It only works through means of OBSE though, so if the Oblivion Script Extender is no option for whatever reason, so will be SkyBSA. And just so this is clear, going by some potential misunderstandings expressed in the OP, Archive Invalidation is "not" needed to get any kind of mods at all to run inside the game but "only" for loose file replacements to Vanilla files, i.e. so called "replacement" mods of any kind.

Hmm, no idea what's up with this. But if the spell id you got can be put into "RemoveSpell" 1:1, then it definitely did contain the mod-index (1st 2 digits = place in load order), too. When opening a plugin with the CS, the mod index will at best just be different (How many plugins are open at a time and in which order? What's the CS' "load order"?), but you will definitely not be able to find the whole 8-digit thing, unless you open exactly the same plugins/masters in exactly the same order as inside your game. (Please don't. It's heavily discouraged to open that many plugins/masters at once in the CS.)

In some rare, exotic cases it actually does. It's unknown when or why exactly, but sometimes the "missing normal map" error indicator will beat the "missing texture" indicator, so the mesh gets pitch black or invisible instead of purple. And then there's also the as of yet still unexplained situation where, when using a body mod, like Robert's Male, but no clothing and armor replacer yet, that is Vanilla clothing/armor meshes with Vanilla bodies inside still used when wearing items, the items themselves will completely disappear. This game just never stops coming up with weird unexplainable ways to fail sometimes, really.

When I installed that list myself some years back, I went about it group by group. As long as you keep the order and the dependencies to your choices, you can skip all you want from Bevilex' list. But as the important thing in installing whole lists of mods is to never ever install them as a list but individually one by one, I did thorough testing of the results and their impact on performance at least after each of the groups. And like I said I also skipped a whole bunch of the options when it was something I didn't really need or want in my game. The best part of Bevilex' list is that you don't even need to install them all.

I'm a little concerned by the use of "OnActivate" here. OnActivate will only run once every time, not loop, and only when the object itself gets activated by something, that is usually clicked on by the player, attempted to pick up/interact with by an NPC, or directly through a script. But I'm not seeing anything that does. All I'm seeing is an action that's meant to loop in something I don't see looping.

Hmm, I'm far from knowledgeable in this regard, but going by what was said in your other topics, could it be MoveTo'ing the sound object will stop the sound just like disabling it does? Or what method do you use to diagnose "it's not working" after a MoveTo call? MoveTo is already known to cancel several other running things on the object that's moved. Maybe a playing sound effect is just one more to the list.

Not "really" familiar with most of these, but while the race records and assets might be inside the "COBL Main.esm", the introduction of them into the selectable races for play is sure meant to be done through the "COBL Races.esp". Don't have this one enabled, shouldn't have the new races available in your selection. However, when you do have the ESP inside your data folder and just not activated in your plugin manager of choice, chances are its effects are still getting incorporated into your game when re-compiling your Bashed Patch. If you go through the multiple tabs it offers for selections (don't know which one(s) exactly would show this plugin), the races plugin could be selected in some of them, regardless of if it's activated in your load order or not. That's a teensy tiny detail one has to be on the lookout for when using the otherwise invaluable Bashed Patch. It sometimes also includes deactivated plugins' effects on recompile, unless specifically told not to through the selection/inclusion tabs. (It remembers your selections of course, but whenever a new plugin comes into your load order, by default it's selected for inclusion.)

Ah, no, no, no, you're going circles. There's some other misconception at play here. Having a file named "Marker_Error.nif" in your data folder does NOT mean you have a missing mesh. Every game has this one, either inside the BSA or a replacer for better visuals in your data folder. It also isn't "generated". It was "installed" by one of the UOPs, as this replacement for the error visual is part of their archive. It's a model file like any other NIF. It just so happens every time the game finds a missing mesh it will use this particular file to "display" it. You have a missing mesh, if you "see" this model inside your game, not if you only have the file in your data folder. That alone does mean nothing, as it's always the case in every game that installed the UOP or another replacement for the error marker. I hope this clears it up a bit. edit: Hmm, didn't read your last post completely to the end, Striker. (Been up for 2 days with only 2 hours of sleep.) It seems you already covered most of what I said in this last go. But if after reading this post there's still some confusion through wording, I hope mine helps clearing the last of it up. And one more FYI I just recalled, that is if I recall correctly: The Vanilla game's "Marker_Error.nif" did not have collision, so you couldn't click it, couldn't select it, to gain further information about "which" item has the missing mesh, thus the UOP team created a replacement file which has it all.

Hm, is it possible to create an equipment item that only visually occupy ring slot but will not occupy it (or any other) logically, i.e so you still can have 2 rings AND that item? The opposite works. An endless number of items can be worn without occupying a slot. But that also means none of them are rendered and can be seen. You cannot, however, get anything visual without it occupying one of the limited number of slots.

What made you "rename" any of the mandatory folders, so now the game doesn't even know the files you installed exist? The 101 of manual install is to "merge" those folders, so what's inside "meshes" goes into "meshes", what's inside "textures" goes into "textures" etc. Don't touch or rename files or folders unless specifically instructed to. There's now records inside your game pointing to resources in paths like "Data/textures/<item-type>/<mod-name>/<item-name>.dds" and in your install they're not where they're searched for.

It's always a question of where these meshes are from. If you take a Vanilla Oblivion game mesh and break it apart, you basically have implicit permission from the company already to publish this as a mod or resource as long as it's for the same game. If you take any other mesh to break it apart however, then you'll need permission from whoever the mesh belongs to publicly share your work as a mod for this game. There's quite a lot of tile sets in the original game, and I've seen a bunch of custom created ones uploaded as well over the years. So it's always a matter of where the original meshes are from and if they are allowed to be shared, in whole or in part.

Always rebuild your bashed patch after changing whatever in your load order. You never know what all plugins' contents were merged into it and it made dependent on them accordingly.

In Oblivion no equipment item will ever be rendered on the body, if it does not occupy a slot. But when you look into using modded equipment, there'll be many rather unusual items which aren't rings per se but for several reasons occupy the ring slots. With those items in mind it quickly became a necessity to always have the respective option in the Bashed Patch checked so everything "hiding" rings no longer will.

Scripts on objects in inventories (often called tokens) will always run while the actor the inventory of which it is in is near. In case of a token inside the player's inventory the script will run constantly, or I think, as I haven't checked for split-second interruptions when e.g. switching cells. But I'm using tokens a lot myself to get certain scripts to run on certain actors, or the player, because assigning a script directly to an actor is limited to only 1 at a time and doing it this way will cause lots of conflicts with other mods, doing it with a quest script needs a huge database of tracked actors with long running loops. And so far they've always been working very reliably. However, if this is only about the player, or any single actor, alone, doing it with a quest script is also fine. Their frequency can be fine-tuned just as much as any object script's. And the player's always easy to reference anyways.

Could IsWeaponOut help?

The older functions still don't know what a "string_var" is and expect a "string" as input parameter. However, there's the handy "$" operator, which can be used to make them think the string_var is a string. string_var y let y := "speed" let x := PlayerRef.GetActorValue $y ;should work now

Don't touch the "ArchiveInvalidation.txt", no matter what outdated mod install instructions might tell you. It was never working reliably to begin with. This file must be empty by all means, or all kinds of weirdness can ensue. Use BSA Redirection as Striker instructed. Or use the OBSE DLL "SkyBSA", which is said to make resource handling like it's in Skyrim, with archives' contents being able to override each other (something original Oblivion can't have without it either, a BSA cannot contain files meant to replace others) and loose files always having priority over BSAs. That said, it can't hurt undoing the mess Steam was making by giving the BSAs more recent file dates than any replacement file could ever have, again like Striker instructed, as I'm not sure even SkyBSA can overcome this weirdness reliably enough.

Let's not confuse them too much now. Making new plugins depend on existing plugins isn't really rocket science at all, it just comes with a few road blocks one must know. The biggest one is the Vanilla Construction Set can't save (or load?) dependencies between ESPs. Only ESMs can be used as masters/parents of an ESP straight away. Doing as you were told in the Vanilla CS will loose the parents every time the plugin is loaded again, if the dependency was even saved once to begin with. Wait, no, it definitely wasn't. To circumvent this one can do the old trick of using Wrye Bash's "ESMify" feature to toggle a switch in an ESP's header to make the game/CS think of it as an ESM every time one wants to edit the dependent ESP in the CS, then use "ESPify" later to switch everything back to normal before launching the game. But that's so yesterday by now, since using the Construction Set Extender (CSE), an Oblivion Script Extender (OBSE) DLL vastly improving and enhancing the Vanilla CS when launched through OBSE, instead will automatically allow for saving/loading other ESPs as masters/parents of the active plugin. And yes, while an object can always have only 1 script attached to it ever, you can introduce a copy of that script, or an override of the existing even, with your additional code inside, through a plugin depending on the original.

The forum does have means to add attachments to your posts, but it's severely restricted/limited and mostly not meant to be used. The only way to add access to resources to your posts is by uploading them somewhere else first and then linking to them. Some people also just post the download urls without making them clickable links.