Currentitemnumber not behaving as expected


Author
Message
LTK
LTK
Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)
Group: Forum Members
Posts: 15, Visits: 72
I'm working on a task that presents a pre-determined sequence of stimuli, followed by a message that says whether they gain or lose points for the participant. Earlier I had separate trials for 'gain' and 'loss' trials, but given that the order I need to present them in varies per participant, I think I have to use one trial type so that it can take a single item list as input. 

However, while trying to convert the two trial types into one, I ran into a problem. I tried to determine the stimulus that is presented on the current trial and based on that, change the message that appears indicating gain or loss. The trial code is as follows:

<trial acquisition>
/ stimulustimes = [0=expquaddle; 3000=result; 7000=clearscreen]
/ ontrialbegin = [
if ( picture.expquaddle.currentitemnumber >= 11 )
values.currentcsvalue = parameters.secondcsvalue;
else values.currentcsvalue = parameters.firstcsvalue;
]
/ timeout = 9000
</trial>


Items 1 through 10 represent gain (coded in parameters.firstcsvalue), and items 11 through 20 represent loss (coded in parameters.secondcsvalue). At 3000 ms 'result' would then display the value of the stimulus as recorded by values.currentcsvalue. So I expected the program to display the value of the presented stimulus, however, it presented the value of the previous stimulus instead. Is this the intended behavior, and is there a simple way to display this correctly? It's possible to split it up into two trials but that seems to defeat the purpose of having the /ontrialbegin function.
Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 98K
LTK - 7/2/2021
I'm working on a task that presents a pre-determined sequence of stimuli, followed by a message that says whether they gain or lose points for the participant. Earlier I had separate trials for 'gain' and 'loss' trials, but given that the order I need to present them in varies per participant, I think I have to use one trial type so that it can take a single item list as input. 

However, while trying to convert the two trial types into one, I ran into a problem. I tried to determine the stimulus that is presented on the current trial and based on that, change the message that appears indicating gain or loss. The trial code is as follows:

<trial acquisition>
/ stimulustimes = [0=expquaddle; 3000=result; 7000=clearscreen]
/ ontrialbegin = [
if ( picture.expquaddle.currentitemnumber >= 11 )
values.currentcsvalue = parameters.secondcsvalue;
else values.currentcsvalue = parameters.firstcsvalue;
]
/ timeout = 9000
</trial>


Items 1 through 10 represent gain (coded in parameters.firstcsvalue), and items 11 through 20 represent loss (coded in parameters.secondcsvalue). At 3000 ms 'result' would then display the value of the stimulus as recorded by values.currentcsvalue. So I expected the program to display the value of the presented stimulus, however, it presented the value of the previous stimulus instead. Is this the intended behavior, and is there a simple way to display this correctly? It's possible to split it up into two trials but that seems to defeat the purpose of having the /ontrialbegin function.

/ontrialbegin occurs *before* stimulus selection happens, that's why you're getting the number from the previous trial. This has to be so, because otherwise you wouldn't be able to e.g. determine which stimulus the trial is going to display per /ontrialbegin. So what you are seeing is the expected behavior.

Whether there's a good way around this in the case at hand, I cannot say based on an isolated code snippet. Assuming there aren't any other snags with how the relevant <picture> element is set up selection-wise, nextindex is what you'll want to use.

<trial acquisition>
/ stimulustimes = [0=expquaddle; 3000=result; 7000=clearscreen]
/ ontrialbegin = [
if ( picture.expquaddle.nextindex >= 11 )
values.currentcsvalue = parameters.secondcsvalue;
else values.currentcsvalue = parameters.firstcsvalue;
]
/ timeout = 9000
</trial>

https://www.millisecond.com/support/docs/v6/html/language/properties/nextindex.htm


Edited 3 Years Ago by Dave
LTK
LTK
Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)Associate Member (181 reputation)
Group: Forum Members
Posts: 15, Visits: 72

Okay, that does make sense. Nextindex does fulfill this function, thanks.
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Explore
Messages
Mentions
Search