If there are multiple linked response items in a sequence, only the first works

[smathot]

Take for example the following sequence:

• sequence
  • keyboard_response
  • keyboard_response

This sequence will end after 1 keypress, which triggers both linked copied of keyboard_response. The problem goes away if you use unlined copies, like so:

• sequence
  • keyboard_response_1
  • keyboard_response_2

The problem also occurs for sketchpad items with 'keypress' duration.

[shyras]

This problem is caused due to the fact that for linked items at this moment there is only one unique item in the item store. In the prepare phase of an item derived from the general_response derived item the response settings are initialized. At this moment this is conducted in the preapre phase of an sequence. This means that for example 'keyboard_response' is prepared twice. When the run phase starts the 'keyboard_response' is ran twice but remembers the response settings of the first run. There are two ways to solve this, buy that depends on how we want the use linked items.

Solution 1 - create unique instances for each linked item (Although this could conflict with the definition within the item store)
Solution 2 - move the response preparation to the run phase (this could conflict with setting variabe settings)

Could you tell me how this is down at this moment in OpenSesame itself?

[smathot]

Could you tell me how this is down at this moment in OpenSesame itself?

That's an interesting question, because it points out that this is also fragile in OpenSesame. Essentially, it's not a problem in OpenSesame, because if you run one item, you can run it again without problem. Similarly, you can prepare an item that was already prepared without problem. However, as soon as an item would do something during the run phase that would require another prepare, the same problem would arise as in osweb. (But currently no items do that.) Does that make sense?

For now, I think it's sufficient if we simply disallow, in osweb, multiple linked copies of the same item in one sequence, and throw a clear error message when this happens. That way the behavior of osweb is at least predictable. (And I don't see how any of the two solutions would really be satisfying.)

What do you think?

[shyras]

For now that will suffice, but i want to try to solve this in the future
because I think there are many people using linked copies (at least in our
faculty).

[dschreij]

This is also a problem for the log files because the column labels depend on the item names right? So unless you call the logger after each recorded response, the second run of the response item will overwrite the first one, and only the value of the second call will be logged.

[dschreij]

This problem also affects the logger item. If 2 instances of the same logger item are found in a sequence, the experiment freezes at the moment that the second logger item should run...

For now, I think it's sufficient if we simply disallow, in osweb, multiple linked copies of the same item in one sequence, and throw a clear error message when this happens.

Does this also hold for items that don't have problems when being called multiple times? For canvases it's pretty common to show them multiple times in a sequence (such as fixation crosses) and these don't appear to generate problems. So for what items should an error be shown?

• reponse items
• logger
• ...

[smathot]

I feel that for now we should be pragmatic and disallow linked items in the same sequence with a clear error message. I just ran into this with someone who was implementing an experiment, and it seems like a pretty mysterious crash.