By c.witteki - 2/25/2015
Hello,
I just got Inquisit and downloaded the demo version of the mouse AAT. However, it seems that there is an error within the manuscript as all pictures move in one direction (push movement) although half of the pictures should be associated with a "pull"-movement. As I just learn to understand the scripts, I was unable to check whether the mistake is in the script provided in the script library.
Can you help me solving this issue?
Thanks,
Charlotte
|
By Dave - 2/25/2015
There's no mistake in the script, I am sure about that. Something else must be at work here. Could you please elaborate what exactly you mean by "all pictures move in one direction (push movement) although half of the pictures should be associated with a "pull"-movement"? You are free to pull or push any image -- if a participant pushes an image that should actually be pulled according to the instructions, that's simply an error on the behalf of the participant and will be recorded as such.
|
By c.witteki - 3/5/2015
Thanks for your reply. In the demo as well as in the downloaded version, you can pull and push the pictures, but they only disappear when they are being pushed (irrespective of the picture format). If they are pulled, they remain on the screen even if it was the right response.
Thanks again for your help,
Charlotte
|
By Dave - 3/5/2015
Do you -- by any chance -- have multiple displays attached to that machine? If so, that may throw off the mouse coordinates Inquisit uses to determine whether to stop the trial. See e.g. https://www.millisecond.com/forums/FindPost14494.aspx for what you can do to figure that out.
|
By c.witteki - 3/26/2015
Hey again!
First of all, sorry for the late reply. We had two monitors attached, however, even when we disconnected one of the displays, the described problem remained. Pictures only disappear when the pictures are being pushed, irrespective of the format. During training trials, there is an error message (portrait format pictures during training trials) which is not presented during the experimental trials.
Any other ideas what could be at work here?
Thanks,
Charlotte
|
By Dave - 3/26/2015
I still think there's likely something wrong with the mouse coordinates reported on that machine. Please enable logging of those coordinates as detailed in the post I linked to earlier. Then provide the resulting data file (you can attach it to the thread by clicking the +Insert button).
|
By c.witteki - 4/1/2015
Hi again,
plaese find attached the output data (one monitor).
Thanks a lot for your help,
Charlotte
|
By Dave - 4/1/2015
Thanks for providing the data file. There's definitely something *very* wrong with regards to the mouse coordinates on your system. You'll see that virtually all the reported coordinates are *negative*, i.e., not actually on the visible display surface.
The coordinates ought to vary between 0 (the top row of pixels on the display) and the display's vertical resolution minus one (e.g. 1439 for a display with a height of 1440 pixels). The AAT script uses those coordinates to detect whether the stimulus has been fully zoomed in or out, i.e., it checks whether the mouse coordinates have hit the top (0) or bottom (e.g. 1439) screen border.
My best guess is that some other software running on your system is interfering with the mouse coordinates. That may or may not be related to your original dual-display setup (the application you use to control the two displays might still mess things up, even if the 2nd display is not attached). Please disable any unnecessary application running in the background. In addition, please add
/ canvasposition = (50%, 50%)
to the script's <defaults> element for testing purposes.
|
By c.witteki - 4/8/2015
Thanks! The odd thing is that the problem occured on two machines (one without additional monitor). I wonder why the mouse coordinates are wrong on both machines. Do you have any idea which program might interfere?!
Thanks a lot!
|
By Dave - 4/8/2015
No, I have no spontaneous idea what specific program (or other factor pertaining to those two systems) could be responsible for throwing off the coordinates. It is clear from the data file, however, that the coordinates are wrong. You did not mention whether you tried adjusting the /canvasposition as suggested in my previous reply. If so, did that change anything re. the logged coordinates? If you haven't tried it yet, please do.
|
By c.witteki - 4/16/2015
Unfortunately, including: / canvasposition = (50%, 50%) did not change the mouse coordinates. We have successfully run the version on two different laptops though and the coordinates seem right in those outputs. As we want to use the script for an online study it would be important that it ran on all computers. If you have any idea what we need to do to fix the problem, that occurs on some computers, it would be great. Thanks!
|
By Dave - 4/16/2015
Unfortunately I don't have any idea what's causing this at present. I am unable to reproduce this on any of the machines I have at my disposal, i.e., the coordinates take on the values they are supposed to take on. My overall impression is that only very few systems would exhibit this issue (for as yet unknown reasons), so in an online setting I would (1) log coordinates and (2) weed out those few machines where they are off (e.g. negative coordinates).
If you come across any additional information / possibly pertinent details regarding the machines you're seeing this on, please add them to this thread. The more information, the likelier it is we can eventually zero in on the root cause. Thanks!
|
By c.witteki - 4/16/2015
Thanks, Dave. We will add information, if we know why the coordinates are incorrect on some computers.
|