By AKrishna - 6/2/2021
Hi all,
we're working on an approach-avoidance task that uses a zooming effect and noticed a weird bug that appears to have been introduced in Inquisit 6. I have attached my script file and necessary stimuli - although please note the script file is very messy! - but to explain the issue in brief, there is weird flickering of text stimuli during the zoom on some systems, which we also reproduced in another experiment we had run previously using picture stimuli instead of text.
In depth, it's probably helpful to understand how the zooming effect has been implemented: by using a background picture stimulus (4.jpg, attached) and text stimuli and iteratively changing their size via expressions.
Specifically (I will refer to lines in the script here to hopefully make it easier to follow):
Several values control the zooming effect (l.17-21). The number of "steps" (i.e. individual frames) the zoom takes is set from the display's refresh interval to equal 500 (or as close as possible). The text and background picture are each set up with a "final" zoom factor, which is the factor by which the stimulus size is multiplied compared to its starting value at the end of the zoom-in effect. In order to allow for a zoom-out, the picture stimulus starts already somewhat zoomed in (see l. 167-168), namely to precisely the degree defined in the final zoom factor. This is so that the zooming out effect always stops at precisely the maximum size for the picture, which should cover the entire display.
When the zooming effect is activated by a (correct) participant response, a value (Hopcounter) starts counting upwards (l. 543) [please ignore the VAASTHammering variable, that's an option I added to allow for multiple responses to "walk" towards or away from the target in steps - its value is false in any case]. The timeout is set to the refresh rate (l.20), so the zoom trial (l.541-573) repeats once per frame, each time with a changed stimulus size, until HopCounter hits the upper limit (l. 547). Each time the zoom trial iterates, it automatically changes the value of the AATTargetStimulusXSize and BGPicXSize expressions (l. 113-123). If zooming in, the difference between the multiplier and 1 is calculated to yield the proportion by which size should be increased - this is then divided by the desired total number of steps (so that each step increments equally) and multiplied by the current step (which is changed on each iteration of the zoom trial - see l.113/121). If zooming out, the logic is similar, but size is reduced stepwise instead (l.114/122).
Thus, the zoom trial iterates [[NumZoomSteps]] times and the stimuli (background and target word) should change evenly in size each time. Now comes the weird part.
On my (fairly beefy) personal computer, this works as expected. But four different testers on other computers of varying degrees of lesser beefiness have reported that the zoom effect is choppy (especially when zooming out, i.e. avoiding) and, more importantly, that the target word flickers in and out of visibility randomly during the zooming effect. The even odder thing is that this behavior does not occur if we run the experiment in Inquisit 5.
We also noted a general difference in draw quality between Inquisit 5 and 6, with the former drawing sharper visuals. This is particularly easy to see if one replaces the picture stimulus ("4.jpg") with a simple black and white grid (e.g. http://www.psychologie.uni-wuerzburg.de/fileadmin/06020231/images/deposit/perspective-grid-png-6-original.jpg) - in our tests, the grid lines appeared grey and slightly blurry in Inquisit 6, but not in Inquisit 5.
Finally, although this may be unrelated, we also noted that zooming out appeared to go too far on some systems, such that one could see the older iterations of the background picture that were no longer being covered by the picture (which should have been covering the entire screen). I have a hunch this might have something to do with the aspect ratios, but I can't quite figure it out. It didn't occur on my display (res. 3840x2160), but did on two others (1680x1050 and 2560x1440).
Sorry for the long question and the messy script to go with it - I normally try to simplify my forum upload examples, but this one was a little too elaborate to easily break down again. :-/
|
By Dave - 6/2/2021
+xHi all, we're working on an approach-avoidance task that uses a zooming effect and noticed a weird bug that appears to have been introduced in Inquisit 6. I have attached my script file and necessary stimuli - although please note the script file is very messy! - but to explain the issue in brief, there is weird flickering of text stimuli during the zoom on some systems, which we also reproduced in another experiment we had run previously using picture stimuli instead of text. In depth, it's probably helpful to understand how the zooming effect has been implemented: by using a background picture stimulus (4.jpg, attached) and text stimuli and iteratively changing their size via expressions. Specifically (I will refer to lines in the script here to hopefully make it easier to follow): Several values control the zooming effect (l.17-21). The number of "steps" (i.e. individual frames) the zoom takes is set from the display's refresh interval to equal 500 (or as close as possible). The text and background picture are each set up with a "final" zoom factor, which is the factor by which the stimulus size is multiplied compared to its starting value at the end of the zoom-in effect. In order to allow for a zoom-out, the picture stimulus starts already somewhat zoomed in (see l. 167-168), namely to precisely the degree defined in the final zoom factor. This is so that the zooming out effect always stops at precisely the maximum size for the picture, which should cover the entire display. When the zooming effect is activated by a (correct) participant response, a value (Hopcounter) starts counting upwards (l. 543) [please ignore the VAASTHammering variable, that's an option I added to allow for multiple responses to "walk" towards or away from the target in steps - its value is false in any case]. The timeout is set to the refresh rate (l.20), so the zoom trial (l.541-573) repeats once per frame, each time with a changed stimulus size, until HopCounter hits the upper limit (l. 547). Each time the zoom trial iterates, it automatically changes the value of the AATTargetStimulusXSize and BGPicXSize expressions (l. 113-123). If zooming in, the difference between the multiplier and 1 is calculated to yield the proportion by which size should be increased - this is then divided by the desired total number of steps (so that each step increments equally) and multiplied by the current step (which is changed on each iteration of the zoom trial - see l.113/121). If zooming out, the logic is similar, but size is reduced stepwise instead (l.114/122). Thus, the zoom trial iterates [[NumZoomSteps]] times and the stimuli (background and target word) should change evenly in size each time. Now comes the weird part. On my (fairly beefy) personal computer, this works as expected. But four different testers on other computers of varying degrees of lesser beefiness have reported that the zoom effect is choppy (especially when zooming out, i.e. avoiding) and, more importantly, that the target word flickers in and out of visibility randomly during the zooming effect. The even odder thing is that this behavior does not occur if we run the experiment in Inquisit 5. We also noted a general difference in draw quality between Inquisit 5 and 6, with the former drawing sharper visuals. This is particularly easy to see if one replaces the picture stimulus ("4.jpg") with a simple black and white grid (e.g. http://www.psychologie.uni-wuerzburg.de/fileadmin/06020231/images/deposit/perspective-grid-png-6-original.jpg) - in our tests, the grid lines appeared grey and slightly blurry in Inquisit 6, but not in Inquisit 5. Finally, although this may be unrelated, we also noted that zooming out appeared to go too far on some systems, such that one could see the older iterations of the background picture that were no longer being covered by the picture (which should have been covering the entire screen). I have a hunch this might have something to do with the aspect ratios, but I can't quite figure it out. It didn't occur on my display (res. 3840x2160), but did on two others (1680x1050 and 2560x1440). Sorry for the long question and the messy script to go with it - I normally try to simplify my forum upload examples, but this one was a little too elaborate to easily break down again. :-/
> the target word flickers in and out of visibility randomly during the zooming effect
Not seeing this under Inquisit 6.4.2 on not particularly beefy systems (e.g. a ca. 2013 ThinkPad T430 with a 3rd generation Intel Core i5 and 8GB of RAM).
The image has a 16:9 aspect ratio (1920 x 1080 pixels). Your display has a 16:9 aspect ratio (3840 x 2160 pixels), too, so this shakes out. Since the inherent aspect ratio of the image will not be distorted, you should expect to see artifacts on displays that are not 16:9, i.e. the image cannot cover the screen fully (e.g. 1680 x 1050 is 16:10).
Here's an example when running at a 16:10 resolution:
Note the artifacts at the top and bottom due to the image-display aspect ratio mismatch. The 16:9 image cannot cover the entire 16:10 area, so previous (larger) instances of the image remain visible underneath (per /erase=false, they are not erased, which would cause flickering).
By contrast, here's a shot running at a 16:9 resolution:
Since the aspect ratios match, the image can cover the entire display area.
Artifacts at 2560 x 1440 would be odd, since that is 16:9. Are you sure the system was actually running at that resolution?
You can get rid of those artifacts by either
- setting a /canvasaspectratio of 16:9 in <defaults>, and/or
- inserting a clearscreen as the first stimulus in the zoom trial, followed by the picture stimulus, then the text stimulus.
|
By AKrishna - 6/4/2021
Hmm. Thanks for the info about the aspect ratio - I knew I was missing something, but for some reason I couldn't make that simple connection.
The flickering is unfortunately reproducible on multiple systems - I'm not sure what's doing it. I'll try to get my colleagues to capture some screen footage for a better bug report.
|
By Dave - 6/4/2021
+xHmm. Thanks for the info about the aspect ratio - I knew I was missing something, but for some reason I couldn't make that simple connection. The flickering is unfortunately reproducible on multiple systems - I'm not sure what's doing it. I'll try to get my colleagues to capture some screen footage for a better bug report.
Would you happen to have the specs for at least some of the affected systems? Particularly:
- OS type and version (note the system requirements at: https://www.millisecond.com/products/inquisit6/requirements.aspx ; e.g. if you're seeing this under e.g. Windows 7 or 8, those operating systems are technically not supported.)
- Inquisit version (please make sure everyone is using the same, latest version available, 6.4.2).
- Graphics card make and model.
- General specs such as RAM, processor speed, etc.
|
By AKrishna - 6/4/2021
We have some footage of the bug:
https://4xdk5geps1hgl8wg.myfritz.net:47219/nas/filelink.lua?id=da2d0729aa03b7d5
Specs for the PC in the video are attached. I'll try to get the specs of some of the other systems as well!
|
By Dave - 6/4/2021
+x
What's the installed driver version for the Intel HD 520 graphics adapter?
Double-click the entry in the device manager, then go to the Driver tab, and driver date and version should be listed there.
Also, what's the Inquisit version installed / used, please? If you're running this in Inquisit Lab, that information is available via Help->About.
If using the web version / player, open the player, and the information is at the bottom of the Home / Browse tab:
|
By AKrishna - 6/4/2021
+x+x What's the installed driver version for the Intel HD 520 graphics adapter? Double-click the entry in the device manager, then go to the Driver tab, and driver date and version should be listed there. Also, what's the Inquisit version installed / used, please? If you're running this in Inquisit Lab, that information is available via Help->About. If using the web version / player, open the player, and the information is at the bottom of the Home / Browse tab:
Oh - sorry, it's Inquisit 6.4.2, we re-installed just before testing. I'll check out the driver version for you!
|
By AKrishna - 6/4/2021
Driver date on the PC in the footage: October 20, 2016; version 21.20.16.4541
In contrast, I DON'T have the issue on my PC:
Inquisit 6.4.2 64bit (build 6307)
Windows 10 Pro Build 19042
Intel Core i7-5960X
32GB RAM
Geforce GTX980 graphics card, driver version 27.21 14.6109 (December 31, 2020)
|
By Dave - 6/4/2021
+xDriver date on the PC in the footage: October 20, 2016; version 21.20.16.4541 In contrast, I DON'T have the issue on my PC: Inquisit 6.4.2 64bit (build 6307) Windows 10 Pro Build 19042 Intel Core i7-5960X 32GB RAM Geforce GTX980 graphics card, driver version 27.21 14.6109 (December 31, 2020)
The driver on the affected system is fairly ancient and outdated, and a driver bug is a distinct possibility. According to Intel's website, the latest release available for the HD 520 is driver version 27.20.100.9466 (date: 05/14/2021):
https://www.intel.com/content/www/us/en/support/products/88355/graphics/graphics-for-6th-generation-intel-processors/intel-hd-graphics-520.html
Please try updating to that driver and let me know if the issue persists after doing so.
One more question for clarification: The script run on the affected system is the exact same one you provided in this thread, correct? I'd like to rule out that we're looking at slightly different bits of code, with a subtle mistake in one version, but not the other.
|
By Dave - 6/4/2021
+x+xDriver date on the PC in the footage: October 20, 2016; version 21.20.16.4541 In contrast, I DON'T have the issue on my PC: Inquisit 6.4.2 64bit (build 6307) Windows 10 Pro Build 19042 Intel Core i7-5960X 32GB RAM Geforce GTX980 graphics card, driver version 27.21 14.6109 (December 31, 2020) The driver on the affected system is fairly ancient and outdated, and a driver bug is a distinct possibility. According to Intel's website, the latest release available for the HD 520 is driver version 27.20.100.9466 (date: 05/14/2021): https://www.intel.com/content/www/us/en/support/products/88355/graphics/graphics-for-6th-generation-intel-processors/intel-hd-graphics-520.htmlPlease try updating to that driver and let me know if the issue persists after doing so. One more question for clarification: The script run on the affected system is the exact same one you provided in this thread, correct? I'd like to rule out that we're looking at slightly different bits of code, with a subtle mistake in one version, but not the other.
Adding: If you don't want to install the non-branded Intel driver, the Dell support portal for your system should also offer a more recent OEM driver version (these typically lag a little behind the Intel releases, but can contain OEM customizations integrating them with other Dell-proprietary features on the system, such as hotkey integration).
|
By AKrishna - 6/4/2021
A driver update to the current Intel build changed nothing, the error persisted.
And yes - the uploaded script is the same as the one being used in the testing, as is the picture.
|
By Dave - 6/4/2021
+xA driver update to the current Intel build changed nothing, the error persisted. And yes - the uploaded script is the same as the one being used in the testing, as is the picture.
Alright, I've compiled all the information into a bug report. We'll have to see if we can find some system among ours on which the problem is reproducible (no luck with that yet).
If you get the specs from the other systems you've observed this on, please add them here.
|
By Dave - 6/7/2021
+x+xA driver update to the current Intel build changed nothing, the error persisted. And yes - the uploaded script is the same as the one being used in the testing, as is the picture. Alright, I've compiled all the information into a bug report. We'll have to see if we can find some system among ours on which the problem is reproducible (no luck with that yet). If you get the specs from the other systems you've observed this on, please add them here.
We're not having any luck trying to reproduce the issue. To help us narrow down potential causes, it would be great if you could try the following on the affected Dell machine and report back the result:
Set values.TimeInMSBetweenAnimationHops to twice the nominal refresh interval reported by the system, i.e.
<values>
...
/ TimeInMSBetweenAnimationHops = 2*display.refreshinterval
...
</values>
This will obviously slow down the animation and make it choppy, but it would be very helpful to know whether the text layer is still being omitted on some trials or whether it is displayed reliably with a longer hop time.
|
By AKrishna - 6/14/2021
+x+x+xA driver update to the current Intel build changed nothing, the error persisted. And yes - the uploaded script is the same as the one being used in the testing, as is the picture. Alright, I've compiled all the information into a bug report. We'll have to see if we can find some system among ours on which the problem is reproducible (no luck with that yet). If you get the specs from the other systems you've observed this on, please add them here. We're not having any luck trying to reproduce the issue. To help us narrow down potential causes, it would be great if you could try the following on the affected Dell machine and report back the result: Set values.TimeInMSBetweenAnimationHops to twice the nominal refresh interval reported by the system, i.e. <values> ... / TimeInMSBetweenAnimationHops = 2*display.refreshinterval ... </values> This will obviously slow down the animation and make it choppy, but it would be very helpful to know whether the text layer is still being omitted on some trials or whether it is displayed reliably with a longer hop time.
Haven't been able to test this yet, but will do so hopefully later today. For now, the specs of another affected system:
Windows 10 Build 19042
Intel Core i5-10210U
16 GB RAM
Intel UHD Graphics, driver version 26.20.100.7985
Resolution: 1920 x 1080 x 60 Hz
|
By AKrishna - 6/14/2021
+x+x+xA driver update to the current Intel build changed nothing, the error persisted. And yes - the uploaded script is the same as the one being used in the testing, as is the picture. Alright, I've compiled all the information into a bug report. We'll have to see if we can find some system among ours on which the problem is reproducible (no luck with that yet). If you get the specs from the other systems you've observed this on, please add them here. We're not having any luck trying to reproduce the issue. To help us narrow down potential causes, it would be great if you could try the following on the affected Dell machine and report back the result: Set values.TimeInMSBetweenAnimationHops to twice the nominal refresh interval reported by the system, i.e. <values> ... / TimeInMSBetweenAnimationHops = 2*display.refreshinterval ... </values> This will obviously slow down the animation and make it choppy, but it would be very helpful to know whether the text layer is still being omitted on some trials or whether it is displayed reliably with a longer hop time.
Increasing the time between animation hops in this way did NOT solve the issue on at least one affected system (the one with the old Intel driver). The zoom effect was visibly slower as expected, but the word still flickered and there were still "jumps" in the zoom.
|
By Dave - 6/14/2021
+x+x+x+xA driver update to the current Intel build changed nothing, the error persisted. And yes - the uploaded script is the same as the one being used in the testing, as is the picture. Alright, I've compiled all the information into a bug report. We'll have to see if we can find some system among ours on which the problem is reproducible (no luck with that yet). If you get the specs from the other systems you've observed this on, please add them here. We're not having any luck trying to reproduce the issue. To help us narrow down potential causes, it would be great if you could try the following on the affected Dell machine and report back the result: Set values.TimeInMSBetweenAnimationHops to twice the nominal refresh interval reported by the system, i.e. <values> ... / TimeInMSBetweenAnimationHops = 2*display.refreshinterval ... </values> This will obviously slow down the animation and make it choppy, but it would be very helpful to know whether the text layer is still being omitted on some trials or whether it is displayed reliably with a longer hop time. Increasing the time between animation hops in this way did NOT solve the issue on at least one affected system (the one with the old Intel driver). The zoom effect was visibly slower as expected, but the word still flickered and there were still "jumps" in the zoom.
Thanks for taking the time to test (also regarding the other, progress bar / shape sizing issue; https://www.millisecond.com/forums/FindPost31710.aspx ). My guess is that the two are indeed related, and I suspect the ultimate cause is some misinterpretation of the calculated size values happening due to confustion about the decimal separator ("," vs ".") either at the driver-level or somewhere deep inside the engine. Your test results should give us enough to go on and either fix (if it's engine-level) or work around (if it's driver-level) that in the next update.
|
By erikb - 6/15/2021
This turns out to be another case where appending a size indicator via string manipulation running afoul of the local locale. In this particular case replace all the concat(value, "%") code with display.getpixelsx(value):
In the attached scripts case modify the relevant <expressions> to the following:
/ AATTargetStimulusXSize = if (expressions.MovementDirection == "Approaching") display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 + values.HopCounter*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding") display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 - values.HopCounter*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
else display.getpixelsx(values.StartingAATTargetTextHeightInPercent)
/ AATTargetStimulusXSizeForError = if (expressions.MovementDirection == "Approaching" && script.currentblock == "PracticeAAT" && !values.ErrorFeedbackInPracticePhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 + values.NumZoomSteps*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding" && script.currentblock == "PracticeAAT" && !values.ErrorFeedbackInPracticePhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 - values.NumZoomSteps*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Approaching" && script.currentblock == "AAT" && !values.ErrorFeedbackInSRBindingPhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 + values.NumZoomSteps*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding" && script.currentblock == "AAT" && !values.ErrorFeedbackInSRBindingPhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 - values.NumZoomSteps*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
else display.getpixelsx(values.StartingAATTargetTextHeightInPercent)
/ BGPicXSize = if (expressions.MovementDirection == "Approaching") display.getpixelsx(values.StartingBGPicWidth * (1 + values.HopCounter*(values.FinalZoomFactorBGPic-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding") display.getpixelsx(values.StartingBGPicWidth * (1 - values.HopCounter*(1-1/values.FinalZoomFactorBGPic)/values.NumZoomSteps))
else display.getpixelsx(values.StartingBGPicWidth)
and things should work as expected regardless of the locale.
The next release will at least issue a warning that the person running the experiment will see if Inquisit fails to parse a size.
|
By Dave - 6/15/2021
+xThis turns out to be another case where appending a size indicator via string manipulation running afoul of the local locale. In this particular case replace all the concat(value, "%") code with display.getpixelsx(value): In the attached scripts case modify the relevant <expressions> to the following: / AATTargetStimulusXSize = if (expressions.MovementDirection == "Approaching") display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 + values.HopCounter*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding") display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 - values.HopCounter*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
else display.getpixelsx(values.StartingAATTargetTextHeightInPercent)
/ AATTargetStimulusXSizeForError = if (expressions.MovementDirection == "Approaching" && script.currentblock == "PracticeAAT" && !values.ErrorFeedbackInPracticePhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 + values.NumZoomSteps*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding" && script.currentblock == "PracticeAAT" && !values.ErrorFeedbackInPracticePhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 - values.NumZoomSteps*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Approaching" && script.currentblock == "AAT" && !values.ErrorFeedbackInSRBindingPhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 + values.NumZoomSteps*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding" && script.currentblock == "AAT" && !values.ErrorFeedbackInSRBindingPhaseInsteadOfZoom) display.getpixelsx(values.StartingAATTargetTextHeightInPercent * (1 - values.NumZoomSteps*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
else display.getpixelsx(values.StartingAATTargetTextHeightInPercent)
/ BGPicXSize = if (expressions.MovementDirection == "Approaching") display.getpixelsx(values.StartingBGPicWidth * (1 + values.HopCounter*(values.FinalZoomFactorBGPic-1)/values.NumZoomSteps))
else if (expressions.MovementDirection == "Avoiding") display.getpixelsx(values.StartingBGPicWidth * (1 - values.HopCounter*(1-1/values.FinalZoomFactorBGPic)/values.NumZoomSteps))
else display.getpixelsx(values.StartingBGPicWidth)
and things should work as expected regardless of the locale.
The next release will at least issue a warning that the person running the experiment will see if Inquisit fails to parse a size.
Erik beat me to the punch while I was still working on this. Note that the code provided by Erik will result in slightly to noticeably larger text sizes compared to the original code. A/B testing, I am getting identical results with the below alternative, which should (and does, on my systems) work regardless of locale / regional format settings.
<expressions>
/ AATTargetStimulusXSize = if (expressions.MovementDirection == "Approaching") {
1pct*(values.StartingAATTargetTextHeightInPercent * (1 + values.HopCounter*(values.FinalZoomFactorText-1)/values.NumZoomSteps));
} else if (expressions.MovementDirection == "Avoiding") {
1pct*(values.StartingAATTargetTextHeightInPercent * (1 - values.HopCounter*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps));
} else {
1pct*(values.StartingAATTargetTextHeightInPercent);
};
/ AATTargetStimulusXSizeForError = if (expressions.MovementDirection == "Approaching" && script.currentblock == "PracticeAAT" && !values.ErrorFeedbackInPracticePhaseInsteadOfZoom) {
1pct*(values.StartingAATTargetTextHeightInPercent * (1 + values.NumZoomSteps*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
} else if (expressions.MovementDirection == "Avoiding" && script.currentblock == "PracticeAAT" && !values.ErrorFeedbackInPracticePhaseInsteadOfZoom) {
1pct*(values.StartingAATTargetTextHeightInPercent * (1 - values.NumZoomSteps*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
} else if (expressions.MovementDirection == "Approaching" && script.currentblock == "AAT" && !values.ErrorFeedbackInSRBindingPhaseInsteadOfZoom){
1pct*(values.StartingAATTargetTextHeightInPercent * (1 + values.NumZoomSteps*(values.FinalZoomFactorText-1)/values.NumZoomSteps))
} else if (expressions.MovementDirection == "Avoiding" && script.currentblock == "AAT" && !values.ErrorFeedbackInSRBindingPhaseInsteadOfZoom) {
1pct*(values.StartingAATTargetTextHeightInPercent * (1 - values.NumZoomSteps*(1-1/values.FinalZoomFactorText)/values.NumZoomSteps))
} else {
1pct*(values.StartingAATTargetTextHeightInPercent)
};
/ BGPicXSize = if (expressions.MovementDirection == "Approaching") {
1pct*(values.StartingBGPicWidth * (1 + values.HopCounter*(values.FinalZoomFactorBGPic-1)/values.NumZoomSteps))
} else if (expressions.MovementDirection == "Avoiding") {
1pct*(values.StartingBGPicWidth * (1 - values.HopCounter*(1-1/values.FinalZoomFactorBGPic)/values.NumZoomSteps))
} else {
1pct*(values.StartingBGPicWidth)
};
</expressions>
|
|