Introduction

Some significant changes were implemented in the E-Prime Extensions for Tobii (EET) version 3.2.1.105 (henceforth referred to as 3.2) compared to previous EET versions. These changes concern both the implementation of the package in E-Prime and the data that is outputted. In this document important changes in the data and a bug in the implementation of the package in E-Prime are described. More information on how to implement EET 3.2 in E-Prime can be found here.

Gazedata filename

In EET 2 and EET 3.1 the gazedata file has the following name:
[Experiment]-[Subject]-[Session].gazedata

In EET 3.2 the gazedata file has the following name:
[Experiment]-[Subject]-[Session]-GazeData.txt

Both files are tab delimited text files, that can be read with for example Excel.

Validity

The meaning of the validity ratings of gaze samples have changed in comparison to EET 2.

EET 2 validity ratings:

• 0 = The system is certain that it has recorded all relevant data for the particular eye and that the data belongs to the particular eye.
• 1 = The system has only recorded one eye and has made some assumptions and estimations regarding if the recorded eye is left or right. However, it is still highly probable that the estimations done are correct.
• 2 = The system has only recorded one eye and has no way of determining if this is the left or the right eye.
• 3 = The system is fairly confident that the actual gaze data is incorrect or corrupted.
• 4 = The actual gaze data is missing or incorrect.

EET 3.1 and EET 3.2 validity ratings:

• 0 = Valid data was not recorded on this sample and eye .
• 1 = Valid data was observed for this sample and eye.

Pupil diameter values

• In EET 2 gazedata files the pupil diameter columns can only contain a positive value (pupil diameter) or -1 (invalid sample), regardless of eye-tracker. Important: pupil data measured with the X3-120 eye-tracker contains pupil data measured with both bright and dark modes of tracking. This pupil data is very noisy and therefore the combination of E-Prime 2, EET 2 and the Tobii X3-120 should not be used.
• In EET 3.1 and eye-tracker X2-60 gazedata files, the pupil diameter columns can contain a positive value (pupil diameter) or -1.#IND (invalid sample).
• In EET 3.1 and eye-tracker X3-120 gazedata files, the pupil diameter columns can contain a positive value (pupil diameter), -1.#IND (invalid sample), or -1 (sample was measured with dark mode and thus pupil size is not reported).
• In EET 3.2 and eye-tracker X2-60 gazedata files, the pupil diameter columns only contain a positive value (pupil diameter) or -1.#IND0 (invalid sample).
• In EET 3.2 and eye-tracker X3-120 gazedata files, the pupil diameter columns can contain a positive value (pupil diameter), -1.#IND0 (invalid sample), or -1 (sample was measured with dark mode and thus pupil size is not reported).

Different meaning of the CurrentObject variable

The CurrentObject variable in EET 3.2 is different from the CurrentObject variable of previous EET versions. The CurrentObject variable in EET 3.2 holds the object presented on screen, ONLY WHEN THE PARTICIPANT IS LOOKING AT THE SCREEN, whereas the CurrentObject variable in previous EET versions holds the object presented on screen, regardless of whether the participant was looking at the screen or not. PST has reported that this different meaning of the CurrentObject variable is intended and not a bug. For a workaround in which a different variable is created that does save the object presented on screen, regardless of whether the participant was looking at the screen or not, see E-Prime an Tobii. 

TETGazeDataSave must be the last object in the procedure

Placing objects after a GazeDataSave package call causes -999 error during runtime. PST has confirmed that this is a bug, see here. The error occurs because E-Prime checks whether the CurrentObject being logged is “valid”. Part of checking the validity is asking if the object’s OnsetTime > 0 at the time the GazeDataSave script is executing. When the GazeDataSave package call is located before the last object, this is not the case, and E-Prime will crash.

The following structure is thus not possible:

Workaround:

• Place the GazeDataSave package call at the end of the procedure.
• When this is not possible (e.g. when the structure in the picture is used), assign a dummy OnsetTime to the object(s) located after the GazeDataSave package call. This dummy OnsetTime should be a large number (PST suggests to use 2147483646). When the object executes, this dummy’s OnsetTime is overwritten by the actual OnsetTime.