By c.witteki - 12/4/2016
Hi again,
in a study I use the mouse AAT, however, it is not working in the intended way:
when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT?
Thanks in advance for your help,
best
Charlotte
|
By Dave - 12/5/2016
+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte
It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following:
Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes).
|
By c.witteki - 12/5/2016
+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes).
Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas?
Thanks,
Charlotte
|
By Dave - 12/5/2016
+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte
Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates:
<trial increase>
...
/branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]
...
</trial>
My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire:
trial.increase.responsey >= values.maxheight-1
There are a couple of things you can do:
- For a quick fix, you can try relaxing the condition by say doing something like
trial.increase.responsey >= values.maxheight-6
- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx
- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up.
Let me know what you find regarding the mouse coordinates and we'll take it from there.
|
By morgenstern - 6/20/2017
+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there.
Hello, I write in this topic because I seem to have exactly the same issue.
I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10.
The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears.
The pull action does not, i.e. the stimulus gets bigger but never disappears.
Just like the previous user I already have the display.canvasheight instead of the display.height.
I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps.
Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears).
Any suggestion?
|
By Dave - 6/20/2017
+x+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there. Hello, I write in this topic because I seem to have exactly the same issue. I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10. The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears. The pull action does not, i.e. the stimulus gets bigger but never disappears. Just like the previous user I already have the display.canvasheight instead of the display.height. I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps. Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears). Any suggestion?
So what are the coordinates the mouse returns?
|
By morgenstern - 6/20/2017
How can I know that?
+x+x+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there. Hello, I write in this topic because I seem to have exactly the same issue. I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10. The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears. The pull action does not, i.e. the stimulus gets bigger but never disappears. Just like the previous user I already have the display.canvasheight instead of the display.height. I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps. Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears). Any suggestion? So what are the coordinates the mouse returns?
|
By Dave - 6/20/2017
+xHow can I know that? +x+x+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there. Hello, I write in this topic because I seem to have exactly the same issue. I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10. The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears. The pull action does not, i.e. the stimulus gets bigger but never disappears. Just like the previous user I already have the display.canvasheight instead of the display.height. I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps. Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears). Any suggestion? So what are the coordinates the mouse returns?
You would have to log that information. See here: https://www.millisecond.com/forums/FindPost17073.aspx
In short: Set /recorddata=true for all <trial> elements in the script and then log values.mouse_y, trial.increase.responsey, trial.decrease.responsey, display.height, and display.canvasheight to the data file via the <data> element's /columns element.
|
By morgenstern - 6/21/2017
+x+xHow can I know that? +x+x+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there. Hello, I write in this topic because I seem to have exactly the same issue. I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10. The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears. The pull action does not, i.e. the stimulus gets bigger but never disappears. Just like the previous user I already have the display.canvasheight instead of the display.height. I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps. Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears). Any suggestion? So what are the coordinates the mouse returns? You would have to log that information. See here: https://www.millisecond.com/forums/FindPost17073.aspxIn short: Set /recorddata=true for all <trial> elements in the script and then log values.mouse_y, trial.increase.responsey, trial.decrease.responsey, display.height, and display.canvasheight to the data file via the <data> element's /columns element.
Please find attached three log files.
The "complete" one includes all the experiment I am planning, for each item I tried to go to the down limit before going to the upper one in order to switch to the next stimulus.
The "downup" file consists in one only item in which I went down and up to the limits until switching to the following one.
The "down" file only includes the down limit.
I also include the syntax file. It is a modified version of the AAT, similar to the one used by Huijding et al., 2009.
Thank you!!
|
By Dave - 6/21/2017
+x+x+xHow can I know that? +x+x+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there. Hello, I write in this topic because I seem to have exactly the same issue. I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10. The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears. The pull action does not, i.e. the stimulus gets bigger but never disappears. Just like the previous user I already have the display.canvasheight instead of the display.height. I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps. Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears). Any suggestion? So what are the coordinates the mouse returns? You would have to log that information. See here: https://www.millisecond.com/forums/FindPost17073.aspxIn short: Set /recorddata=true for all <trial> elements in the script and then log values.mouse_y, trial.increase.responsey, trial.decrease.responsey, display.height, and display.canvasheight to the data file via the <data> element's /columns element. Please find attached three log files. The "complete" one includes all the experiment I am planning, for each item I tried to go to the down limit before going to the upper one in order to switch to the next stimulus. The "downup" file consists in one only item in which I went down and up to the limits until switching to the following one. The "down" file only includes the down limit. I also include the syntax file. It is a modified version of the AAT, similar to the one used by Huijding et al., 2009. Thank you!!
I asked you to also log display.canvasheight. That's not in those data files, only display.height is. Could you please provide data including the canvas height? Thanks.
P.S.: You don't need to conduct any additional full test runs for that -- just tell me what the display.canvasheight property returns when you run the script.
|
By Dave - 6/21/2017
+x+x+x+xHow can I know that? +x+x+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there. Hello, I write in this topic because I seem to have exactly the same issue. I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10. The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears. The pull action does not, i.e. the stimulus gets bigger but never disappears. Just like the previous user I already have the display.canvasheight instead of the display.height. I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps. Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears). Any suggestion? So what are the coordinates the mouse returns? You would have to log that information. See here: https://www.millisecond.com/forums/FindPost17073.aspxIn short: Set /recorddata=true for all <trial> elements in the script and then log values.mouse_y, trial.increase.responsey, trial.decrease.responsey, display.height, and display.canvasheight to the data file via the <data> element's /columns element. Please find attached three log files. The "complete" one includes all the experiment I am planning, for each item I tried to go to the down limit before going to the upper one in order to switch to the next stimulus. The "downup" file consists in one only item in which I went down and up to the limits until switching to the following one. The "down" file only includes the down limit. I also include the syntax file. It is a modified version of the AAT, similar to the one used by Huijding et al., 2009. Thank you!! I asked you to also log display.canvasheight. That's not in those data files, only display.height is. Could you please provide data including the canvas height? Thanks. P.S.: You don't need to conduct any additional full test runs for that -- just tell me what the display.canvasheight property returns when you run the script.
*Assuming* display.canvasheight happens to be identical to display.height on this particular system (that's possible, but not certain -- it depends on the display's native aspect ratio), then the problem is that -- for some reason -- the canvas is displaced (might be a defunct display driver or some other application running in the background throwing things off).
display.height is 1024 in your data.
- The lowest value for values.mouse_y (a full "PUSH") is -32. The value should generally not be negative, but rather 0 (or slightly above, depending on settings). A negative value is indicative of the mouse venturing beyond the specified canvas area.
- The highest value for values.mouse_y (a "PULL") is 991. So, under the assumption that display.canvasheight equals 1024, the mouse never comes close to the coordinate that would trigger the end of the PULL action / indicate a full "PULL" -- that value would be 1023 (0 to 1023 -> 1024 points in the vertical dimension).
Since 991 + 32 = 1023, i.e. the range one would expect with a canvas height of 1024, this leads me to suspect that the canvas is not properly centered, but rather offset such that its bottom end lies beyond the physical screen boundaries. I.e. with the blue area representing the physical screen, and the yellow area representing the canvas, you probably have something like
instead of
Please try setting the canvas position explicitly
<defaults >
/canvasposition = (50%, 50%)
/canvasaspectratio = (4,3)
/minimumversion = "4.0.4.0"
/ inputdevice = mouse
</defaults>
and see if that resolves the problem on your system.
|
By morgenstern - 6/21/2017
+x+x+x+xHow can I know that? +x+x+x+x+x+xHi again, in a study I use the mouse AAT, however, it is not working in the intended way: when participants are instructed to pull the mouse, the pictures remains on the screen although the response direction is correct. In contrast, when pictures are pushed (irrespective of instruction), the pictures disappear (importantly, the AAT is running on other computers, thus, the computers that are used seem to be the problem). As the computers are rather old, I was wondering whether the graphic card (AMD Radeon (TM) HD 8350) or the system (e.g., RAM (8 GB) or processor (Intel (R) Core (TM) i5-4590 CPU@ 3.30GHz) might be responsible. Are there any minimum requirements to run the mouse AAT? Thanks in advance for your help, best Charlotte It seems more likely that when you pull the mouse, the mouse coordinates never actually reach the border of the screen. Try the following: Do a search & replace in the script and replace all instances of "display.height" with "display.canvasheight" (without the double-quotes). Hi Dave, thanks for your reply. I searched the script for "display.height", however, this command does not appear. There is one instance /Maxheight = display.canvasheight, but that´s it. Do you have any other ideas? Thanks, Charlotte Okay, thanks. We need to figure out what's happening on those systems then. For background: The script determines when a stimulus has been "fully zoomed in" based on the mouse coordinates: <trial increase> ... /branch = [if (trial.increase.responsey >= values.maxheight-1)
{values.mouse_y = trial.increase.responsey; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease}]... </trial> My theory still is that this just never happens because -- for some reason -- the mouse never reaches the required coordinates for the above conditiont to fire: trial.increase.responsey >= values.maxheight-1There are a couple of things you can do: - For a quick fix, you can try relaxing the condition by say doing something like trial.increase.responsey >= values.maxheight-6- To really figure out what happens, you would have to modify the script and log the actual mouse coordinates (change the /recorddata attributes in the various increase / decrease trials to 'true', log the respective responsey and mousey properties to the data file, log display.height and display.canvasheight). Those would show which coordinates the mouse is actually able to reach on those systems. See e.g. this thread for a similar problem: https://www.millisecond.com/forums/FindPost17073.aspx- As for what prevents the mouse from working properly on those systems, there are a couple of possibilities: You may have some piece of software installed that messes with the mouse / remaps its coordinates. If the systems have multiple monitors with different sizes attached, that can also mess things up. Let me know what you find regarding the mouse coordinates and we'll take it from there. Hello, I write in this topic because I seem to have exactly the same issue. I'm using an AAT module on Inquisit 5 on a Lenovo Thinkvision with Windows 10. The push action works properly, i.e. the stimulus gets smaller and smaller and then disappears. The pull action does not, i.e. the stimulus gets bigger but never disappears. Just like the previous user I already have the display.canvasheight instead of the display.height. I tried relaxing the condition, from the original 1 I tried to change it up and up up to 200. Nothing helps. Something weird: I also tried the joystick version and with that module I seem to have this same issue but with both actions (i.e. I can zoom the picture in and out with the joystick but the picture never disappears). Any suggestion? So what are the coordinates the mouse returns? You would have to log that information. See here: https://www.millisecond.com/forums/FindPost17073.aspxIn short: Set /recorddata=true for all <trial> elements in the script and then log values.mouse_y, trial.increase.responsey, trial.decrease.responsey, display.height, and display.canvasheight to the data file via the <data> element's /columns element. Please find attached three log files. The "complete" one includes all the experiment I am planning, for each item I tried to go to the down limit before going to the upper one in order to switch to the next stimulus. The "downup" file consists in one only item in which I went down and up to the limits until switching to the following one. The "down" file only includes the down limit. I also include the syntax file. It is a modified version of the AAT, similar to the one used by Huijding et al., 2009. Thank you!! I asked you to also log display.canvasheight. That's not in those data files, only display.height is. Could you please provide data including the canvas height? Thanks. P.S.: You don't need to conduct any additional full test runs for that -- just tell me what the display.canvasheight property returns when you run the script.
Hi, sorry for the missing information. Please find attached the new, complete, data file. If I read it correctly turns out that canvasheight is different from height.
|
By morgenstern - 6/21/2017
Sorry, wrong file. Is it normal that I cannot edito nor delete my own posts? Please find attached the correct file for the joystick version.
|
By Dave - 6/22/2017
+xSorry, wrong file. Is it normal that I cannot edito nor delete my own posts? Please find attached the correct file for the joystick version.
Thanks for the additional data files; those have been very helpful with respect to figuring out where things go sideways. Problem is that values.maxheight may be set to a wrong value at the time it is originally set, which happens when the script is initially parsed. Under some circumstances this can lead to it being set to the full display.height because the exact canvas dimensions have not been determined yet, i.e. if display.canvasheight ends up being smaller than display.height (as in your case) the "endincrease" condition may end up being impossible to reach. If you add
<expt >
/ onexptbegin = [
values.Maxheight = display.canvasheight;
]
...
</expt>
to both <expt> elements in the script, things should work -- at this point the exact canvas height is known to the script.
|
By morgenstern - 6/22/2017
+x+xSorry, wrong file. Is it normal that I cannot edito nor delete my own posts? Please find attached the correct file for the joystick version. Thanks for the additional data files; those have been very helpful with respect to figuring out where things do sideways. Problem is that values.maxheight may be set to a wrong value at the time it is originally set, which happens when the script is initially parsed. Under some circumstances this can lead to it being set to the full display.height because the exact canvas dimensions have not been determined yet, i.e. if display.canvasheight ends up being smaller than display.height (as in your case) the "endincrease" condition may end up being impossible to reach. If you add <expt > / onexptbegin = [
values.Maxheight = display.canvasheight;
]... </expt> to both <expt> elements in the script, things should work -- at this point the exact canvas height is known to the script.
Wow! Mouse version works now!
I tried adding the same syntax to the joystick file but when I run it it fails and gives error in the exp section: Expression 'values.Maxheight' is invalid. Expression contains an unknown element or property name. I see a 'values.Maxheight_px' in the file. Is this anyhow related to the error I get?
Thank you very much for your help!
|
By Dave - 6/22/2017
+x+x+xSorry, wrong file. Is it normal that I cannot edito nor delete my own posts? Please find attached the correct file for the joystick version. Thanks for the additional data files; those have been very helpful with respect to figuring out where things do sideways. Problem is that values.maxheight may be set to a wrong value at the time it is originally set, which happens when the script is initially parsed. Under some circumstances this can lead to it being set to the full display.height because the exact canvas dimensions have not been determined yet, i.e. if display.canvasheight ends up being smaller than display.height (as in your case) the "endincrease" condition may end up being impossible to reach. If you add <expt > / onexptbegin = [
values.Maxheight = display.canvasheight;
]... </expt> to both <expt> elements in the script, things should work -- at this point the exact canvas height is known to the script. Wow! Mouse version works now! I tried adding the same syntax to the joystick file but when I run it it fails and gives error in the exp section: Expression 'values.Maxheight' is invalid. Expression contains an unknown element or property name. I see a 'values.Maxheight_px' in the file. Is this anyhow related to the error I get? Thank you very much for your help!
The joystick version works somewhat differently. While you'll want to set
<expt >
/ onexptbegin = [
values.Maxheight_px = display.canvasheight;
]
...
</expt>
in the joystick version, I cannot be sure if this alone will resolve the problem. Contrary to what you say here https://www.millisecond.com/forums/FindPost21943.aspx , the attached file either isn't from the joystick version or at least doesn't log any of the information pertaining to the joystick version (no values.joystick_y, etc.).
|
By morgenstern - 6/22/2017
+x+x+x+xSorry, wrong file. Is it normal that I cannot edito nor delete my own posts? Please find attached the correct file for the joystick version. Thanks for the additional data files; those have been very helpful with respect to figuring out where things do sideways. Problem is that values.maxheight may be set to a wrong value at the time it is originally set, which happens when the script is initially parsed. Under some circumstances this can lead to it being set to the full display.height because the exact canvas dimensions have not been determined yet, i.e. if display.canvasheight ends up being smaller than display.height (as in your case) the "endincrease" condition may end up being impossible to reach. If you add <expt > / onexptbegin = [
values.Maxheight = display.canvasheight;
]... </expt> to both <expt> elements in the script, things should work -- at this point the exact canvas height is known to the script. Wow! Mouse version works now! I tried adding the same syntax to the joystick file but when I run it it fails and gives error in the exp section: Expression 'values.Maxheight' is invalid. Expression contains an unknown element or property name. I see a 'values.Maxheight_px' in the file. Is this anyhow related to the error I get? Thank you very much for your help! The joystick version works somewhat differently. While you'll want to set <expt > / onexptbegin = [
values.Maxheight_px = display.canvasheight;
]... </expt> in the joystick version, I cannot be sure if this alone will resolve the problem. Contrary to what you say here https://www.millisecond.com/forums/FindPost21943.aspx , the attached file either isn't from the joystick version or at least doesn't log any of the information pertaining to the joystick version (no values.joystick_y, etc.).
Please find attached the new joystick file. It should present the appropriate information now. I added the syntax you suggested but it does not work yet.
|
|