DrakeTheDragon

Just adding to further eliminate some confusion. You do not put your folder "FOREHANDZEBRA MOD" into "Oblivion/Data" but its "contents". For example when there's a "meshes" or "textures" folder inside or a "FOREHANDZEBRA MOD.ESP", you put those into "Oblivion/Data". That's why on a normal mod install it will always ask you whether to replace/merge (merge is usually what you want) "meshes", "textures" and others of the prominent folders. You don't put "Data" into "Data", "meshes" into "meshes", "textures" into "textures" or any arbitrally named folder containing "Data", "meshes", "textures" or ESPs/ESMs into "Data", or likely the mod will not find those files. The contents from "meshes" have to go into "meshes", from "textures" into "textures", but never those folders themselves. If you see any structure like "Data/Data/textures" or "Data/textures/textures" afterwards, it will very likely not work. Oh, and on a side-note, having a "Data" folder inside your mod package is actually "bad" practice. For usual mods only containing plugins/masterfiles and resource files there's no need to add to the confusion by adding a "Data" folder around the actual contents. You can simply move the contents of the archive ("meshes", "textures", esp files) from your extraction folder into your "Data", folder when there's no "Data" folder needlessly wrapped around them. OBMM can decipher those package structures and locates the actual files and folders inside such a bogus "Data" folder. Likely BAIN can, too, but I'm not sure. But the gist of it is, a "Data" folder needlessly wrapped around the mod's actual contents inside an archive just isn't necessary and only adds to the confusion for the "I just extract into my data folder"-people. There are cases where a "Data" folder is required inside your archive though, for example when the mod contains more than just plugins and resource files but also executables like "obse_loader.exe" or other things which need to go into "Oblivion" directly instead of "Oblivion/Data". That's not your regular every-day kind of mods though.

ESP/ESM filenames cannot simply be changed "after the fact" though. The filenames are used for parenting (ESM/ESP mastering), in BOSS masterlists for load order and Bash tag suggestions, for association with BSA archives to be loaded automatically, and even stored in savegames for the mods you used. If I rename an ESP I was using, it's like I deactivated the mod and made a cleansave. I would loose all quest progress, items from the mod I picked up, everything. It constitudes a clean start-over. If I was to rename the ESP of my dragon race mod in the next release, I would be "CTD'ing after the Bethesda logo" everybody's game who's using a mod that requires mine. Mine will technically be gone, as far as the mods requiring it are concerned, and the games will insta-crash right after updating my mod. You can change the names displayed in the "Files" tab at every point in time though, maybe even the title of the mod page, if I'm not mistaken. However, with mods with multiple downloadable/additional/optional files this will turn into a nightmare of a concept pretty quickly by design. You cannot have 2 ESPs with the same filename, just so it's the same as the mod name, without one replacing the other, or can you? A sort of prefix instead of completely identical filenames would sure work though. Using similar filenames to the mod's name "from the start" definitely helps with association. So that's not a bad idea. For "already released" mods though it sounds like it's not worth the trouble, and there will be a lot of it due to the points I mentioned.

It's not really a problem with obse_loader.exe. This is a known issue with OBGE and Anti Aliasing. It just doesn't happen when you don't use the obse_loader.exe, because without OBSE there's no OBGE. Read here for more details and solutions: http://forums.nexusmods.com/index.php?/topic/188894-no-main-menu/page__st__10

You do know that's the place where your savegames are stored, too? :ermm: Deleting whole folders when it's only settings from 1 or 2 .ini files inside there causing the issues sounds not-just-a-little extreme to me.

I can see the issue here. This script auto-equips the item right after it was added to the inventory. This, however, won't happen when it was already inside the inventory from the start. It's missing a condition for this initial presence. In the game you cannot access NPCs' inventories directly, as if they were chests or something, so these mods which enable you to do that do so by moving everything from the NPC's inventory into a temporary container which is then opened by the player. When you're done messing with its contents, all items from inside it get moved into the NPC's inventory, that's when "OnAdd" triggers and why. Now let's see how we could expand this script so it also triggers the equipping right from the start initially. scn 000TailSlotSct ref Owner ref Me short bDoEquip begin GameMode if bDoEquip == 1 set Me to GetBaseObject set Owner to GetContainer if Owner != Player if Owner.IsActor == 1 Owner.EquipItem Me endif endif set bDoEquip to 2 elseif bDoEquip == 0 set bDoEquip to 1 endif end begin OnAdd set bDoEquip to 1 end If "bDoEquip" is "1", it will do the player and actor checks and equip the item accordingly. Then it sets "bDoEquip" to "2" so this block will never execute again, unless "bDoEquip" gets set to "1" again by getting added into someone's inventory. If "bDoEquip" is "0" though (the initial state), it will get set to "1" and accordingly execute the check and equip part next. This will happen only once, so it's only to cover the "initially inside the inventory" situation as well. Hope it works. Regarding Wrye Bash's bashed patch, maybe this Pictorial Guide will come in handy. Especially images labeled "g4", "g5" and "g6" cover bashed patch creation and the various options and settings one can check or not. The option you're searching for should be inside "Tweak Clothes". However, this is only in my out-dated German version of WB, and I don't know where it'll be in your's. Keep in mind though, there is no "unlimited" equipment possible within the game. You can make items equippable without occupying a slot, which is what this option and related stand-alone mods do, but by removing the slot assignment from the item you also make it not render, as in "invisible". You can equip an unlimited amount of invisible items, but only those which occupy a slot and there can only be one of accordingly are the ones which will show up.

The filenames aren't really the important part here. There's a name attribute inside the KF file, if you open it with NifSkope, which is telling the game which kind of animation it is meant to be used as. Just look inside the castself.kf you got and you should be able to spot what it is with ease. Then rename the one inside the howl.kf you copied into a new castself.kf accordingly and the CS should be able to detect it as a castself animation. Beyond this though I can't be of much help. I'm not an animator and my knowledge in this field is very limited. edit: Just read it up, it's the name of the NiControllerSequence and in a castself.kf it reads "CastSelf".

They're presented in the dialog coming up when you "rebuild" your bashed patch. There's a multitude of sections you can enable and disable certain features in and this is found inside one of them. However, keep in mind there can always only be 1 item equipped in a slot. You can remove slot assignments from rings and such, like this does, but if an item doesn't have a slot, it's simply not rendered, doesn't display.

There is no way to tell an NPC exactly what to wear. They equip all they have in inventory according to certain settings or their script packages. The only way to make sure an NPC ends up with the items you want is to only have those items in its inventory. However, an NPC doesn't equip tail slot items on its own. Those must always be force-equipped via scripts and you must make sure they stay equipped, or the NPC will simply take them off on its own the next evaluation of its script packages. What's the "tail slot script" you're trying to use? Maybe it's just insufficient for the task and needs refinement.

Don't ask me. I just learned the hard way it sometimes doesn't in the past. At least it's nowhere near anything you could count on happening. It was never executed in abilities during my tests, I had to switch to GameMode for things to run, and I'm hesitant to say it'll be under other similar "constant effect" circumstances now.

What's the script going to do? Likely some of the blocks, especially the ScriptEffectUpdate block, will not get executed when in an enchantment or an ability. Maybe the ScriptEffectStart will, but that's only once and never again, and ScriptEffectFinish is not going to happen with a "constant" effect. However, blocks like GameMode or MenuMode always are, once a frame or something, even for Spell scripts.

Oblivion itself wouldn't do that. Are you using Streamline by any chance?

Ok, but for future reference I advise against simply deleting the .obse co-saves. Depending on the mods you're using you can loose important data that way. OBSE scripts using the new complex data structures such as arrays and strings store their contents in these files, as there's no place for this in the regular savegames. Deleting the files means deleting the data from those variables. It might not have much impact with only a mod using some rather constant string_vars, but a highly dynamic array structure for storing complex game world information could turn out a critical loss when deleted.

Inactive plugins shouldn't matter. What isn't loaded can't be missing its master. And as we're not talking of crashes during loading of savegames but crashes before the main menu, it's save to say inactive plugins shouldn't matter. So you "were" using Darn UI previously or "are" you still? If you uninstalled Darn with its custom font files and the originals weren't restored or maybe the Oblivion.ini you had to alter for Darn UI wasn't correctly restored and is still referencing the now-missing font files, this could be an explanation. First thing you should do is check if it's caused by the ini. You're only using Oblivion.esm now and nothing else, so it should be save to have only default settings in your ini, just as after you configured the game for the first time after install. Locate the "Oblivion.ini" somewhere inside "documents and settings" "my games/oblivion" or where those files are found in your OS and rename it to something else (renaming is safer than deleting, so you can restore it later or use it for comparisons). Then start your game through the regular launcher, make the necessary configurations where needed, and a new "Oblivion.ini" with only default settings should be created automatically for you (it's a copy from "oblivion_default.ini" found inside your "oblivion" folder in "program files" with only the settings the launcher is able to configure filled in). If this fixes your crashes, they were caused by a faulty ini damaged by inproper uninstall of Darn UI or something along that line.

A CTD during the logo screen is usually caused by a missing master. One of the plugins you're using is missing one of its masters. What's your load order? This kind of severe error is usually easy to spot. It can however also be caused by missing fonts and other not-so-obvious files. But then you would know if you installed and uninstalled any such UI-changing mods.

Noticeable slow-downs in load and save times caused by mods are only known from so-called savegame "bloating". Especially with new OBSE data structures saved in the so-called OBSE "co-saves" (the files named identical to your regular savegames but with the suffix ".obse") this can get pretty severe. One script with missing string_var or array_var clean-up and the amount of data cluttering your co-saves is multiplied each frame. This bloat can be removed by deactivating the plugin it's coming from and saving (a so-called clean-save) or by using Wrye Bash's savegame bloat removal feature. I haven't yet encountered, or heard of, any noticeable load or save time slowdowns from just regular mod usage, no matter how many mods you use. From all I know only actual bloating can cause this severe slowdown.

If you take a close look into the NiTriShapes in NifSkope, you'll see that head meshes have a "non-applied" translation of a certain amount upwards. The head mesh appears at the proper location, above your shoulders, but the internal position of each vertex is still close around the origin. This is so the EGM and TRI morphs from FaceGen can be applied to the mesh. They're stored as offsets from the original position of the vertex inside the file and the game interpolates between the original position and the offset according to the FaceGen slider setting. The connection between the vertices and the offsets is controlled by their index in a list of vertices, the so-called vertex-order. That's why count and order of vertices in the meshes to be morphed "must not" be changed ever, or this connection will be lost and the morphs will offset different vertices making the mesh literally "explode". I guess what happened to your mesh is somehow the translation got appplied or it was exported at this height out of the modeling app but the non-applied translation upwards is still added to it, thus it's at twice the height as usual now. That's why the blinking eyelids move the whole way down to where they actually should be, down to where the TRI file dictates plus the non-applied offset upwards. It's a matter of fact that head meshes can't be imported from or exported into NIF directly for various reasons. One being the vertices getting resorted on im- and export and thus the connection between the NIF and the EGM/TRI files getting destroyed. Maybe you experienced another one, a mix-up of the non-applied translation with a real offset.

From what I read, this ability for Premium members and such will be kept, just the regular down-repping ability, or maybe post reputation itself even, was mentioned to be removed. But let the staff and devs chime in for the details. They know best what they're going to do.

Negative reputation given to a post serves only "one" purpose, hiding it when it gets 5 of them. Hiding a mod author's replies in his or her own comments section serves exactly "no" purpose. Negative reputation is no "I disagree" or "I don't like what you wrote" and especially no "I hate the very thing you are, thus I down-rep all of your posts" measure and received far too much abuse in the past. It's become a means of anonymous, and as such ban-free, trolling and the damage far outweighs the advantages. Last I heard, it'll be gone for good in its entirety soon.

Happy Birthday, Nexus!

It could turn out to be a "Misuse of the Files Area" uploading something which isn't a mod. I'd rather use some free file host like MediaFire, 4Shared, SendSpace, DropBox, etc.

Hmm, you never said you were having this "can't inject DLL" issue when trying to start the CS with OBSE, else we could have solved this as well right away. As for determining the ingame time, I think this page could prove useful to the task. And guilty as charged, yes, that's me. The Anthro-Dragon Race is my eternal WIP project. :sweat:

Yes, with the first 2 digits replaced by the mod index from Wrye Bash an additem call should work. Make sure you use the hexadecimal number though, as it could be given in decimal form instead. I'm rather clueless why your game crashes when you disable a plugin, but maybe it's because you're wearing/using something from this mod at the moment or something. I'd rather not load "all" plugins into the CS at once. It'll rather crash and you still can't be sure the FormID returned then really is the one the game's waiting for.

Now, now, don't be so harsh. Blender is a little more complex to learn than a simple armor mash-up in NifSkope and I can imagine for a newcomer it's much too daunting to even consider it at first. Those armor mash-ups are usually done with only NifSkope anyways, and while there sure will be clipping issues, I've seen an abundance of mods done exactly that way, without the help of any real modeling app or anything. The OP wants to start slow, so let him do just that. @OP: We will need either a screenshot of the NIF tree on the left, completely expanded so we can see every node, or you could just upload your NIF itself some place so we could have a look at it in NifSkope ourselves. edit: Oh, and for what it's worth, the NIF tree structure can be messed up the exact same way even in Blender, when not doing the merge correctly from the start. It will definitely help knowing what to look out for when this happens in future.

You could of course disable the plugin, save without it, and start the mod over again, but if it involved a rather complex questline or anything, this progress will be lost. "additem" via console likely doesn't work as your giving the wrong FormID. The hexadecimal number consists of 8 digits, while the first 2 are dependant on the plugin's place in your load order. This value is called "mod index" in Wrye Bash and can be read up also in other mod managers. If you read this up in the CS, it's usually 02 or something, as this is the place of the plugin within the opened files, Oblivion.ESM (01), name-of-plugin.ESP (02). That's why the first 2 digits from within the CS are always useless for when in the game. If you remove the mesh, i.e. you get a Missing Mesh sign, then it also has no collision boundary, and as such can't be picked up. Perhaps that's the cause for why it fell through the ground to begin with? The original mesh itself had no collision boundary? It will just keep falling and falling now once dropped. If you changed the plugin itself to add another item to the selling NPC, I don't know why it's crashing now. But if you created a new plugin with the old one as master and edited the NPC from the other one in it, this will only work under certain circumstances. The normal CS does not support ESPs as masters and as such you need to ESMify the ESP you want to edit by your new plugin first before loading it in the CS and ESPify it back before starting the game. Then you can use it like a real masterfile and all and its relation to your new plugin will stay intact when saving. Otherwise it's lost on save, that's likely why it's crashing. Or just use CSE, the Construction Set Extender, as this one allows for ESP mastering in the CS natively.

If it's not a typo, how about "set ActorValue to player.getav Armorer" instead of just "player.getav Armorer"? The line as it is in the script you posted has no function and your "if" checks compare an always empty variable (ActorValue = 0 constantly).