DrakeTheDragon

But last time I heard of it you needed to use the external packaging tool for this, as the CK packer failed to do that on its own. Easy to miss for newcomers.

Every time a Scripted Effect spell is cast a new instance of the script is created and run. They don't know each other and can't access each other's variables. All variables start at uninitialized value every time a spell is cast. What I was concerned of in regards to a limited number of spells active at the same time was the number of the replacement stones "only". As you're only having fixed number, 5 stones, trying to swap out 6 stones the first placeholder will vanish when the last stone gets exchanged, as it will be moved to the last stone's position. You can only have 5 replacement stones in place at once, so one of the dark stones will be missing its replacement. But this was only for when it was still a spell to exchange a single dark stone only. Now that it loops through all dark stones in range storing "DisabledCount" in the spell script where it's at "0" again for every new spell you cast, maybe a more "global" storage method should be considered. As it is right now, there will be dark stones without replacements in place when the number of stones replaced (in sum over all spells running at the same time) exceeds 5. Where is the spell cast at now anyways? If it's now On-Self, I think you're good to go, as I've never seen a single spell being in effect twice or more times on an actor so far. There could be an internal prevention in place here already. What's the issue with CompareModelPath? Can you show me some lines of the scripts?

With Wrye Bash you can always investigate which plugins were active when a savegame was created. You get a complete list of the plugins you will need for the savegame no longer to complain on load, together with their load order by time of creation. Just click on a savegame in the list of savegames and the list of "masters" will show on the right.

Hmm, wouldn't this just be the same way it always was? After calling the function in a script, nothing happens right away, but the files need to be reloaded for the items to show the new looks. The changed path/file is "stored" in memory and in the next savegame you create, of course, but the change doesn't actually "show", yet. Iron Armor still looks like Iron Armor until I trigger a reload of the NIF. There are several ways to make this happen, reloading the game is one of them, unequipping and reequipping the item is another, but I was understanding your last post as if it now happens "immediately" after the function call, without me ever doing anything to trigger it. Now I'm confused. :ermm:

It was changed? Really? Last time I checked, well, admittedly already more than 2 years ago, it still had this warning sticker in the documentation making me aware of this requirement. Changes to the biped models now apply immediately, everywhere in the game? It doesn't help Me much, as I still have to exchange the item worn by an instance of a cloneformed copy, and as such can't save any steps, but it's very valuable to know this regardless.

Sorry. Last time I did it I didn't yet know of CSE. I installed it long since, but... you know, no time for modding means no possibility to try the other way out so far. And I'm not going to describe solutions I haven't used myself, yet. :sweat:

Well, for one, OBGE requires OBSE, as it's mainly a DLL plugin for OBSE. For two, the menu text to disappear when using OBGE is a common issue pretty well discussed in the respective OBGE topics. From what I can recall OBGE doesn't play nice with Anti Aliasing enabled in the game. You can, however, force AA through your graphics card drivers even when it's turned off ingame.

You cannot use FormIDs (the hexadecimal numbers) to reference records from another plugin or masterfile. The 1st two digits represent its place in load order and this isn't actually the same when opening it in the CS. One change in load order, or a difference between your's and someone else's and your plugin will not work for someone else. I used the ESMify feature of Wrye Bash to turn my dragon race plugin into a masterfile, so I could use my races in a companion mod, turning Viconia de'Vir into a female dragon. I can now change my dragon race plugin however I please and will not have to update Viconia de'Vir's plugin every time or anything... unless I change the EditorID of the race or some of the assets I made Viconia use, of course. Nothing inside the plugin is changed during the process of ESMify'ing nor changes anything inside Viconia de'Vir's plugin by parenting it to my race mod. I only have to keep in mind to ESMify my dragon race plugin every time before I open Viconia's plugin again and always ESPify it back afterwards before I start the game again. Keep in mind you can only modify the assets of the "active" plugin. Any attempt to touch the records of one of the masterfiles will create a copy of them inside the active plugin and not touch the masterfile at all.

Quite weirdly I always have to ALT-Tab my way through the running processes until I'm back at Oblivion. Then I can press Enter to activate the Close button of the popup dialog and Oblivion closes completely. It depends on the kind of freeze/crash you encounter though. Mine's not guaranteed to be the same as your's.

Now that makes sense. I figured as much as introducing a kind of Nexus Torrent Client. Was just wondering how many mod users would actually be willing to become seeders. Some incentives like mentioned could help though. Consider my curiosity sated. Thanks. :thumbsup:

One thing I'm wondering now. Who's gonna be the seeders in this equation? The Nexus file servers? In which way would that help improving the current situation with file server connectivity or bandwidth issues? If it's the Nexus users, which is what such torrent networks usually live from, a couple thousand clients having downloaded the file in question already and now providing it for others to download while they're online, how many Nexus users would suddenly be getting torrent clients when they never needed any before to begin with? How could the Nexus increase that number? Where could this system get its seeders from at the end of the day? And in a number which would help improving the situation? Just wondering. :unsure:

While I doubt you'll be loosing out on anything important when you're blocked from downloading ones mods out of spite or due to an off-site disagreement, I still see no use in doing that either. There's this bunch of morons coming along yelling at me that my stuff isn't lore friendly and they'll never be going to download or endorse it, and all I do in response is blocking them from downloading it? I can hear the laughter from far away already even without a voice chat system. Silencing trolls in your comments "after the fact" may give you some peace at least around this place, but it will not stop them from being trolls at other places outside of your control, whereas clicking the Report button usually will. And they will go out of their way to keep trolling you by other means, if only for silencing them. It's a "won a battle but lost a war" situation.

They're all listed up here: http://obse.silverlock.org/obse_command_doc.html#Wearable From "SetMaleBipedPath" down to "CopyXXXPath" all are functions used to this purpose. Keep in mind though, for the actual changes to become visible you need to unequip and reequip the item in question, or cause any other action which will make it "reload" its NIF file. Keep also in mind to use the "objectID:ref" notation instead of the "reference." one, as inventory items can only be obtained as BaseObjects. If you change the NIF file used by the Iron Armor Cuirass, you will change it for all Iron Armors in the game at the same time. It might not exactly show right-away, as they, too, need to update their visuals first, but internally its NIF file is changed for all references used in the game. Once an NPC equips an Iron Armor Cuirass, it will use the new NIF, too. I for one was using CloneForm to create new BaseObjects for the new appearance first, then exchanged them, but this comes with a bunch of drawbacks of its own.

This is actually a good idea. It is what the "Mirrors" tab is for after all.

As in "playable or NPC race" or only as a "creature" rather?

I added a lot to my post after you posted this, as I wasn't told you posted something already by then. For some reason "Target" seems to be reserved, as the script highlighter in my browser highlights it. Either try "target" instead, as ObScript is case-sensitive in some regards, or a totally different variable name even. "==" on something obtained in a spell script via "GetSelf" in this case will not work, as you're now comparing apples with bananas, an actual "reference" with a BaseObject's EditorID. Try using "GetIsID" without a reference, exactly like I used it. In a spell script it could be troublesome to use "GetSelf" where it's not necessary. But most important of all, let's first check if spells even work on activators. Use this simple script in your spell to find out: begin ScriptEffectStart MessageBox "Hit something!" end Then cast this onto random things and see if it does pop up at all.

Sounds to me like a scripted effect spell with the exchange taking place in the spell script itself could do the trick here. Though I admit scripting the exchange will be the hard part. The spell script will have to check if it's running on such a dark welkynd stone or not. One such way could be using GetBaseObject and then comparing the returned value with the EditorIDs of the traps you're intending to replace. E.g.: if GetBaseObject == ARTrapEvilStone01 Or you could use GetIsID for the same comparing purpose. E.g.: if GetIsID ARTrapEvilStone01 As there are already 9 different generic and 1 quest-related (though this one shoots only on a quest NPC and seems to be of no relevance to your idea here) "types" of those traps in the Vanilla game alone, and only The Nine know how many custom ones in mods, it will be difficult to catch them all, but I think you can catch "most" of them via the NIF file used for their model instead, by using CompareModelPath for example. if CompareModelPath "ARTrapEvilStone01" And you would already catch all of the above... though you as well catch ones not intended to be caught with this solution. Still not caught would be those with a custom model used for the same purpose, but I think now we're getting too far away from your original intention anyways. I had a short look into their scripts and it seems they're either "triggered" by something else (a trigger plate maybe or an invisible trigger zone) (ARTrapEvilStone01, ARTrapEvilStone02, ARTrapEvilStoneFAST01), or they're the kind that shoots on its own while the player is in range (ARTrapEvilStoneAUTOFIRE01, ...02, ARTrapEvilStoneAUTOFIREFAR01, ...02). They only react to the player (hardcoded target). And they're all firing through means of their object scripts. In retrospect only the last 4 seem to be relevant and the way of identification through EditorIDs seems to be very feasible. I for one wouldn't mess with their scripts to turn them inactive, although this would be a feasible attempt as well. The most simple approach to get rid of them "temporarily" would be to "move them away" or "disable" them and place a placeholder at their place. This could all be handled in one single spell script... if all works out as intended that is. begin ScriptEffectStart ;the identification part: if (GetIsID ARTrapEvilStoneAUTOFIRE01) || (GetIsID ARTrapEvilStoneAUTOFIRE02) || (GetIsID ARTrapEvilStoneAUTOFIREFAR01) || (GetIsID ARTrapEvilStoneAUTOFIREFAR02) disable ; will disappear and should no longer be able to react on player or shoot at player endif end begin ScriptEffectFinish enable ; should reappear after time runs out and also be able to react on player and shoot at player again automatically end If we're lucky, everything will work fine already and the running out of the spell will turn everything back to normal. But it could be calling "disable" on the object will also disable the continuation of this spell or its script execution. In this case we'll have to put the disable and enable part into the object script of the replacing object we put in its place as well as an actual timer counting down. I'd say try this attempt first and come back telling if it works or not. In case it really won't work that way at all due to the repercussions of "disable", I could go more into detail on what to do otherwise. You can use MoveTo to put something else into the trap's place without risking savegame bloat from PlaceAtMe, but then it will only work for a fix number of traps at once, as you'll need to have a fix number of replacements with "persistent reference id" ready from inside a holding cell or something. And you'll need some scripted trickery taking care of which of them to take and when not to act at all due to no more replacements being available at this time... and all such things. ... ref self ... set self to GetSelf ; now we have a reference to the target to work with other than the default reference automatically used in spell scripts ... TemporaryReplacementStone01.MoveTo self ; move replacement 01 from holding cell to target disable ; disable target ... TemporaryReplacementStone01.MoveTo HoldingCellID ; move rep. 01 back to holding cell when time is up ... "TemporaryReplacementStone01" and so on have to be "persistent reference id"s for replacement objects you placed into the holding cell with EditorID "HoldingCellID". In case MoveTo doesn't lead to the replacements being placed at exactly the same location, use GetPos and SetPos, for X, Y and Z respectively, and appropriate "float" variables, to store the location of "self" and set the replacement's location exactly after using MoveTo to get the replacements at least into the same cell and nearby. In case the disable-enable-based approach above doesn't work out, you could try using following approach instead. ... short active float timer float pos ref target ref self ... begin GameMode if active == 1 && timer > 0 set timer to timer - GetSecondsPassed elseif active == 1 && target != 0 set active to 0 set self to GetSelf target.MoveTo self set pos to self.GetPos X target.SetPos X pos set pos to self.GetPos Y target.SetPos Y pos set pos to self.GetPos Z target.SetPos Z pos target.enable self.disable self.MoveTo HoldingCellID set target to 0 endif end And do following when "moving away" the traps inside the spell script: ... set self to GetSelf ; obtain a usable reference to the spell target TemporaryReplacementStone01.MoveTo self ; get the replacement at least into the same cell and nearby set pos to GetPos X TemporaryReplacementStone01.SetPos X pos set pos to GetPos Y TemporaryReplacementStone01.SetPos Y pos set pos to GetPos Z TemporaryReplacementStone01.SetPos Z pos ; get position absolutely exact TemporaryReplacementStone01.enable disable MoveTo HoldingCellID set TemporaryReplacementStone01.target to self ; at least if replacement is an Activator, too, this should work, set target variable of rep to target set TemporaryReplacementStone01.timer to 10 ; set countdown of 10 seconds over in the script of rep. set TemporaryReplacementStone01.active to 1 ; initiate ... Make sure all variables are properly defined inside the spell script ("self" of type "ref", "pos" of type "float"). Phew, that ought to have given some pointers. I hope it'll all work, as I can't test it at the moment.

As a suggestion to mod authors themselves, why not. I placed a mod of mine on another file host and linked to it in the "mirrors" tab, split into multiple pieces even, because a user with dial-up was unable to download it. As something the site does automatically for every mod above a certain size though I, too, am rather skeptical it'll happen.

For one, the system is currently pretty taxed and registration emails getting sent is not the first thing reported taking ages, so I wouldn't be surprised myself, if this was affected by the same delays. But I'm wondering... you got "this" account, and having "multiple" accounts leads to the ban of "all" accounts... what is the cause for you wanting a new one when you already have one? Maybe if you tried using a "taken" email address, i.e. one that's already in use by another account, this one, that could be causing issues as well, as you should be receiving a warning or something instead of the email being send, but due to the site issues currently this isn't happening either. If it's a new email address, maybe it's a problematic one which can't receive mails automatically sent. I've designed a registration email interface myself in the past and had to take care of a lot of oddities preventing even plain-text emails from getting through the mail servers. In this case maybe the site should be giving an error or warning, too, but yet again due to the site issues currently it simply isn't happening. Or the whole process just isn't functioning correctly right now. The persons most likely able to help with whatever it is that's going wrong here will be moderators or site admins maybe. Try PM'ing one of the staff members for help.

http://forums.nexusmods.com/index.php?/topic/751961-site-issues-since-dawnguard/

By its description Slof's Better Bodies only contains textures (mainly) and requires Robert's Male and Female bodies to work. There is no change in "shape" between Robert's and Slof's. What you're encountering is likely "Vanilla" body meshes from inside clothing/armor meshes, which will not use Slof's more defined skin textures but Vanilla Oblivion textures. In Oblivion your body is included within your clothing items. You exchange your body all along while wearing them. For not to get old Vanilla body meshes while wearing Vanilla items you will need so-called "Stock Clothing And Armor Replacers" for your respective body mods. With those installed neither your body's shape nor the skin textures used will change while wearing items from the original game, DLCs or overhauls anymore.

Skin "textures" are always nude. It's body "meshes" deciding if it has underwear or not. Namely it's the files "meshes/characters/_male/lowerbody.nif" for male and "femalelowerbody.nif" or "femaleupperbody.nif" for female. Neither meshes nor textures of the original game can ever be "overwritten", as they never existed as external files in those folders to begin with. Those folders ("meshes", "textures", etc.) don't even exist in an unmodded game. Now, were you using any Body Mods already and now have to restore their underwear'ed versions, or did you never touch a Body Mod at all and want your Vanilla body back? The first simply requires a reinstall of your body mod(s), the later only the deletion of the files I mentioned above (well, add "upperbody.nif", "hand.nif", "foot.nif", "femalehand.nif" and "femalefoot.nif" to the list as well, or the effects will only be "partially" undone, of course). A set of such bogus nude body mesh files was accidentally included in Deadly Reflex 6, if I'm not mistaken. There are also a number of step-by-step instructions out there on which files exactly to remove in this case.

As you reinstalled Oblivion, make sure it's up-to-date patched to version 1.2.0416 or most of today's plugin files (ESP) will just be "silently ignored" by a pre-1.2 game version, no matter if they're activated in the launcher or not.

They're using the same icon as OBMM already? Then chances are good they're assigned to be opened with OBMM by default. If you double-click them, does OBMM come up asking you if you want to add them to your list of OMODs? That's what's happening when I double-click OMODs. They get copied into the OMOD folder automatically, ready to be "activated" (=unpacked and installed). Given you know where your OMOD folder is, and no windows OS with UAC is preventing you from putting the files there directly, you can also simply put the ".omod" into the folder where all your other ".omod"s are, and the next time you start OBMM it will be in the list of OMODs, ready to be "activated". Turning an OMOD into an archive is as simple as right-clicking the OMOD in your list of OMODs (right-hand section in OBMM, a listing of your OMOD folder's contents) and choosing "convert to archive". If I got you right, you tried dragging the OMOD right into OBMM itself, "not" into the folder. While dragging a file from one folder into another in your explorer nothing at all can interfere and move files to different places, so I guess them getting put into the corrupted folder happens when opening them via OBMM, which is what happens when I double-click them. This now would simply mean they are just that, "corrupted". A lot of people seem to get corrupted downloads these days while the Nexus network is so taxed. (Surprisingly mine are always fine.) So if this happened to you, too, and your downloads got corrupted, you now have a bunch of corrupted OMODs no tool will ever be able to open. Doesn't OBMM complain or something, when you try to open these? What happens when you simply double-click them?

1. Jan 1970 00:00:00 is the human-readable representation of the Unix-Timestamp 0 (=0 seconds since the start of the Unix epoch), that is what you get from an empty timestamp field in the database table. I guess the 01:00:00 instead of 00:00:00 comes from the time zone one's in. I take it the code was unable to read the database at this time, thus the empty return values got interpreted into human-readable nonsense and the description and such was gone.