Problems with AAT - software problem?


Author
Message
c.witteki
c.witteki
Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)
Group: Awaiting Activation
Posts: 24, Visits: 86
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

Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
c.witteki - Monday, December 05, 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

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).

c.witteki
c.witteki
Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)Distinguished Member (2.6K reputation)
Group: Awaiting Activation
Posts: 24, Visits: 86
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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

Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
c.witteki - Tuesday, December 06, 2016
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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.

morgenstern
morgenstern
Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)
Group: Forum Members
Posts: 11, Visits: 18
Dave - Tuesday, December 6, 2016
c.witteki - Tuesday, December 06, 2016
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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.

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?



Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
morgenstern - Tuesday, June 20, 2017
Dave - Tuesday, December 6, 2016
c.witteki - Tuesday, December 06, 2016
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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.

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?

morgenstern
morgenstern
Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)
Group: Forum Members
Posts: 11, Visits: 18
How can I know that?
Dave - Tuesday, June 20, 2017
morgenstern - Tuesday, June 20, 2017
Dave - Tuesday, December 6, 2016
c.witteki - Tuesday, December 06, 2016
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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.

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?



Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
morgenstern - Tuesday, June 20, 2017
How can I know that?
Dave - Tuesday, June 20, 2017
morgenstern - Tuesday, June 20, 2017
Dave - Tuesday, December 6, 2016
c.witteki - Tuesday, December 06, 2016
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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.

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.
morgenstern
morgenstern
Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)Expert (1K reputation)
Group: Forum Members
Posts: 11, Visits: 18
Dave - Tuesday, June 20, 2017
morgenstern - Tuesday, June 20, 2017
How can I know that?
Dave - Tuesday, June 20, 2017
morgenstern - Tuesday, June 20, 2017
Dave - Tuesday, December 6, 2016
c.witteki - Tuesday, December 06, 2016
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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.

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.

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!!



Attachments
aat_mouseinput_works_huijding_lo.iqx (295 views, 78.00 KB)
AATmouseinput_raw_complete.iqdat (300 views, 246.00 KB)
AATmouseinput_raw_downup.iqdat (308 views, 2.00 KB)
AATmouseinput_raw_down.iqdat (307 views, 2.00 KB)
Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
morgenstern - Wednesday, June 21, 2017
Dave - Tuesday, June 20, 2017
morgenstern - Tuesday, June 20, 2017
How can I know that?
Dave - Tuesday, June 20, 2017
morgenstern - Tuesday, June 20, 2017
Dave - Tuesday, December 6, 2016
c.witteki - Tuesday, December 06, 2016
Dave - Monday, December 05, 2016
c.witteki - Monday, December 05, 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

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.

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.

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.

Edited 7 Years Ago by Dave
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Explore
Messages
Mentions
Search