Difference between revisions of "Category:Troubleshooting"

From the Oblivion ConstructionSet Wiki
Jump to navigation Jump to search
imported>Dev akm
(→‎Performance Problems: added tips from haama)
imported>Qazaaq
 
(25 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Troubleshooting Introduction =
This is a collection of articles on troubleshooting TES IV problems -- gotchas, common mistakes, CS bugs, etc. The basic ideas and topics were originally discussed in [http://www.bethsoft.com/bgsforums/index.php?showtopic=628331 this ESF thread]. Continued reports and peer review has moved to a [http://www.bethsoft.com/bgsforums/index.php?showtopic=837706 new thread] now that the original is almost full.


This is a collection of articles on troubleshooting TES IV problems -- gotchas, common mistakes, CS bugs, etc. The basic ideas and topics were originally discussed in [http://www.bethsoft.com/bgsforums/index.php?showtopic=628331 this ESF thread].  
The original list started back in February 2007 has grown to the point that it needed to be split into separate articles. These articles list of some common mistakes and their effects on players and/or the CS. Please suggest more ideas if you can.


These topics could be organized in a lot of different ways, but for now we can start with a simple list.


I've created it as a category so we can add more specific topic articles in the category.
----


What follows is essentially a long list of some common mistakes and their effects on players and/or the CS. Please suggest more ideas if you can.--[[User:Dev akm|Dev akm]] 17:56, 20 February 2007 (EST)


= CTD (Crashes) =
*[[Common Bugs]] - These are annoying problems with the CS and game engine.
 
*[[Common Mistakes]] - These are things that all mod-creators should know not to do.
== Nested If Versus And ==
*[[Crashes]] - Common problems that may cause game crashes (CTDs). See also [[Crash Prevention]].
 
*[[CS Crashes]] - Common actions that make the CS crash.
Don't assume that if-tests stop at the first non hit. For example,
*[[Debugging]] - When something just isn't working right, look here for possible causes and ways to track down the bug.
 
*[[Performance Problems]] - This section is intended as a place to list performance problems and tips, especially those related to scripting.
  if (myref.isactor and myref.isincombat)
*[[Fixing the AddTopic Bug]] - Critical dialog bug fix.
 
*[[Obscure Bugs]] - These issues don't occur very often, and we don't even really know what causes them, but they hurt nonetheless.
could cause a crash because myref.isincombat is always checked, even if myref isn't an actor. Use a nested IF statement instead.
*[[Helpful Programs]] - These programs can help a lot when troubleshooting.
 
*[[Understanding Mod Conflict Reports]] - An explanation of different mod conflicts.
== Existing Object Names as Variable Names ==
 
Don't use existing object names as variable names. The existing ones get priority. If you write:
 
  ref bed
  set bed to ThisBedref
  player.moveto bed
 
this will probably cause a CTD because 'bed' is also a topic id and will get priority here.
 
Other possible mistake names: enemy, accept, contract, creatures, gift, help, inventory, positions, placeholder, tasks, themage.
 
== Quest Targets ==
 
Deleting a quest target will crash the CS. You can get around this by setting the conditions so that it's never displayed.
 
== Referencing Deleted Objects ==
 
It's easy to cause a crash by using a reference to an object that was deleted, or, in some cases to a dead actor.
 
For example, when using GetSelf in ScriptEffectUpdate or ScriptEffectFinish blocks for area of effect scripted spells, GetSelf can point to a dead body
 
This will cause a crash if you try a function that requires the object to be an actor, or even null if a summoned creature has been killed in the area.
 
== Bow Reach Bug ==
 
This bug is fairly well-known but still crops up on occasion. The game will CTD if a bow with Reach = 0 is equipped by anyone (player or NPC). Some of the vanilla Oblivion bows have this problem, so be sure not to replicate the error in your mod.
 
== Activate Self ==
 
When you script an object
#to [[Activate]] itself
#from a block that continously runs (i.e., [[GameMode]], [[MenuMode]], etc.)
#and not bypass the [[OnActivate]] block, as such:
<pre>begin GameMode
Activate player, 1
end
 
begin onActivate
...
</pre>
you can cause an CTD. It seems that self-activation causes the entire script to run from the top, including the [[GameMode]] block, and so will [[Activate]] itself infinitely. You can prevent this by placing the [[OnActivate]] block before the self-activation, as such:
<pre>begin onActive
...
end
 
begin GameMode
Activate player, 1
end</pre>
 
== Activating a Container (including NPC) ==
 
If you meet all of these conditions:
#[[Activate]] a [[Container]], so that you run it's [[OnActivate]] block, that is:
<pre>YourContainer.Activate player, 1</pre>
#from an [[Object scripts|Object Script]] (and maybe a [[Magic effect scripts|Magic Effect Script]], but a [[Quest scripts|Quest Script]] or direct activation would be safe)
#when a scripted item is in it (even a [[Scriptname]] declaration is too much)
you will get a CTD upon activation. The easiest way around it is to place the script on another object (an [[Activator]], etc.) and activate it instead of the container. You can also use a [[Quest scripts|Quest Script]] to activate the container, as such:
<pre>scn YourOpenerQuest
 
ref  rContainerToOpen
float fQuestDelayTime
 
begin GameMode
  if (fQuestDelayTime != .01) ;to activate the container quicker
    set fQuestDelayTime to .01
  endif
  rContainerToOpen.Activate player, 1
  StopQuest YourOpenerQuest
end</pre>
and use this whenever you want to activate a container:
<pre>scn ActivatingScript
set YourOpenerQuest.rContainerToOpen to YourContainer
StartQuest YourOpenQuest</pre>
 
= Common Mistakes =
 
These are things that all mod-creators should know '''not''' to do.
 
== AddTopic Dialogue Bugs ==
 
Even though it's well-known and documented in the wiki, the 'add topic' bug regarding dialogue continues to be is one of the most common mistakes mod-creators make.
 
If two or more mods try to alter the same topic, only the changes in the mod loaded last will take effect. This causes serious problems because the GREETING topic is shared by all NPCs.
 
The problem occurs even if you have [[Removing_default_dialog_tutorial|removed unwanted GREETING dialogue from your NPC]].
 
Motub has written a [[Fixing_the_AddTopic_Bug|detailed description of the AddTopic problem with steps for solving it]].
 
Also, you should avoid having a topic added by both a script and in the AddTopic box. This can sometimes cause problems where NPCs may suddenly start conversing with you from far away, through objects, etc., as if they had been given a "forced greeting" directive (i.e., [[StartConversation]]).
 
Moving the addtopic lines out of the NPC's script and into the topic's result script box will avoid the issue.
 
== Persistent Doors ==
 
Vanilla doors can't be moved in mods without incompatibilities with most existing savegames since their position is stored in the savegame data once you come near them. Modders should try to avoid moving doors from the original game.
 
== Changing Script Variables ==
This issue is best described in Wrye's ESF thread [http://www.elderscrolls.com/forums/index.php?showtopic=625194 Overriding Scripts and CTDs] based on discussions started in MentalElf's ESF thread [http://www.elderscrolls.com/forums/index.php?showtopic=603536 In desparate need of a save game editor]. However, a good summary of the issue is probably worth providing here.
 
The big problem with script variable changes is not which mod wins the conflict in a specific configuration, but that it can change over time. Suppose someone is using a hypothetical BaseModA.esm, which defines MyScript to have the variables '''VarA''', '''VarB''' and '''VarC'''. These variables get the indices 1, 2 and 3. The savegame will just contain the information:
 
  script FormID = xxxxxx
  value for variable index 1 = x
  value for variable index 2 = y
  value for variable index 3 = z
 
In other words, only the position of the variable is stored.
 
Now if the player after some time decides he would like to add OptionalAddOnB.esp, and it contains slight alterations to MyScript, then it may still have the variables '''VarA''', '''VarB''', and '''VarC''', but they now have the indices 3, 2, 1. When the savegame is loaded, it sees that the script FormID is still the same, so it loads variable index 1 into '''VarC''', index 2 into '''VarAB''', and index 3 into '''VarA''' (i.e., in the wrong positions). Depending on the meaning of these variables, serious problems can arise.
 
It gets even worse if '''VarA''' is a ref variable and '''VarC''' is a float variable. You now have the binary representation of that float value in the ref variable and the contents of a ref variable in the float variable. Complete chaos!
 
The only way to resolve this is to start the game without ANY mods active that define that particular FormID, load the savegame (which strips out everything), save, add the files you want in the order you want, and start again. Unfortunately, this solution won't work for changes to scripts that originated in Oblivion.esm (since you can never load without those FormIDs).
 
This is a critical issue that can cause a lot of CTDs, but somehow people still don't seem to know about it.
 
== Savegame Bloating ==
 
Your savegame contains info about changes to the gameworld. The more changes that occur, the more info that needs to be saved, thus the bigger your savegame file becomes.
 
One big culprit is the placeAtMe function. New objects that are created in the world using placeAtMe never disappear. This is particularly a problem with mods that use invisible activators to cast spells at the player or enemies - you end up with lots of invisible activators which are no longer used but persist in the savegame indefinitely.
 
Items stored in inventories are another common culprit, especially with the negative item count bug mentioned below.
 
=== Avoid Using PlaceAtMe ===
 
It's very surprising that there's no mention of this issue whatsoever in the high-profile tutorial [[Casting_Spells_From_An_Activator|Casting Spells From An Activator]], which apparently gives very bad advice by giving script examples that will leave garbage in your savegame. 
 
Unfortunately, using ''disable'' doesn't remove the reference from your savegame. It's mentioned on the [[:Category:About_Modding_Etiquette|Etiquette page]], but this is a pretty weak warning:
 
  ... avoid using PlaceAtMe to create new copies of an object when you could simply use MoveTo on an existing object.
 
The [[PlaceAtMe|PlaceAtMe]] page has a good warning and the [[Talk:PlaceAtMe|Talk:PlaceAtMe]] page has some additional details, but these issues are not mentioned in the places where people really look for answers (i.e., tutorials), so I'm not sure how effective this is.
 
Quite a few mods still use this technique to repeatedly place hidden activators near the player when a MoveTo would work just as well without any negative side effects.
 
Perhaps the reason this issue hasn't been more widely discussed is that it's just not as easy to use MoveTo on a persistent object as it is to use PlaceAtMe/disable on a temporary reference. There's some discussion about this on the [[Talk:MoveTo|Talk:MoveTo]] page, but it's far from being concise or clear.
 
We really need a good tutorial on how to properly use MoveTo instead of PlaceAtMe/disable.
 
One of the main issues with MoveTo is that the collision shape doesn't always move with the object. Calling disable after moveTo, and then enable a frame later, may fix this problem.
 
The bloating caused by PlaceAtMe is not as severe as some of the other problems, but a single mod using it repeatedly can still add several megabytes to a savegame over time. If you have several mods that all do this, it starts to add up rather quickly.
 
=== Avoid Using DuplicateAllItems on a Companion ===
 
This seems to be by far the major offender in savegame bloating problems.
 
Some Companion Share mods have caused outrageous savegame bloating problems by using DuplicateAllItems excessively. The most common example is a mod using DuplicateAllItems (duplicating them to a duplicate of the NPC) in order to calculate and display encumbrance. If any of the NPC's items are scripted items, then they become permanently duplicated (and impossible to destroy) every time the DuplicateAllItems call is made. Since that call is made every frame while the companion's inventory screen is open, you get bloat very quickly (tens of megabytes in a few seconds).
 
Instead of duplicating items, you can use RemoveAllItems to transfer items to the companion and then back. That does fix the original bug (scripted items don't cause bloat anymore), but it still leaves the negative items bug with RemoveAllItems (see below).
 
=== Avoid Using RemoveAllItems on a Companion ===
 
This can also cause savegame bloating problems, but it is easier to avoid than the DuplicateAllItems issue.
 
Calling removeAllItems on an actor or container that has a negative count of one or more items will cause those items to be duplicated. Negative quantities mean the item is restocked when it's depleted.
 
You can avoid the problem by not giving the companion any items with a negative quantity.
 
So, you should avoid doing:
 
  NPC.RemoveAllItems NewContainer
 
then
 
  Newcontainer.RemoveAllItems NPC
 
on a NPC that has a negative item count. This doubles the items every time you do companion share. That means that the NPC will have 65536 items of a kind after 16 shares, 16777216 items after 24 shares and 4.2 bilion after 32 shares. Serious bloat!
 
== Don't Do These Things ==
 
Here's a list of more things to avoid:
 
* Don't ever hit the CS button "Recompile All"
* Don't run "Generate All" pathgrids or "Generate Entire World"
* Don't try to copy things from one ESP into another ESP unless the items come from Oblivion.esm
* Don't modify cells in Oblivion.esm in another master.
* Don't modify cells by accident. Cells not intentionally changed by your mod shouldn't have an asterisk next to them (use [http://www.elderscrolls.com/forums/index.php?showtopic=619318 TES4Gecko] to "clean" your mods before release)
* Don't use underscores in primary resource filenames. Underscores are reserved by the game for finding various file types, such as normal maps (xxx_n.dds), glow maps (xxx_g.dds), etc.
* Don't use full paths when creating retextured items. Texture paths need to be relative to the Data folder, not higher (not C:\Program Files\...)
 
== Tips ==
 
* Package mods so they can be unzipped in the Data folder without extra subdirectories.
* The README should be named ModName-README.txt so as not to overwrite existing READMEs from other mods.
* .7z (7-zip) is the currently preferred format for mod distribution [This can cause a debate, but new modders need to know about it.]
 
== Avoid Using Common IDs ==
 
Although this is less of a problem in Oblivion than it was in Morrowind, it's still good advice.
 
Do not create objects or variables with generic names, such as "SECRETPASSAGEDOOR". Use a unique identifier that you prepend/append to the name of the stuff you create, such as: "IchininSECRETPASSAGEDOOR".
 
This will make your mod less likely to collide with other mods when merging.
 
== Vanishing Landscape in Tamriel ==
 
This problem is also listed under Common Bugs because it can also be caused with new worldspaces whenever the current modindex for the plugin differs from the modindex of the plugin during creation in the CS. In this case, however, it happens when you try to use an ESM to alter the landscape for another master (such as Oblivion.esm), causing landscape in Tamriel to vanish (rather than in your plugin), for example.
 
The easy solution?. Never use a master to modify another master. The solution is explained in an old tutorial about [http://www.bethsoft.com/bgsforums/index.php?showtopic=603415 Creating Clean Masters]. Fortunately you can now do this automatically by using [[TES4Gecko]] to split a mod into ESM/ESP components.
 
== Game Settings ==
 
Game settings are not like global variables. If you use
<pre>set SomeVar to fiSomeGameSetting</pre>
your script will save, but won't run in game. You have to use the [[GetGameSetting]] function, as such:
<pre>set SomeVar to (GetGameSetting fiSomeGameSetting)</pre>
 
== Common MessageBox Mistakes ==
 
#The script has to run every frame to catch the button press. For persistent objects (activators, containers, tokens, etc.) this means the object needs to be loaded in memory (i.e., in the same cell as the player). For quests, this means you have to set fQuestDelayTime to a low number, like .001. For all of them, you also have to place the code inside a blocktype that runs every frame (i.e., [[GameMode]], [[MenuMode]])
#If you plan on having multiple menus displayed from one script, you need to use a governing variable to tell which menu you're currently displaying. For instance, make a [b]short MenuShowing[/b] variable and set it to 1 to display your first menu, and 2 to display the second menu.
#If any part of your code after the button catch (that is, after [b]if (Button > -1)[/b]) requires more than one frame to process, and you've set up your code to set the button variable every frame, such as:
<pre>...
if (MenuShowing == -1)
  MessageBox ...
  set MenuShowing to 1
elseif (MenuShowing == 1)
  set Button to GetButtonPressed
  if (Button > -1)
if (Button == 0)
...</pre>
then you need to change it to catch the button only when the player's decision hasn't been caught yet [i]and[/i] make sure to reset Button after displaying the menu:
<pre>...
if (MenuShowing == -1)
  MessageBox ...
  set MenuShowing to 1
  set Button to GetButtonPressed
elseif (MenuShowing == 1)
  if (Button == -1)
set Button to GetButtonPressed
return
  elseif (Button == 0)
...</pre>
#If you're using a scripted magic effect for your messagebox, make sure to make it last a couple of seconds (at least). It is ''strongly'' advised to use another method. You can have the scripted magic effect start up a quest, or an activator, or add a token to the player and run the messagebox from those.
 
= Common Bugs =
 
These are annoying problems with the CS and game engine.
 
== Vanishing Landscape in a New Worldspace ==
 
This general problem is also listed under Common Mistakes because it can also be caused by using an ESM to alter the landscape for another master. In this case, however, it occurs whenever the current modindex for the plugin differs from the modindex of the plugin during creation in the CS (because the end-user's load-order will rarely be the same as the load-order during creation). This usually means that the only way to get the plugin to work in-game is to make it the very first thing that loads after Oblivion.esm, which is a terrible limitation.
 
[[TES4Gecko]] now includes a '''Move Worldspaces''' function to help deal with this issue by "injecting" new worlspaces into the 00 modindex.
 
See [http://www.elderscrolls.com/forums/index.php?showtopic=616587 this ESF thread] for the discussions that led to this solution.
 
== Remove Item ==
 
The 'remove item' function doesn't work properly with more than one item sometimes. The in-game message (produced by the game) is correct, but the number of items the player loses is not. For example, you may get the message '5 ogre teeth removed', but only 3 were actually removed from your inventory. This happens randomly, no matter which item you remove or how many 'remove item' functions (or other functions) you use in a single frame.
 
== Oblivion Realm Resets ==
 
Whenever the player closes an Oblivion gate, the entire Oblivion cell and everything inside of it is reset. This includes inventories of containers and NPCs, and for NPCs their spell list and location. It may also be possible that variables on world objects (containers, NPCs, activators, etc.) are also reset. These two threads have more information and tips to avoid the problem:
[http://www.bethsoft.com/bgsforums/index.php?showtopic=689034]
[http://www.bethsoft.com/bgsforums/index.php?showtopic=675492]
 
See post 96 in the Gotchas! thread in the CS section of The Elder Scrolls Forum for links to threads containing more information and tips to avoid this problem. (sorry I can't just put in the links, something's not working quite right)
 
== Adding Multiple Items with the Same Script ==
 
There are some oddities (well, the right words for it I won't use here) when you
#add two or more items
#with the same script
#to the same container
#at or about the same time.
<br>This seems to happen for several situations:
*You add an item, which in turn adds another item
**So I would guess it also includes using [[AddItem]] for two separate items
*An item that runs when the player adds them to a container, or the player takes them from a container
**For example, if you have 2 of an item in a container (same base object), and the player double-clicks them, thus adding one after the other, you'll hit this bug
**But using 'AddItem SomeItem 2' seems to work without hitting the bug
[http://www.bethsoft.com/bgsforums/index.php?s=&showtopic=628331&view=findpost&p=10126100|Here are some more examples]
<br>What exactly is going is anyone's guess, and the problems that can occur are very, very bizarre making them hard to trace. Also, the bug seems to be intermittent, sometimes working and sometimes not, and some scripts don't seem to run into the problem. The a few points to take away from this:
*Adding two or more items with the same script can produce weird results
*If you're adding multiple items and getting weird results, put a frame or two between when you add one and when you add the other
**In the right situation, you can avoid the problem by changing the [[Scriptname]] of the items
*If there is a possibility of the player running into this situation, be sure to test for it
 
== Activating an object every frame ==
 
This didn't cause a CTD with me, but as it causes unpredictable results there is a chance CTD's might occur.
 
When you have a script that constantly activates a certain object (in my case, to wait for a result that was published inside that object and could be retrieved in this way), other scripts might become unresponsive.
I had several onadd blocks in other scripts that weren't executing anymore.
 
If you have to do this, build in a timer.
 
= Debugging =
 
When something just isn't working right, look here for possible causes.
 
== Comma Instead of Period ==
 
This can cause severe headaches for the scripter: The compiler will accept a comma in place of a period in reference syntax, but the script will silently fail in the game when the line is encountered.
 
  player.modAV health 200 <- Fine
  player,modAV health 200 <- Suddenly your script is no longer running and you're wondering why
 
Easy to miss when you're looking for logic errors.
 
== Numerals ==
 
Don't start an ID or variable with a numeral.
 
  short 5forFighting; BAD
  long benFolds5; GOOD!
  myGuy.moveTo 0marker; BAD
 
== Mismatched If/Endif ==
 
The compiler will ignore extra [[endif|endifs]] when you save your script, but they can cause the script to stop running when encountered during gameplay. Make sure each [[if]] in your script is paired with exactly one [[endif]]:
<pre>if ( something == happened )
  do something
endif ; GOOD
endif ; BAD, extra endif may cause errors in the game</pre>
The best way to avoid this problem is to use proper indentation of if-blocks.
 
== Quest Topic Scripts ==
 
The Scripting section in the Quest/Topic editor seems to be for very generic scripting like setting global variables and doing things like setstage. Be aware that while some things may compile clean here and seem perfectly fine, they just don't work in-game.
 
== Getself != player ==
 
Be careful if you use:
 
  Getself != player
 
When called in a scripteffect spell, the statement sometimes evaluates true for the player. The easiest solution is to add another condition to double-check it, such as:
 
  getdistance player >0
 
However, [[getDistance]] is unreliable if the player is swimming.
The best solution is to use:
 
  ref refVar
  set refVar to getSelf
  if ( refVar.getIsReference player == 0 )
 
= Performance Problems =
This section is intended as a place to list script performance problems and tips.
 
== Gamemode Scripts ==
Avoid using gamemode scripts wherever possible. Use quest scripts instead.
 
== CPU-hungry functions ==
There are a few CPU-hungry functions to watch out for and avoid at all costs:
GetSecondsPassed
GetDistance
 
= Obscure Problems =
 
These issues don't occur very often, and we don't even really know what causes them, but they hurt nonetheless.
 
== Pathgrid CTDs ==
 
Does anyone really know why the pathgrid CTDs happen? The last thread about it I remember didn't find a solution.
 
This is an older problem that plagued both UL and OOO for a while. Basically, [http://www.elderscrolls.com/forums/index.php?showtopic=495607 changing pathgrids is risky] and requires a lot of testing to avoid CTD issues. I didn't find any surefire solutions for this either. Does anyone know if this topic has been written about in any more detail than the introductory [[Path_Grid_Generation|Path Grid Generation]] article and [[A_beginner%27s_guide%2C_lesson_3_-_The_external_world#Path_Grids_.28simple.29 |Path Grids (simple)]]?
 
== Black Screen Bug ==
 
This is the [http://www.elderscrolls.com/forums/index.php?showtopic=517690 Infamous Nvidia + HDR Black Screen Bug].
 
This bug can usually be fixed by the mod-creator. It is usually caused by problems in a custom mesh. This can happen if the mesh creator forgot to assign a valid material to part of the mesh. It can also happen if you have an opaque texture assigned to a transparent portion of your mesh. It can even sometimes be caused by a standard shader like the GhostEffect.  
 
It can also usually be solved by updating the tangent space of certain mesh nodes in a .nif file. NifSkope has a spell to do this.
 
Once you've narrowed down which .nif is causing the problem, simply open it in NifSkope, right-click each NiTriStrips/NiTriShape node and select ''Mesh -> Update Tangent Space''. This works most of the time.
 
= Related Articles =
 
= Helpful Programs =
[[TES4Edit]]<br>
[[Wrye Bash]]<br>
[[TES4Gecko]]<br>

Latest revision as of 08:23, 23 January 2010

This is a collection of articles on troubleshooting TES IV problems -- gotchas, common mistakes, CS bugs, etc. The basic ideas and topics were originally discussed in this ESF thread. Continued reports and peer review has moved to a new thread now that the original is almost full.

The original list started back in February 2007 has grown to the point that it needed to be split into separate articles. These articles list of some common mistakes and their effects on players and/or the CS. Please suggest more ideas if you can.



  • Common Bugs - These are annoying problems with the CS and game engine.
  • Common Mistakes - These are things that all mod-creators should know not to do.
  • Crashes - Common problems that may cause game crashes (CTDs). See also Crash Prevention.
  • CS Crashes - Common actions that make the CS crash.
  • Debugging - When something just isn't working right, look here for possible causes and ways to track down the bug.
  • Performance Problems - This section is intended as a place to list performance problems and tips, especially those related to scripting.
  • Fixing the AddTopic Bug - Critical dialog bug fix.
  • Obscure Bugs - These issues don't occur very often, and we don't even really know what causes them, but they hurt nonetheless.
  • Helpful Programs - These programs can help a lot when troubleshooting.
  • Understanding Mod Conflict Reports - An explanation of different mod conflicts.

Subcategories

This category has only the following subcategory.

S

Pages in category "Troubleshooting"

The following 11 pages are in this category, out of 11 total.

C

D

F

H

O

P

U

Retrieved from "https://cs.uesp.net/w/index.php?title=Category:Troubleshooting&oldid=3794"