Difference between revisions of "Crashes"
m
→Activating a Container (including NPC): Typo correction
imported>Dev akm (→MessageBox on a Terminating Script: attached to MyItem) |
imported>Syscrusher m (→Activating a Container (including NPC): Typo correction) |
||
| (25 intermediate revisions by 10 users not shown) | |||
| Line 1: | Line 1: | ||
= | __TOC__ | ||
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 37: | Line 55: | ||
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. | 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. | ||
== SetLevel Bow Bug == | |||
Strangely this bug is mostly unknown (and the Bow Reach doesn't have to be zero to produce a CTD). It causes almost always a CTD if the player uses SetLevel on an actor that has a bow equipped or drawn and is inside the players cell (the CTD occurs as soon as the player visits or is in the cell where the actor was forced to reequip his bow due to SetLevel). | |||
To avoid the CTD the actor has to be moved to a never-to-be-visited-cell to do SetLevel and then move the actor back to its origin. That can be done in a single frame. | |||
== Activate Self == | == Activate Self == | ||
| Line 52: | 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 | <pre>begin onActivate | ||
... | ... | ||
end | end | ||
| Line 59: | 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 | #[[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]] | #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 93: | Line 137: | ||
If PCVampire | If PCVampire | ||
MessageBox "You can't use this item while you're a vampire." | MessageBox "You can't use this item while you're a vampire." | ||
Player.UnEquip | Player.UnEquip MyItem | ||
Player.Drop | Player.Drop MyItem 1 | ||
EndIf | EndIf | ||
end | end | ||
| Line 104: | Line 148: | ||
If PCVampire | If PCVampire | ||
Message "You can't use this item while you're a vampire." | Message "You can't use this item while you're a vampire." | ||
Player.UnEquip | Player.UnEquip MyItem | ||
Player.Drop | Player.Drop MyItem 1 | ||
EndIf | EndIf | ||
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]] | ||