[open] save responses into block variable table
Hi,
another question:
I'd like to save responses to comparison of pairwise items independently of the keys I assigned into the "allowed_responses" variable.
Therefore I need to access this variable from an inline-script, to later define for example
if response == "f":
standardized_response = 0 if response == "j":
standardized_response = 1
Is there any way to do that?
Related to that to that question is the last entry of this
Comments
Certainly. You can use the self.get() and exp.set() as described here
So basically, you would insert an inline_script after your response item that looks somewhat like this:
if self.get('response') == "f": exp.set('standardized_response', 0) elif self.get('response') == "j": exp.set('standardized_response', 1)Cheers!
Check out SigmundAI.eu for our OpenSesame AI assistant!
Hi, Sebastian,
okay, this way would work, but do I have the possibilty to access the allowed_keys variable, to make my code work even if I change input keys?
Best
There is a variable for the allowed keys, which you can access within an inline_script. It's called allowed_responses.
You could use an inline_script like the following:
# load allowed responses allowed = self.get("allowed_responses") # split allowed responses (these are separated by a semicolon) allowed = allowed.split(";") # recalculate to standardized response for option in range(0, len(allowed)): if self.get("response") == allowed[option]: self.experiment.set("standardized_response", option)In this script, first the allowed responses ("k;l") are accessed and separated and stored into a list variable (["k","l"]) called allowed.
After this, for every option in this list ("k" and "l"), it is checked if this is equal to the response (could be "k").
If this is the case ("k" == "k"), then the variable standardized_response is given the value corresponding to the place of this key in the keylist (for "k", this is 0, since Python starts counting at 0; for "l", this would be 1).
Does this help at all? If not, please leave another comment!
About local and global variables
I just want to add something about accessing variables that are defined in the interface.
With the exception of variables defined in a loop item, all variables that are set via the interface are local, meaning that they are available within, but never outside, a given item. Examples are the "duration" box in a sketchpad and the "allowed_responses" box in a keyboard_response. This is convenient because it allows you to present, for example, a sequence of sketchpads without their durations getting mixed up.
Because those variables are not made global, simply using
my_var = self.get("allowed_responses")in an inline_script will not work if you set 'allowed_responses' via the interface. You will get the following error message:
As you may have guessed, the solution is to make the variable global yourself. You can achieve this by either:
exp.set("allowed", "z;/")This allows you to:
(Note that you should not name your own global variable 'allowed_responses' because typing [allowed_responses] in the allowed responses box will give a recursion error.)
Retrieving local variables anyway
All the above being said, for plastic_students' specific situation it's probably best to retrieve the local variable in an inline_script anyway, because he wants the code provided by Sebastiaan to work even if he changes the allowed responses in the keyboard_response item.
So how would we do this? By specifically indicating from which item a variable has to be retrieved. Getting, for example, the variable 'allowed_responses' from a keyboard_response item called 'my_keyboard_response' in an inline_script item works like so:
allowed = exp.items["my_keyboard_response"].get("allowed_responses")And from here on, Edwin's code should work fine!
Note why this works, even when you have multiple keyboard_response items in your experiment: You use the item's name (which is unique) as a key to retrieve the desired item information.
Did you like my answer? Feel free to

Woops, my bad! I thought it was a global one. Should've checked first.
Thanks for the addition!