David Brasher

The people who made Oblivion were much too fond of quest items. A prime example is the dagger that Lucian Lachance gives you when you accidentally kill an ally in battle. Like you may have no intention at all of joining the Dark Brotherhood, but you are now stuck with this item for a quest that you never plan on completing. That example was by design. The developers meant for you to have this dagger and not lose it, because that could break the Dark Brotherhood quest arc. Seridur's key sounds like it might be tied up with the Order of the Virtuous Blood quest and post quest repeatable activity. In many cases when you complete a certain quest, the scripting will make a key so that it is no longer a quest item and may be dropped. In other cases, the developers failed to do this and left bugs in the game. Or in some cases, they used bad judgement and made a key into a quest item when there was no reason for this. One obstacle to making a mod such as you propose, is that many keys open more than one door or container, and if the keys were set to vanish upon use, then quests and dungeons could be broken by leaving vital doors and containers unopenable because the key no longer exists.

This was a common problem with Windows Vista and I am not surprised to see it elsewhere. There is mod that allows you to access the console by equipping a magic ring in-game: http://oblivion.nexusmods.com/mods/13133/?

It seems like I have heard of mods that make it so there are no quest items. Quest items are the items you cannot drop or sell, like the keys you describe. A mod like this would have the negative side effect of making it so you could break a quest and be unable to complete it if you sell or lose the wrong item, but that really doesn't happen all that often. So this kind of mod would not make the keys vanish, but would allow you to sell them or drop them whenever you felt like it. So you might try searching for a mod using key words like "No quest items."

This could require a system of scripts. You would need a quest script on an active quest that had a quest variable that other the other scripts could refer to. Each enemy that must be killed before the door unlocked would need to carry a script. The door would need to be set up as a reference. So you would use many copies of a script like this on your monsters: SCN AAEnemyDeathScript ; Object script attached to each and every enemy that must die before the door unlocks. Begin OnDeath Set AAQuest01.KillCount to AAQuest01.KillCount + 1 End Note that in this example the quest is named AAQuest01. The script attached to quest AAQuest01 is named AAMyQuestSCRIPTwithAnExcessivelyLongName. The object scripts that refer to variables in other scripts must refer to the quest name, not the script name. So it must be like this: Set AAQuest01.KillCount to AAQuest01.KillCount + 1NOT like this: Set AAMyQuestSCRIPTwithAnExcessivelyLongName.KillCount to AAMyQuestSCRIPTwithAnExcessivelyLongName.KillCount + 1You would use a quest script like this: SCN AAMyQuestSCRIPTwithAnExcessivelyLongName ; Attached to your quest. Short KillCount Short DoOnce Begin GameMode If DoOnce == 0 If Killcount == 23 ; If you have 23 monsters on this level that must die before the door unlocks. AAMyDoorREF.Unlock ; Where your door is set up to have the reference ID "AAMyDoorREF." Set DoOnce to 1 EndIf EndIf EndYour quest script would have to be written, compiled, and installed on a quest before you could compile your object scripts. Note that this system is not entirely safe from failure. Like if you had 23 monsters, what if two of them disappeared? Then the door could never be opened. Like a monster might fall through the floor and get lost in the bottom of the cell where you can't fight it and kill it. The game might just never place and render a monster. Maybe the AI is bad and a monster wanders off and leaves the cell. What if the script doesn't always trigger right? You could kill 23 monsters and only have the script fire 21 times. (Oblivion is a bit buggy sometimes.) The door would never open and the mod would be broken. So if you encounter problems when play-testing, you might want to consider changing things so that the door opens when 90% of the monsters are dead, or change it so the door opens when the boss monster is dead, because he is the toughest and will probably be the last to die.

Maybe your border remover mod is not working because you have another mod that adds borders back in. Your border remover mod would need to load after all the other mods that touch the border.

The hold boundaries are just nonsensical and someone scrawled them on the map in five minutes so they could meet a deadline. In real life, political boundaries tend to follow areas where strong political control can be exerted. Capitals are often centrally located. Failing that, there are often firmly loyal cities and towns in the controlled political areas which extend the control far beyond the reach of the capital. But Skyrim is in a state of anarchy. Bandits and monsters rule most of it. The only places you see guards and soldiers are the big cities, a few small villages, and a few forts. So if I was to draw a political map of Skyrim, I would draw little circles around each town with dotted lines rather than solid lines. In addition to the name of the town, I would write the name of its ruler's hold capital in parenthesis. Like how small islands on a world map may have a notation such as (United Kingdom) or (France.) The lines around towns would be dotted instead of solid to indicated "boundary undefined" such as it is with certain boundaries in the desert on the Arabian peninsula.

Mod dirt is kind of a misunderstood thing. If something is an intentional edit, then it is not mod dirt. But it can still cause mod conflicts. But maybe it is supposed to conflict. It depends on the intent of the mod. If you want to change the base game and have your mod win conflicts, then it will need to load after conflicting mods and you can more frequently do things such as use search-and-replace. If you want to avoid more mod conflicts, then you will more frequently disable and replace conflicting objects. If you delete conflicting objects rather than disabling them or moving them under the floor, then you will cause CTDs when conflicting mods are running. (This is the rational behind the misnamed TESVEdit UDR references.) If you really want to avoid mod conflicts, then don't be editing Breezehome. Get a new cell, even if it is a replica of Breezehome.

Go to CK > Object Window > Items > LeveledItem. Add your spell tome book objects to leveled lists with names starting in "LItemSpellTomes-"

I hate Steam Workshop because it is built wrong and they won't fix it. Steam Workshop is bad because it severely limits what types of mods you can upload. On Skyrim Nexus you can upload practically anything. Here are some common types of mods you can't upload to Steam Workshop: 1. Mods that have both an .esm and an .esp. 2. Mods that have loose files. 3. Mods that include documents like readme files, user guides, walkthough documents, and spoiler documents. 4. Mods with images such as maps or pictures of the different options that can be installed. (Like maybe the armor comes in two colors depending on which texture files you choose to install.) 5. Mods that have multiple .esp files for things like different difficulties, different item colors, different degrees of lore-friendliness, or for compatibility with different mods.

In the same object list in the CK where you built your "Recipe" you will also see "Temper" entries. So for an example of the two object types, there is one called "RecipeArmorDaedricBoots." This is for crafting daedric boots. Further down the list there is one called "TemperArmorDaedricBoots" This is for improving daedric boots. In your mod, you will need to build a second crafting object for tempering. Follow the patterns used in these vanilla Skyrim objects whose names start with "temper-."

I would say that you should not do this for your first Skyrim mod. This mod idea is like what an expert modder would try to do and fail at. Some of the ideas might be possible, but it is certainly not what the CK and the Skyrim game engine are designed for, so it would be cutting across the grain and fighting an uphill battle the whole way. I suggest you pick an easy thing for your first mod.

The CK's archiving function totally stinks. Don't use it. You can use archive.exe which does the job properly and you can make a single .bsa. Content in a .bsa may not be accessed unless there is an .esp of the same name. So if you have a .bsa named RustyArmor.bsa, you must also have a mod named RustyArmor.esp to access this stuff. If your mod is named MyArmorMod, then it isn't going to work and you are going to have a lot of invisible armor. I have not used SkyData and do not know how it works, but I can imagine you having terrible problems and two-thirds of your data missing and inaccessible. Or did you build two additional .esp files to go with your two new .bsa files with new names? There should be no difference between running Omegared Armor Compilation with loose files or with with a single .bsa. The file paths remain the same. Just be sure to remove all the loose files for that mod that you had, or else the game will refer to your loose files instead of to your .bsa.

You can initially disable certain items instead of moving them down out of sight or deleting them. Then they will not be visible or usable in the game and will not create UDR references. TES5Edit even has a function that can automatically do an operation like this on a mod that a new modder built: Undelete and Disable References. (This may be where the badly named acronym "UDR" comes from.) This function does the same thing that you are talking about manually doing when you build your mods. Although I would say it is better to just never delete the references. Then you don't have to spend time using the function and verifying that it worked. Deleted references are not actually "mod dirt." They are bad things that can cause CTDs if two mods refer to the same items and one of them deletes them, but they are not mod dirt. Mod dirt is unintentional or avoidable edits to things that do nothing toward making the mod function as designed. If you delete items, you did it on purpose because you wanted to edit the game to be that way. The stock answer would be that there is no way to build a mod that TES5Edit does not need to be used on. Modders are always supposed to do their final modcleaning in TES5Edit before uploading. They may have done a really good job while building the mod and not find a single thing to clean, but they are still supposed to check. This way the mod is clean by the time the gamers get it, and they don't need to clean it, and if they do try, then they won't find anything to clean out of it.

Windows Vista/Windows 7 has insane security restrictions. It tends to view mods and other gaming software as malware trying to harm your computer. The tightest security is in folder "Program Files." This is why Elder scrolls games are installed outside of "Program Files." With mod building software, you usually have to reinstall it after reinstalling Skyrim in a new location. If you just move your existing mod building software to another folder, there will be problems. Savegames are uneffected by reinstalling the game. (Just so long as you do not take any actions to go erase them.) If you don't feel safe, then back up your savegames to another folder that won't be involved in this removal and reinstallation of files. Stay away from the Python version of Wrye Bash. It tends to be too hard to install and installing it can mess up other programs like Blender. Use the standalone version of Wrye Bash if you can get it to install. I was able to install standalone 301 this morning without any problems.

Your attitude is a bit confrontational and could perhaps give offense to some. It is true that many weapon and armor mods that add new things to the game are not done in the ideal fashion. But there are reasons behind this. Skyrim has a design flaw that can cause terrible mod conflicts if you try to have a vendor sell a custom item. Basically only one mod can do this, and if you have ten weapon mods you are going to have problems. There are workarounds, but they are not easy for the new modders to use. we are talking about the modelers that could not even figure out how to put their items into the game other than through crafting. Custom vendors work just fine, but building a custom vendor is beyond the skill level of many modelers. Skyrim has a design flaw with custom quests and dialog. Since around Skyrim Update 1.5, mods with custom quests don't work so well. The workarounds for modders are tricky and still not well tested and the workarounds for gamers are unreliable and not sure fire. So it may be too much to ask for modelers who are so unskilled in the CK that they just have their items available through crafting do these things. Even most Skyrim questcoders are hard pressed to cope with the buggy software. So it is not simple for modders to add new items to the game through quests. Many gamers only roleplay righteous heroes. So it would not be a good approach for modders to make it so all users need to steal the new items as you suggest. Likewise, putting items into the world loose has its drawbacks. Many gamers would get really frustrated and send the modder lots of questions and complaints. Many gamers are in a hurry and they want their new items NOW! They don't want to have to wait to randomly find a new item two weeks from now. Many gamers do not have the skill to use the CK to figure out where the modders placed the items they want so badly. So they are likely to turn up their noses and walk away from mods designed this way just as you do with mods that have the items be crafting only. So I would say it is not as simple as you think. But I do agree that it would be nicer if modelers would build their weapon and armor mods such that the items are not available only through crafting. I especially dislike mods where the items are only available through console codes. That is like the ultimate in immersion breaking acquisition methods.