Trial Port display milliseconds are off

Back

Trial Port display milliseconds are off

Author	Message
Dave	Dave posted 11 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 103K	A /branch need not be conditional. Suppose you have <trial a1> and <trial a2>. You always want a2 to follow a1: <trial a1> [...] / branch = [trial.a2] </trial>
	Reply Like 160
Lostcode	Lostcode posted 11 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 29, Visits: 1	Real quick. If I do a / branch [if() trial.whatever] is there a command for to say like if(trial.whatever1.runs) trial.whatever2? <--- meaning if trial whatever1 ran then run trial whatever2 Or do I need to setup a count or a generic value that it will reference that will always make it run the next trial?
	Reply Like 153
Lostcode	Lostcode posted 11 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 29, Visits: 1	I'll check back through my versions after fixing this current problem and send it to you if I still have it.
	Reply Like 148
Dave	Dave posted 11 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 103K	/ branch I have experienced trialduration complications when using this method. Like it would apply the trial duration from the last thing used to the duration of the next. I am not aware of any such issue and don't see why that would be. /branch has nothing to do with a given <trial>'s /trialduration. If you have any code showcasing that issue, please feel free to share it.
	Reply Like 153
Lostcode	Lostcode posted 11 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 29, Visits: 1	/ branch I have experienced trialduration complications when using this method. Like it would apply the trial duration from the last thing used to the duration of the next.
	Reply Like 139
Dave	Dave posted 11 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 103K	The /branch attribute fits the bill.
	Reply Like 149
Lostcode	Lostcode posted 11 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 29, Visits: 1	Any Recommendations for a daisy chain for it? The trial must always have the other trial occur after it because a block I have uses that trial and another one show up randomly.
	Reply Like 155
Dave	Dave posted 11 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 103K	Remember I want a response to be issued for both in the trial. A <trial> collects a single response. There is no way to collect two or more. You'll have to daisy-chain separate <trial> elements if that's what you want.
	Reply Like 164
Lostcode	Lostcode posted 11 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 29, Visits: 1	found the problem. I have my responsetime = 0 which is effecting the zeroPort showing for some reason. Remember I want a response to be issued for both in the trial. Trying to figure out how to allow only one response for the trial but can be responded for both the word and the erase I have set. The erase is a black screen. I remember reading the /responsetime attribute and the / responseinterrupt attribute. What would be needed here for what I require?
	Reply Like 153
Dave	Dave posted 11 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 13K, Visits: 103K	The green and red is a trial and then another green and red is either the same trial or one that's similar reading from a different item list. Could you clarify that graphically, please? The block uses a ratio of two trials. The trials are the same as the one posted. Is there something in the block that would screw with this? I cannot tell you that without seeing the actual code. Have you checked the two involved <trial> elements and their stimuli for errors? The data might well be consistent with an error in one of the involved elements. Also, (a) what is the system's refresh rate and (b) are you running the latest Inquisit 4 release (4.0.3)?
	Reply Like 184