Difference between revisions of "Crashes"

3,020 bytes added ,  11:16, 21 September 2014
m
imported>Scanner
m (added SetLevel Bow Bug)
imported>Syscrusher
 
(23 intermediate revisions by 9 users not shown)
Line 1: Line 1:
= Troubleshooting Crashes (CTDs) =
__TOC__
Common problems that may cause crashes.
Common problems that may cause crashes in-game.
 
== Dueling Inventory Changes ==
 
Using either [[RemoveMe]] or [[RemoveItem]] on an object in inventory immediately after adding the object will cause random crashes. To avoid this, delay the removal by several frames with a counter.
 
There is mounting evidence -- but no hard proof yet -- that multiple, frequent inventory changes may cause crashes if they happen too close together. For example, if you have multiple mods that rely heavily on adding and removing tokens from the player or nearby actors, you may encounter random crashes when one of these mods removes a token in the same frame that another mod adds a token. In theory, the chances of this happening would increase as the frame rate decreases.
 
There has been some suggestion that this problem might actually be related to another bug: [[Common_Bugs#Adding_Multiple_Items_with_the_Same_Script|Adding Multiple Items with the Same Script]].
 
== Deleted References ==
 
If you delete any vanilla (Oblivion.esm) refs and another mod loads after yours that does anything with those refs that you deleted, the player will very likely get a crash on exit and/or a crash when reloading with a savegame made in another cell than the one he's currently in.
 
The solution is to never delete any vanilla (Oblivion.esm) refs. Move them and/or set them to be [[Reference#Reference Data Flags|Initially Disabled]] instead. This won't work for an object with Parent References, so be sure to remove the Parent Reference from the object.
 
Shoving an object out of view by -30,000 Z units (arbitrary value) will put it far enough away that the game won't render it anyway.
 
See [[Undelete_References|Undelete References]] for some tips about how to deal with this. See [http://www.bethsoft.com/bgsforums/index.php?s=&showtopic=837706&view=findpost&p=12355637 here] and [http://www.bethsoft.com/bgsforums/index.php?showtopic=850987 here] for more details.


== Nested If Versus And ==
== Nested If Versus And ==
Line 58: Line 76:
</pre>
</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:
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
<pre>begin onActivate
...
...
end
end
Line 65: Line 83:
Activate player, 1
Activate player, 1
end</pre>
end</pre>
It is also usually unwise to self-activate an object from within its [[OnActivate]] block with the [[OnActivate]] bit true, as this almost always leads to infinite recursion and a crash.
'''Wrong:'''
<pre>begin OnActivate
...
Activate player, 1
end</pre>
'''Right:'''
<pre>begin OnActivate
...
Activate player, 0
end</pre>
The default on that bit is zero, but it is a good practice to explicitly specify it as a reminder to yourself.
This situation arises (for example) if you have a container with a script that does something when activated but then lets the player or NPC go ahead and open the container in the usual way. The [[Activate]] call to actually open the container does not need to recurse into your OnActivate script.


== Activating a Container (including NPC) ==
== Activating a Container (including NPC) ==


If you meet all of these conditions:
If you meet all of these conditions:
#[[Activate]] a [[Container]], so that you run it's [[OnActivate]] block, that is:
#[[Activate]] a [[Container]], so that you run its [[OnActivate]] block, that is:
<pre>YourContainer.Activate player, 1</pre>
<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)
#from an [[Object scripts|Object Script]] (and maybe a [[Magic effect scripts|Magic Effect Script]], but a [[Quest scripts|Quest Script]], direct activation, or dialog script would be safe)
#when a scripted item is in it (even a [[Scriptname]] declaration is too much)
#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:
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:
Line 115: Line 153:


Which doesn't cause a CTD.
Which doesn't cause a CTD.
== Edits to Tamriel cell (-47,-7) ==
Any change to Tamriel cell AnvilMainEntrance (-47,-7) will not cause crashes in-game, but instead will cause Oblivion to crash on exit from the main menu. There may be other cells that also do this. The presence of the CELL record is enough; even if all the refs. are removed the crash will still occur if the CELL record is still present.


[[Category:Troubleshooting]]
[[Category:Troubleshooting]]
Anonymous user