By becgwin - 3/23/2015
Hi,
I have an online study that is about to start and I have been testing it across different computers. It ran quite successfully over the last semester, but this time I am getting a lot of errors when pressing the start button. I have attached the file with the screen grab. Can you please tell me what this error means and why it is happening so frequently? And what I can do to fix it?
Many thanks,
Rebecca
|
By Dave - 3/23/2015
Usually such an error indicates that your browser has automatically prevented the Inquisit Web plugin from running.
Firefox does this by default for any newly installed plugin (mandatory "click to play"), make sure to allow the plugin via your browser's settings. Chrome used to behave differently, but recent versions have started removing plugin support altogether, i.e., the browser will refuse to execute the plugin no matter what you do. The solution for the latter case is to use the Web Player launch method.
If you are using the JavaWebStart launch method, make sure (a) your installed Java Runtime Environment (JRE) is up to date and (b) enabled in the browser (via the Java control panel applet and the browser's plugin settings).
If a given launch method fails for some reason, the "Having trouble starting" section at the bottom of any launch page offers alternative launch options.
|
By becgwin - 3/24/2015
Thanks Dave. Can you please tell me the best browser to launch Inquisit? That way I can direct my participants to that browser and save them any frustrations/difficulties loading the programme. Alternatively, would I be better just to direct them to use the Web Player launch method, or do the scripts run better on a standard browser if if works well. Also, if they use the web player, are there any issues I should be aware of, such as effects on the script or timing?
Rebecca
|
By Dave - 3/24/2015
There isn't an objectively "best" browser, I'm afraid. Apart from the browser, there are a lot of other moving parts (e.g.: Is Java installed? Is it enabled in the browser? Is it up to date? etc.). Generally, I'd say that using the Web Player is a good option overall -- it isn't confined to any particular browser, and as such should work across the widest range of possible operating system / browser configurations. Timing-wise, there should be no difference between the various launch methods.
|
By becgwin - 3/24/2015
Thanks Dave. That is very helpful - I might just suggest they use the web player as the go to option if there own browser doesn't load - or am I better to just set that as the default when I set my study up online? Is there any situations where the web player may have issues?
|
By Dave - 3/24/2015
I think it is fine to recommend the Web Player as the go-to option, but keep other launch methods available nonetheless in case it fails. The (sad) truth of the matter is that there are failure conditions -- sometimes very weird & irreproducible ones -- for any launch method. Hope this helps.
|
By becgwin - 3/26/2015
Hi Dave,
Thanks for that. Before I put the webplayer as the go-to, can I ask one more question. Some months ago in a post I made the comment that when using the webplayer, I could push the images OK, but pulling the images was problematic - once they got to the full size they did not usually disappear - but froze and to clear them you had to push them (https://www.millisecond.com/forums/Topic15283.aspx?Keywords=aat#bm15312). In testing my next study, I find that it is happening again using the webplayer on my Lenovo Thinkpad Carbon x1. You suggested I go through the script and check for subtle differences. The only differences that I have found in comparing my script to the library version are as follows:
1. I have changed the starheight and minheight ratios for B as I am using left and right tilt pictures which are both landscape (as versus landscape/portrait). The original code is as follows:
<values>
/Startheight_ratioA = 0.5
/Startheight_ratioB = 0.6
/MinHeight_ratioA = 0.05
/MinHeight_ratioB = 0.1
/intertrialinterval = 300
/pixeltolerance = 5
</values>
but my code now reads:
<values>
/Startheight_ratioA = 0.5
/Startheight_ratioB = 0.5
/MinHeight_ratioA = 0.05
/MinHeight_ratioB = 0.05
/intertrialinterval = 300
/pixeltolerance = 5
</values>
I was wondering if this might be causing problems but thought not as the problem is pulling whether it is left or right tilt (you might expect it only for one or the other if changing B to landscape was the problem?). I was also hoping you could let me know if this change might have other repercussions throughout the script of which I might be unaware?
The other changes are that I have added an error to the real trials - you helped me with that earlier - so that the code for trial decrease and increase starts with the following:
<trial decrease>
/inputdevice = mouse
/ontrialbegin = [if (values.expcondition == 1 && values.targetformat == "p") trial.decrease.insertstimulustime(text.error, 0)]
/ontrialbegin = [if (values.expcondition == 2 && values.targetformat == "l") trial.decrease.insertstimulustime(text.error, 0)]
/ ontrialbegin = [picture.targetstimulus.height = picture.targetstimulus.height - values.mouse_change/(values.maxheight/2) * expressions.maxheightchange_px]
OR
<trial increase>
/ontrialbegin = [if (values.expcondition == 1 && values.targetformat == "l") trial.increase.insertstimulustime(text.error, 0)]
/ontrialbegin = [if (values.expcondition == 2 && values.targetformat == "p") trial.increase.insertstimulustime(text.error, 0)]
/ ontrialbegin = [picture.targetstimulus.height = picture.targetstimulus.height + values.mouse_change/(values.maxheight/2) * expressions.maxheightchange_px]
I have been adapting the version developed on the 01-15-2014 and I note that in the latest version (09-12-2014) the first two lines of code are deleted (?). I have also used pre-generated sequences as I have increased the number of trials to 192.
I do not have the freezing problem with pulling on my computer at uni using the standard plug in and only one other person has commented on the issue.
You noted in my last post that you had not heard of it before, but I was wondering if you had any other ideas as to why it might be happening? I have attached my script again and please let me know if you would like the direct link to the online study.
Many thanks,
Rebecca
|
By Dave - 3/26/2015
I don't think the changes you made are responsible. Best guess is that something is off with the mouse coordinates, which is what the script relies on to check if the image has been fully extended (although I'm not sure why that would only happen in the web player). Please log those coordinates to the data file (see e.g. https://www.millisecond.com/forums/FindPost14276.aspx ) and attach the resulting file here. Please also provide your machine's display resolution.
|
By Dave - 3/26/2015
Another thing, which I'm not quite clear about: Do you experience the same issue with the original (unmodified, using the original images) AAT script available from the library when running it via the Web Player?
|
By becgwin - 3/28/2015
Hi Dave,
I tried running the library mouseinput AAT and had the same issue with freezing (note: while I mostly have to push it to get rid of the image, occasionally the image disappears after a while). My screen resolution is "Wide viewing angle and high density Flexview display 2560 x 1440". Attached is a section of the data with the mouse_y coordinate (I hope that is what you wanted). When I run the script on my computer from dropbox it works fine - it is only when I am running it online that I have the problem. I have compared the mouse coordinates for the two and find that when I am online the mouse_y coordinates are between 0 and 719, but when I do it via dropbox I get between 0 and 1439 (i.e. double when I do it online). I am not sure why this happens.
Any ideas on what is happening and how to fix it?
Thanks,
Rebecca
|
By Dave - 3/28/2015
Thanks for the data file. This confirms my suspicion that something's throwing off the mouse coordinates for some reason. You'll notice that 0-719 (720px) is only half of your actual vertical display resolution (0-1419; 1440px). The script thus doesn't "realize" that the image has been fully extended, because the relevant coordinate (1419) is never reached. Please try the following and let me know if that changes anything: Add
/ canvasposition = (50%, 50%)
to your script's <defaults> element and re-run in via the web (keep logging the mouse coordinates).
|
By becgwin - 4/8/2015
Hi Dave,
Thanks for this. Sorry for the late reply but I have been unwell.
I have tried this and it seems to make it worse. Whereas before it would occasionally allow the image to disappear when pulled (resulting in 719 for mouse_y), the image now must be pushed to disappear - when you pull the image it just stays on the screen (and I believe it is not allowing me to pull it as far as when there was no canvasposition included). I have not included the data file as all the values.mouse_y were 0.
Any other thoughts?
Kind regards,
Rebecca
|
By Dave - 4/8/2015
No, unfortunately I don't have any additional idea at the moment. It's clear that *something* is messing up the mouse coordinates (resulting in the apparent[1] freezing in "pull" trials ). What that something is, I have no clue.
> (and I believe it is not allowing me to pull it as far as when there was no canvasposition included)
The above suggests a wrongly sized and/or positioned canvas, so playing around with the scripts /canvasposition, /canvassize and /canvasaspectratio settings might help to narrow things down.
[1] It isn't actually freezing, the problem is that the mouse coordinate that would lead to the termination of the trial is never reached.
|