Millisecond Forums

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.

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

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.

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?

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.

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

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.

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?

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