|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+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.
|
|
|
|
|
morgenstern
|
|
|
Group: Forum Members
Posts: 11,
Visits: 18
|
+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.
|
|
|
|
|
morgenstern
|
|
|
Group: Forum Members
Posts: 11,
Visits: 18
|
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.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+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.
|
|
|
|
|
morgenstern
|
|
|
Group: Forum Members
Posts: 11,
Visits: 18
|
+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!
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+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.).
|
|
|
|
|
morgenstern
|
|
|
Group: Forum Members
Posts: 11,
Visits: 18
|
+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.
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+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. Thanks. There seems to be something wrong with your joystick's configuration / calibration. When fully extended in either direction, the joystick should report a value of 1000. Specifically, it should be +1000 in case of a full "PULL", and -1000 in case of a full "PUSH" Here's data from a test run on a system set to the same canvas settings as yours and a properly calibrated joystick.  When at rest and centered, a properly calibrated joystick ought to return 0 as its position. Full extension in either direction, is what triggers "end decrease" and "end increase" condition respectively: <trial practicedecrease> ... /branch = [if (joystick.y <= -1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PUSH"; trial.enddecrease_practice}] ... </trial> <trial practiceincrease> ... /branch = [if (joystick.y >= 1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease_practice}] ... </trial> Contrary to the mouse-version, the joystick coordinates -- -1000 to +1000 -- have nothing to do with the canvas dimensions or screen resolution. They represent the joystick's own relative coordinate system which does not vary with display resolution or the like. Try calibrating your joystick either via the software provided by its manufacturer or the operating system's built-in facilities.
|
|
|
|
|
morgenstern
|
|
|
Group: Forum Members
Posts: 11,
Visits: 18
|
+x+x+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. Thanks. There seems to be something wrong with your joystick's configuration / calibration. When fully extended in either direction, the joystick should report a value of 1000. Specifically, it should be +1000 in case of a full "PULL", and -1000 in case of a full "PUSH" Here's data from a test run on a system set to the same canvas settings as yours and a properly calibrated joystick. When at rest and centered, a properly calibrated joystick ought to return 0 as its position. Full extension in either direction, is what triggers "end decrease" and "end increase" condition respectively: <trial practicedecrease> ... /branch = [if (joystick.y <= -1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PUSH"; trial.enddecrease_practice}] ... </trial> <trial practiceincrease> ... /branch = [if (joystick.y >= 1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease_practice}] ... </trial> Contrary to the mouse-version, the joystick coordinates -- -1000 to +1000 -- have nothing to do with the canvas dimensions or screen resolution. They represent the joystick's own relative coordinate system which does not vary with display resolution or the like. Try calibrating your joystick either via the software provided by its manufacturer or the operating system's built-in facilities. Sorry for my late answer. Joystick calibration really helped, now it almost works as expected. However the joystick is still very laggy. What I mean is that, in order to switch to the next image, I have to push (or pull) the joystick to its extremes (which is fine), but then I have to keep it in the extreme position for a while, maybe around 1-2 seconds. If I go back to rest position faster (in less then a second), the picture gets back to normal and there is no switch. This makes the whole procedure very slow and effortful. I tried doing the calibration a few times trying not to push and pull to much the joystick to its extremes but it did not help. Is there any option to make the exreme point movement detection faster? Thank you so much
|
|
|
|
|
Dave
|
|
|
Group: Administrators
Posts: 13K,
Visits: 104K
|
+x+x+x+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. Thanks. There seems to be something wrong with your joystick's configuration / calibration. When fully extended in either direction, the joystick should report a value of 1000. Specifically, it should be +1000 in case of a full "PULL", and -1000 in case of a full "PUSH" Here's data from a test run on a system set to the same canvas settings as yours and a properly calibrated joystick. When at rest and centered, a properly calibrated joystick ought to return 0 as its position. Full extension in either direction, is what triggers "end decrease" and "end increase" condition respectively: <trial practicedecrease> ... /branch = [if (joystick.y <= -1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PUSH"; trial.enddecrease_practice}] ... </trial> <trial practiceincrease> ... /branch = [if (joystick.y >= 1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease_practice}] ... </trial> Contrary to the mouse-version, the joystick coordinates -- -1000 to +1000 -- have nothing to do with the canvas dimensions or screen resolution. They represent the joystick's own relative coordinate system which does not vary with display resolution or the like. Try calibrating your joystick either via the software provided by its manufacturer or the operating system's built-in facilities. Sorry for my late answer. Joystick calibration really helped, now it almost works as expected. However the joystick is still very laggy. What I mean is that, in order to switch to the next image, I have to push (or pull) the joystick to its extremes (which is fine), but then I have to keep it in the extreme position for a while, maybe around 1-2 seconds. If I go back to rest position faster (in less then a second), the picture gets back to normal and there is no switch. This makes the whole procedure very slow and effortful. I tried doing the calibration a few times trying not to push and pull to much the joystick to its extremes but it did not help. Is there any option to make the exreme point movement detection faster? Thank you so much > [...] I have to keep it in the extreme position for a while, maybe around 1-2 seconds. Not seeing this with any of the joysticks I've ever used, so I suspect your device may be malfunctioning. Have you tried a different joystick? What you can also try, alternatively, is to toy around with these values: <trial practicedecrease> ... /branch = [if (joystick.y <= -1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PUSH"; trial.enddecrease_practice}] ... </trial> <trial practiceincrease> ... /branch = [if (joystick.y >= 1000) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease_practice}] ... </trial> i.e. set them below 1000, thus not requiring a *full* extension of the joystick: <trial practicedecrease> ... /branch = [if (joystick.y <= -995) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PUSH"; trial.enddecrease_practice}] ... </trial> <trial practiceincrease> ... /branch = [if (joystick.y >= 995) {values.joystick_y = joystick.y; values.endtime = script.elapsedtime; values.finalresponse = "PULL"; trial.endincrease_practice}] ... </trial> That should help if your particular joystick barely ever reaches the maximum (1000) without applying considerable force and despite the re-calibration.
|
|
|
|