Printable View
I am encountering a problem where DirectRT stops running stimuli as if the input file is done very early in the test. We believe it has to do with when a subject responds to stimuli, it may be when there is a false answer. We have two 'jump to' functions.
This seems to only happen on a certain file, but the file appears to be written the same as our other input files.
Can you post your input file? Would be happy to take a look. Normally a session would end a trial ID for a jump is not found. If it is there, it would be odd for it to be skipped over.
I have attached two files. The first is the one (ROantb+) that ends DirectRT early. The longest we have gotten it to run is to the 114th trial (fleac)
The second is one (ROant1a+) that we have gotten to run all the way through and have only made the change of numbering the trials 1-160 since and seemed to run OK.
Thank you.
Nothing obviously wrong as far as I can see. If you run through a trial session with [I]ROantb+[/I] and give the same response on each trial (e.g., always [I]203[/I], always [I]205[/I], or always [I]208[/I]), will it always quit at the same spot?
[I][edited from support email][/I]
[QUOTE]
I actually think I found the problem and would just like confirmation. Our variable in position 158 is generally where the survey abruptly cuts off. However I just noticed that the skip is incorrectly programmed to skip to a preceding variable for all but two of the possible response categories. Would this cause the experiment to end? It is currently programmed to skip to 'everdrunk' which occurred at position 118 instead of rmeligion at position 161.
[/QUOTE]
Yes, a backwards jump or skip would cause it to end because DirectRT simply skips trials until it finds the one it's looking for. If it is never found (in the forward direction), the session would end.
We haven't gone through a file using only one response, yet. We do, however, believe that the crash has to do with too fast of a response time. It seems to be crashing on swifter responses, which seem to be within 200 miliseconds or less from the word stimuli. Has this been a problem in the past for anyone?
The software doesn't seem to consistently crash dependent on which button (203, 205, 208) is pressed, but it does seem more consistent that it crashes when response time is quicker (about 200 miliseconds or less).