Difference between revisions of "Category:Troubleshooting"

3,348 bytes removed ,  13:48, 14 September 2007
→‎CTD (Crashes): moved to it's own page
imported>Dev akm
(→‎Remove Item: ingredient sorters)
imported>Dev akm
(→‎CTD (Crashes): moved to it's own page)
Line 9: Line 9:
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)
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) =


== Nested If Versus And ==
Don't assume that if-tests stop at the first non hit. For example,
  if (myref.isactor and myref.isincombat)
could cause a crash because myref.isincombat is always checked, even if myref isn't an actor. Use a nested IF statement instead.
== 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 =
= Common Mistakes =
Anonymous user