Difference between revisions of "Causes of CTDs"
→Worldspace Navmeshes
imported>Odessa |
imported>Grigoriprime |
||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 4: | Line 4: | ||
===Debugging=== | ===Debugging=== | ||
The console command [[SetConsoleOuputFile|SCOF]] can be used in game, or via a script with [[Con_SCOF]] to write all console output to a text file in the fallout game directory. This is very useful as it allows you trace output to the point of CTD back in Windows. | The console command [[SetConsoleOuputFile|SCOF]] can be used in game, or via a script with [[Con_SCOF]] to write all console output to a text file in the fallout game directory. This is very useful as it allows you to trace output to the point of CTD back in Windows. | ||
<pre> | <pre> | ||
; within game console, type: | ; within game console, type: | ||
| Line 37: | Line 37: | ||
FirstRef.MarkForDelete | FirstRef.MarkForDelete | ||
</pre> | </pre> | ||
Note also that [[RemoveMe]] and [[Dispel]] are not instant, and a script may run for several frames after its parent object/spell was removed, with unpredictable behavior. To protect against this, you can use: | |||
<pre> | |||
int Completed | |||
Begin GameMode | |||
if Completed | |||
return | |||
endif | |||
; * do something | |||
set Completed to 1 | |||
RemoveMe | |||
End | |||
</pre> | |||
===BuildRef might not return what you expect=== | |||
The [[BuildRef]] function allows you to reference assets of an external mod without making that mod a master to your own plugin. However, it can potentially return an invalid or unexpected reference, and crash the game if you do not bother to check for this. See the [[BuildRef]] function article for full details. | |||
===Unexpected returns during immediate game start up=== | |||
It has been observed on a few occasions where scripts running in early game startup, or sometimes just on their first scan return <NULL> for an actor. With all the DLC's booting up, I've experienced such failures up to 10 seconds after gamestart, things like a female player returning zero for [[GetIsSex]] Female. | |||
===Invalid string formatting=== | ===Invalid string formatting=== | ||
Using invalid format specifiers or mismatched number of arguments to format may crash the game (and at best the script), for example: | Using invalid [[String Formatting|format specifiers]] or mismatched number of arguments to format may crash the game (and at best the script), for example: | ||
<pre> | <pre> | ||
DebugPrint "GunScript %n: Shooting %2.0 bullets" rActor iBullets | DebugPrint "GunScript %n: Shooting %2.0 bullets" rActor iBullets | ||
; you meant "%2.0f" but missed the f | ; you meant "%2.0f" but missed the f | ||
</pre> | </pre> | ||
If using NVSE, it is safer to use string concatanation and the [[ToString]] function where possible, instead of formatting. See [[String Variable]] for more information. | |||
===Invalid And/Or syntax for conditions=== | ===Invalid And/Or syntax for conditions=== | ||
| Line 51: | Line 73: | ||
; above ; | ; above ; | ||
</pre> | </pre> | ||
EDIT (09/01/15): | |||
This comes from my personal experience. | |||
Sometimes absurd wrong syntax compile (so never fully trust 100% the compiler or PU). But mainly, some of them don't CTD in game and silently break the script execution, making the debug pretty hard. | |||
Here an example, a mistake I did more than once because of copy/paste: | |||
if (something) || (something else) || (some other thing) || | |||
(I left an extra || at the end) - This line was compiling, but it wasn't CTD in game, it was interrupting the rest of the script from that line to the end. | |||
I use vanilla + 4Gb + NVSE + PU, so it's not like NVAC preventing CTD or whatever. | |||
Also I noticed how some script mistakes CTD in FO3, while don't CTD in NV but they interrupt the script execution. And not because of FOSE / NVSE, I'm talking about vanilla script. | |||
===NPC outfit scripts that modify inventory=== | ===NPC outfit scripts that modify inventory=== | ||
| Line 60: | Line 94: | ||
===Nested function calls=== | ===Nested function calls=== | ||
If using the [[Script Compiler Override]], it is possible to nest multiple function calls on a single line, rather than use | If using the [[Script Compiler Override]], it is possible to nest multiple function calls on a single line, rather than use intermediary variables. Sometimes this causes a CTD, which is avoidable by using multiple lines. | ||
===Single line And/Or conditions=== | ===Single line And/Or conditions=== | ||
| Line 68: | Line 102: | ||
[[Category:Debugging]] | [[Category:Debugging]] | ||
===Animations=== | |||
(ADDED 09/01/15) | |||
This is not about scripting, but still a cause of CTD, I would say it's common among users. | |||
When a .kf (animation file) calls a movement on a bone which is not present in the skeleton, this usually leads to a CTD. However you don't need to have a body /armor rigged on that bone, to avoid it, only have the right skeleton. | |||
This is the reason why in many mods the modders want you to install a compatibility skeleton, because it has all the possible bones used among different mods. | |||
===Animations - Textdatas=== | |||
Curious to notice how an empty (wrong) textdata could lead to a GECK CTD when it's previewed on the render window, but it will be ignored in game and will work fine. | |||
==Worldspace Navmeshes== | |||
Having uncaught errors in a navmesh that is in an exterior location can cause CTD on load of any save. This effect can be delayed by up to nearly a minute in some cases. It is also possible for this to happen if you manipulated an error free navmesh and forgot to finalize it. | |||
This may be due to bad navmesh info and can sometimes be fixed by deleting the navmesh infos for your exteriors in FO3Edit and letting GECK re generate them. It is unknown if this creates other issues but it has been observed to resolve CTD on load without creating any additional GECK errors and does not require physically recreating your actual navmesh. | |||