WIP

PLAYTESTING

Vanilla engine: When starting the game, don't click "Cancel"/"Yes to all" to skip warnings and errors - if you do, error messages will never display later on in the game.
OpenMW: If on Linux or mac, run openmw.exe from terminal and keep an eye on the output while running the game. If on Windows, test only with vanilla engine you can now keep it open too, just start the game from command line, or just use a .bat file as your shortcut (write "openmw.exe" in a text file, rename extention to .bat, put in openmw folder).

Playtest with a new character who doesn't know any topics.
Playtest with an old character who knows many topics, has a high level, reputation, etc.
Create new saves for each quest state.

Start:
- Is it clear that you're taking on a quest? If you didn't want to do that, is it stuck in your Journal list?
- If not, does it have an option to turn it down? Does it need one?
- Can you come back and take the quest after turning it down?
- Can you abandon the quest? Do you need to?
(doesn't apply to faction quests started from "duties"/"chores"/...)

Whenever the situation changes (usually comes with a journal update):
- Check the new journal entry
- Talk to every NPC involved on every topic associated with the quest. Does their dialogue make sense?
- If the change came from a NPC greeting, reload and contract a disease (console: Player->AddSpell, "rotbone"). Does it still work?

Items/gold:
- What if you don't have enough? Does it still work if you have have more than the exact amount of items?
- Are they taken from your inventory?

Taking an item triggers an event:
- Does the same thing happen if you pick it up while the inventory is open?

NPC AI:
- NPC walks somewhere. Does this break if you get near them, stand in their way, rest, change cells?
- NPCs attack you or fight each other. What happens if you use Calm/Command spells? If you talk to them, what happens? Does it need to be otherwise?

End:
- If your actions make it impossible to complete the quest, does it properly fail?
- If completed, is the Journal entry closed?

Betacomments:

DEBUGGING AND REVIEW

When starting the game, don't click "Cancel"/"Yes to all" to skip warnings and errors - if you do, error messages will never display later on in the game.

Always begin by testing ingame and "on foot" first, without the console, and without unnaturally fast running speed. You need to check that any directions can be followed, to see what happens when you enter cells, what else is on the way, etc.
Afterwards you can use the console command coc "Cell Name" (centeroncell) to teleport. If you set up a savegame in a convenient nearby location, do so before adding your plugin to the game (when testing changes to scripts, you'll sometimes need to use a clean save in which these scripts weren't already running). If you need to test many quest paths in many locations, you can set up a save with various teleportation targets using this mod (MWSE/MGE XE only) or this mod (current TR_Mainland.esm cells only), or make your own testing script.

Other testing tools:
- This plugin skips the introduction on "New Game". Edit it to start where you want, add items...
- alternatively, edit "Starting Cell=" in Morrowind.ini
- Another quickstart test plugin
- Another another quickstart test plugin
- A more extensive chargen mod
- Some saved games (remove master files) on Modding History

For NPC claims it's a good idea to use scripts that teach the player all existing topics when testing:
- ...

You can add addtopic "Greeting 0", addtopic "Greeting 1", etc. to 9 in your test plugins, or in the console. This will let you see other available greetings in the topic list. For example when you playtest with a disease and find that an important greeting is blocked by Greeting 4 because it's lower, in Greeting 5 instead of 1 or 0 (a common error), you can use the "Greeting 5" topic to save time and keep testing.

Other useful console commands:

Debugging a script: if you can't immediately identify a bug, add message displays at each stage of the script (MessageBox, "Hello world") until you can pinpoint which part doesn't work. Check the syntax and quirks of any function involved in MSFD; read also its Troubleshooting section for possible meanings of error messages. Advanced scripters: if all else fails and nothing seems wrong with the code, cut the whole script, paste it into a simple text editor (notepad), delete the troublesome line(s) and re-type them by hand, then copy-paste back and recompile.
 

REVIEWING

Go through every single thing added by the plugin in the Construction Set.
You can open it in TESAME on the side to have a list of what it adds, or dump its contents with tes3cmd, or any other method you like, but if you haven't checked every dialogue line, dialogue result, and script, you haven't reviewed the quest.
Quick navigation: in the topics list, press the first letter(s) of the topic name to jump ahead. When in a Greeting or topic, press the * key to jump straight to the first line of the active plugin. Follow * with the spacebar and the first letters of a specific line to jump to that line. Due to the time the CS takes to display everything when you land on a dialogue entry with many conditions, you may have to wait and/or start pressing keys again from the beginning.

Start by opening its Journal entry. You can open several dialogue windows (Character->Dialogue) and keep one open with the Journal stages on display.

You can use the CS Error Check Results to scan for issues in dialogue results, but never save the plugin after doing so (it processes changes to global variables and records them as default values). Error Check Results will wrongly report errors for any local variables inside operations ( + - * ...) or IF blocks if they're implicit (without an explicit speaker target, as in "speaker.localvariable").

Don't rely on the CS script compiler to know that a script works. It will not always warn you about syntax, wrong IDs, or other errors. Tools like MWEdit or others can check your scripts for some syntax errors.

The CS search function (Edit->Find Text) is very helpful, but if you have extremely long scripts, don't rely on it to find portions of text or code in them. It won't.

Cleaning: See warnings about deleting dialogue in TESAME.
Automatic cleaning by tes3cmd will remove vanilla junk cells (those automatically dirtied by the CS) and unmodified objects that exist in the plugin's master files only. To check whether a big file is modifying items in a master (the original Morrowind files) or editing objects defined in another ESP (TR_Mainland or section files), use the tes3cmd function "common".
To avoid merge issues, clean not only dirtied lines from vanilla but also those from other TR files the quest file depends on. Don't keep dialog placeholders dirty (BEGIN TR...), clean them.

Check naming conventions (claims used to generate quest numbers, now add what instead to denote which quest the object belongs to?):

 
tes3cmd commands (as a .bat file) detecting common issues with IDs in "TR_plugin.ESP":

Standard typography:
- dashes are en-dashes represented by two hyphens -- and have spaces around them
- ellipses are not spaced, ... instead of . . .
- apostrophes and quotes are straight, " instead of  “ , ' instead of ` (tes3cmd: to detect the latter use command line and not a .bat file, or see nonstandard characters in commands above)
- when there is both description and dialogue in player choices: [Description in brackets]

 
Good practices:
- Add Addtopic in the results of dialogue that should link topics the first time, as backup. Use unique topics when possible. If reusing vanilla or older quest topics, check that knowledge of the topic doesn't shortcut other quests.
- Make sure journal entries link the topics the player will need to use or look up for details (whichever topics originally gave the extended dialogue version of what the journal entry says)
- Add ClearInfoActor on dialogue that shouldn't get recorded in the journal's topic index, like any generic dialogue that doesn't give the player any information in a quest topic (not generic topics rumors).
- Add nolore to any generic dialogue. Make sure all dialogue entries have specific conditions (ID, cell or local variable). If the only condition is "choice", try to add more proper conditions anyway, otherwise the CS will display that topic and choices when filtering for any single NPC. If an entry with only cell conditions needs to be common to nolore and not-nolore NPCs, consider adding a TR_Map condition.
- Follow scripting good practices in dialogue results too, keeping consistent spacing around parentheses. Don't keep any spaces around " -> " (error if target was in quotes).
- In dialogue results, if implicit local variables are in an operation ( + ...) or in a IF block, add an explicit target whenever possible (with syntax set "NPCID".localvariable to ... or if ( "NPCID".localvariable == ... ) ) to reduce the amount of wrong reports from CS error check
- If rumors give journal entries, make those "Finish" and let the next journal entries from the questgiver "Restart" the quests.
- Whenever NPC AI is given a task, SetHello 0 until it's completed so it doesn't get interrupted by hello voices.
- If teleportation is disabled by something, always start a global script to enable it back in case a scripted item (Barilzar's Mazed Band...) was used to exit the cell. Update the global T_Glb_GetTeleportingDisabled for easy compatibility.
- Script efficiency: put anything you can under single-frame checks (CellChanged, OnDeath...). Put any slow functions (GetDeadCount, GetDetected, GetLOS) under a timer. Having many lines under a check is not as good as using "Return" at the top of the script under the opposite check. For scripts that run in already slow exteriors, the first few lines should include "return" if quest conditions haven't started, and the next few lines "return" after quest conditions are finished.
- A script that breaks under any legitimate use of ingame mechanics is not acceptable. Assume that stable MCP bugfixes apply, but not features (anything that isn't a default bugfix). MWSE scripting isn't used but you may want to take distant land into account. For extra points test in OpenMW and make sure any advanced scripting works in it too.

Always playtest the file ingame again after any changes made in review!

WIP