Debugging
We all make errors - yes, even me. This page will give some suggests as to how to resolve them.
Most errors manifest with an error message, either on the page or in the console (or both), therefore it is important to have the console open whilst you test your game.
Press F12 (or Crtl-Shft-I or Crtl-Shft-J or via a menu) whilst in your browser to open the "Developer Tools". There will be various tabs; select the second, "Console" (if you do not see the tabs, try dragging the divider to make the window larger). Any errors in your JavaScript code will appear here - as well as any messages you send there.
If Quest hits an error that has been anticipated, it will produce an error message. This will usually tell you exactly what is wrong where.
For example, when you load the page (and settings.debug is true), Quest will check through every exit and give an error message if one is not a proper Exit object or if it goes to an unknown room.
An exception occurs when the browser cannot cope with the code. The browser will put the details into the console.
This will be a chain of lines of code, a "stack trace", so the top one is probably the only one you need to look at; those lower down will be due to knock-on effects of the first one - useful for determine where Quest was, but not where the error is. That said, if the top one mentions "jquery", ignore it and look a the one below.
The error message should say the line number and file, and is usually right about where the error is, even if the cause is not so obvious. In the top image, the error is in the file lang-en.js, line 252. In the lower image, ignore the JQuery stuff, and look below it. Again, the error is in lang-en.js, this time line 821.
If you cannot see the error there, look further down the list. In particular, see if any code you have recently changed is in the list. That is probably where the issue is.
You can also put code in your files that will print messages to the console. This can be very helpful when trying to work out the logic flow through your game, and checking if it is actually using the code you think it is.
console.log("This is my string")
console.log(this)
If you send an object or array, the entire object or array will be there and you can check every value if you expand it (note that the values may update in the console when they change in game). It will also report the file and line number (useful when you want to remove it and cannot remember where you put it!).
You can also type into the console. Want to know the state of the "torch" object? Just type w.torch (and press enter twice) and all the attributes will be listed, and you can check they are what you expect them to be.
If settings.debug is true, some extra commands will be available. Set it to false before you release the game to disable them.
Type WT <name> to run a walk-through.
Walk-throughs are simply arrays of commands, all inside a dictionary called walkthroughs, and are usually best placed in code.js. This example creates a single walk-through called "one".
const walkthroughs = {
one:[
"n", "w", "n",
]
}
More here.
Type INSPECT <object> to see all the details about the given object (in the console window). Use INSPECT2 <object> with the object name (useful for rooms!).
Use CMD <command> to see details for a specific command.
Type CMDS for a full list of commands, together with the regular expression. If useable by NPCs, that will also be noted. Note that sometimes multiple commands are used to handle different word orders (eg PUT ON HAT and PUT HAT ON); by convention, the second form has the same name but with a 2 suffix, the third has a 3 suffix, etc. (but the first has no number). When listed, these will appear as alternative regular expression.
Type TEST to run unit tests (or press the 0 on the number pad with Num Lock off). Unit testing is discussed here.
The PARSER command toggles debugging information for the parser. When turned on, you will see what commands the parser found as potential matches and what objects, and how it scores them when decided which to use.