[This page is outdated! See instead the PTR wiki: https://wiki.project-tamriel.com/wiki/Construction_Set_Error_Check_Results]
The Construction Set's Error Check Results is a button at the bottom right of the dialogue window.
Unlike normal scripts, the scripts in dialogue results are not precompiled until they're triggered in the game, and by default they don't get error-checked by the CS. Error Check Results makes the CS simulate the scripts in all dialogue results and progressively give reports in pop-up windows as well as in Warnings.txt. It is a valuable tool for detecting simple syntax errors or ID errors, with two drawbacks:
- YOU MUST NEVER SAVE YOUR FILE after using Error Check Results. In the process of simulating dialogue results, it applies all changes to global variables, at the minimum modifying their default values.
- It will always report a number of false positives, detailed below.
False positives
These are some cases where errors reported by Error Check Results will not give any actual errors in the game:
References that do not exist yet
Error Check Results reports errors when there is a reference to an object instance and no such instance exists. So far so good.
In dialogue results however, it is permissible to refer to objets which do not yet exist anywhere in the loaded files' cell records, but which, by the time the dialogue is run, will necessarily have been created in the game or loaded from another plugin. (This is in contrast to compiled scripts, which can only target an explicit ID if an instance of that ID has been placed in the CS, and only the first instance that existed). Error Check Results will, logically enough, still report errors in that case -- example from Tamriel_Data's Orgnum Coffer, whose dialogue lines only become accessible once the coffer is dropped on the ground in the game: "Line 2 function reference object "T_Com_UNI_KingOrgnumCoffer_01" not found". Note that unlike other reports this one won't copy the corresponding dialogue line's text in warnings.
References that are not persistent
Again, targetting non-persistent references (instances of objects without 'references persist' ticked) seems permissible for dialogue results where it wouldn't be for compiled scripts. This results in a simple warning that Object '...' is not persistent. Its presence is not guaranteed in game.
Implicit local variable inside a condition
Dialogue results implicitly target whoever speaks the line if no explicit target is specified. When a local variable on the speaker is implicitly checked inside a condition -- for instance the variable "short control" in the condition "If ( control == 1 )", Error Check Results will report Script Error: EXPRESSION likely followed by Right eval or Left eval, as it apparently can't see that the speaker possesses the local variable, even in dialogue lines that specify a Speaker ID condition.
The error is in that case incorrect -- the script will work. The false positive report can be prevented by giving the variable an explicit target, in this example "If ( "SpeakerID".control == 1 )".
Implicit local variable inside an operation
Similar to the above, with an example in the Tribunal topic "selling off": the local variable "rats" on the right side of the operation "set rats to rats + 1". Error Check Results will report Expression Error: SYNTAX and Set expression returned an error.
Similarly, in simple cases the false positive report could be prevented by giving the variable an explicit target, in this example "set "rerlas mon".rats to ( "rerlas mon".rats + 1 )". When the operation involves both local variables and global variables, adding explicit references can't prevent the error report.
Local and Global variables inside an operation or condition
Similar to the above two cases but when global variables are also involved, Error Check Results will report Expression Error: SYNTAX and Set expression returned an error.
Unlike the previous two cases, such error reports can not be prevented by simple edits.
Local variables and Script functions, or Script functions inside an operation
Similar to the above two cases but when certain script functions are also involved, Error Check Results will report Expression Error: SYNTAX and Set expression returned an error.
Where several GetDeadCount are summed inside an explicit local variable, Error Check Results reports Expression Error: SYNTAX and Set expression returned an error.
Where several GetJournalIndex checks are summed inside a local variable, Error Check Results reports Expression Error: BADOBJECTPOINTER and Set expression returned an error.
(More cases may exist when functions are compared or summed inside a condition?)
These error reports can not be prevented by simple edits.
Known false positives in TR files
When using Error Check Results on your quest/dialogue claim (remember again: YOU MUST NEVER SAVE YOUR FILE after using it), it is usually enough to disregard any errors that don't mention anything you're working on.
When using it to error-check the entire TR files, it is useful to know which are known false positives. To that end, copied below is the state of Error Check Results including disregarded errors from all the original game files, TR_Mainland.esp, and Tamriel_Data.esm
-- updated as of June 2021: (errors in red are not false positives but current actual errors from Data)