Detecting and fixing typos
Say you mistype a command, for example you type newCanva instead of newCanvas:
[js highlight=11]newTrial(
newText(“The fish swim in a tank which is perfectly round”)
.print()
,
newImage(“two”, “2fishRoundTank.png”)
.size(200,200)
,
newImage(“one”, “1fishSquareTank.png”)
.size(200,200)
,
newCanva(450,200)
.add( 0 , 0 , getImage(“tow”) )
.add( 250 , 0 , getImage(“one”) )
.print()
,
newKey(“FJ”)
.wait()
)[/js]
Now, this is pretty bad: the script is rather blunt and will crash on the slightest typo. Fortunately the debugger, which is just slightly smarter, is here. In this case, you should see a message in the Errors tab of the Debugger window when you test your experiment, saying something like Wrong command ‘newCanva’ on line 15. Did you mean to type ‘newCanvas’?
Sometimes your errors will be too sophisticated even for the debugger to guess what you were trying to do. Say you fix the typo above so your script correctly contains newCanvas—if you copied and fixed the script above and now are testing it, you should see a new error: No Image element named “tow” found.
When you get an error message in the Debugger, there are some basic steps you can take to fix your script. Most of the time, if you simply scan your script for the expression in quotes, you will find that you made a typo somewhere and fixing it will solve the problem. To help you locate the error, you can also pay attention to the number to the right of PennController: in the message: it indicates which trial contains the problematic expression, starting with 0 as the first trial being created. Sometimes, however, the error occurs outside a trial—in those cases, the number is no longer a reliable indicator, so make sure to scan your script.
Probing the commands thread
The Log tab of the Debugger reports a line whenever a command is executed on an element. This can be particularly useful if, for example, you were expecting something to happen in your trial but, somehow, you end up waiting for it to happen forever: maybe you’ll see that it already happened before, or that another crucial command was never executed to start with. You can then get a better idea of where and/or when the problem arises.
The Log tab also reports when a resource is successfully preloaded. It won’t tell you when preloading fails (because preloading failure—in contrast to success—does not culminate in any form of achievement) but if you get stuck on a long preloading message, you’ll be able to identify the problematic resource(s) by elimination.
Skipping to a given trial in the experiment
As your experiment becomes more complex, and as you keep adding trials to it, testing the experiment can become somewhat of a hassle, especially if you are testing a feature of a trial that comes late in your experiment. Fortunately for you, the Sequence tab lists all the trials of your experiment in running order, along with their labels and a Reach button. Clicking this button will rapidly skip through all the trials that separate you from the one you clicked on, allowing you to rapidly test trials anywhere in your experiment.
Takeaway
We won’t talk about the Info and Tables tabs here, but feel free to explore them, they should be rather self-explanatory (though Info will make more sense to people used to the native Ibex environment). Your main takeaway should be this: use the debugger as much as you can, because you will encounter problems, and the Debugger will make it so much easier to solve them. When you are 100% sure you are ready to publish your experiment online (after taking a look at—and ideally analyzing—your results file to make sure all relevant information gets saved) you can turn the Debugger off by simply adding [js]DebugOff()[/js] to you script.
Next: Data collection basics