Repeating Instance of Multi-Character Input
This is a cross between an OpenSesame and OSWeb question. I'm posting it here because I need the solution to work with OSWeb (i.e. Javascript, not Python).
I have an experiment where participants complete Task A, but sometimes are interrupted with Task B. After completing Task B, they return to Task A. I have this part all figured out.
When completing Task B, participants need to type their answer (numbers) and have it show up on the screen. I have this part figured out as well (thanks to Sebastiaan's post and code on collecting multi-character inputs).
The problem I'm having (possibly because I'm using Sebastiaan's code and don't know how to rework it) is that Task B has multiple parts, where participants have to do the same thing multiple times (i.e. see a math problem on the screen and type their answer so they can see it). I'm currently unable to make this "repeat" happen. I have attached a screenshot of the trial sequence with just 1 instance of Task B (this works).
I have attempted to copy everything in the red brackets below what is currently there to create a second instance, but it does not run. Only the first instance runs. I do not know if this is the best way to achieve this "repeat", but so far everything I have tried has failed.
Since everything in red is part of Task B, it all runs on "run if" statements in the trial sequence (which works).
I also use Sebastiaan's code at the beginning of the entire experiment for participants to enter a subject number, so this code sequence is used twice with no problem. It only seems to be an issue when I try to place two loops (with the "constants" inline script) right next to each other.
Thank you!
Elisabeth
Comments
When you say it must repeat, do you mean task B has to be executed multiple times (like in a loop) or at multiple, random times in the loop of doing task A?
If it is the first case, you probably best wrap a loop-sequence structure around your task B.
If it is the second case, you can use the run_if functionality and specify the trials at which task B should be inserted.
Does that make sense?
Eduard
Task B itself needs to loop at 1 time. For example: Task A --> [Task B1, Task B2, Task B3] --> Task A
Wrapping the entire thing in another loop may be the answer for me. I will try it and let you know. Task B does run at random times, but I already have the run_if statements configured correctly for what I need.
Elisabeth
I tried wrapping the loop up in another loop...does it work? Yes it does, it physically runs. But I'm still struggling to make it do what I want it to do.
The problem with this solution (visualized in the picture below) is that since the Task B loop is within the overall Trial Loop, the data output records multiple "trials" when Task B appears.
What happens is that during Trial #4, Task A is interrupted by Task B. Task B runs 5 times, and then Task A resumes. What I would like to have happen is to have each "instance" of Task B as a separate variable, but I'm not sure how to make that happen (or the best way to explain it).
I have tried putting a "Task B" variable in the outermost loop (Block_Loop) so that the variable is outside of the trial sequence (theoretically solving the "multiple trial" data problem). The problem with this is that I need multiple "Task B" variables (or so I think) - one for each unique instance, which again is fine with me. I assume that I need a unique sketchpad for each possible instance of Task B, but I can't get the multiple sketchpads to run correctly in the inner loop.
If this makes no sense, I can attach my experiment file and maybe that will help. If this just isn't possible in the way I'm thinking, I can make the current way work (with the messy data output), it will just take some extra data cleaning.
Thanks! Elisabeth
Hi Elisabeth,
Yes, existing variables are written every time you call a logger, even if their values don't change. Therefore, if your Block A variables are set to 4, they will stay at 4 and written to the logfile as 4 even during B blocks. Normally, this shouldn't be a problem though, because in the analysis, you can easily split your data in block A and block B, so that all the irrelevant block B lines in the logfile won't be a problem for a block A analysis. All you need is a variable that codes whether the current trial belongs to block B or block A.
Does that make sense, or am I misunderstanding you?
Eduard
Yes, that makes sense. I just didn't know if there was a way to change the way the data was logged based on how the variables were arranged. Thanks for the clarity!
Elisabeth