Difference between revisions of "Crashes"
m
→Activating a Container (including NPC): Typo correction
imported>Dev akm |
imported>Syscrusher m (→Activating a Container (including NPC): Typo correction) |
||
(12 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
__TOC__ | __TOC__ | ||
Common problems that may cause crashes in-game. | 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 == | == Deleted References == | ||
Line 6: | Line 14: | ||
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. | 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 | 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 | 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 [http://www.bethsoft.com/bgsforums/index.php?s=&showtopic=837706&view=findpost&p=12355637 here] | 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 68: | 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 75: | 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]], direct activation, or dialog script 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) |