The E-Basic compiler has a finite amount of room to store string literals (i.e. text entered between quotation marks) and object compiled code. For example, every place the script generates Object.Property = "this is the value" will reduce this amount. Once this room has been used up, a "script is too large to be compiled" error will occur.
Many times, the design of the experiment causes a large amount of script to occur (e.g. too many unnecessary objects, objects with large amounts of text entered into their Text property). Simply changing the design of the experiment will reduce the chances of running up against the compiler limit and will typically make the experiment easier to manage (see examples below).
The following steps can be used to avoid receiving the "script is too large to be compiled" error:
1) Upgrade to E-Prime 1.2. There has been updates to how many of the E-Objects generate their E-Basic script, which significantly reduces the chances for the compiler error.
2) Take the time to design your experiment before implementing it. A number of the "script too large" errors can be reduced by simply changing the design of the experiment, which in turn makes the experiment easier to manage. For a list of general guidelines, please see INFO: E-Basic Style Guidelines/Recommendations
3) Ensure all List objects have their LoadMethod property set to Embedded (located on the General tab of the List's property pages).
4) When presenting a lot of text (e.g. instructions screens), attempt to store the text in a List attribute. Then, reference the attribute in the TextDisplay/SlideText object's Text property (i.e. instead of typing the text directly into the Text property). This reduces the number of string literals that must be generated.
5) Attempt to reduce the number of objects in the experiment. Keep in mind that it is very rarely necessary to create more than one object to present your stimuli. That is, unless two objects are completely different (e.g. they are collecting responses from different devices), there are very few cases where creating a new object would be preferred over using attribute references to vary a single object's properties.
Example 1: On trial 1 of a lexical decision task, a TextDisplay will be used to present the word "dog" for 1000ms. On trial 2, a TextDisplay will be used to present the word "jop" for 1500ms. Both trials will collect a 1 (word) or 2 (non-word) response from the keyboard. In this situation, there is no reason to create two separate TextDisplay objects. Instead, simply create two attributes in your TrialList. One attribute will hold the stimulus itself (e.g. "dog" or "jop"), while the other will hold the object duration (e.g. 1000 or 1500). Reference each attribute in its corresponding property within the single TextDisplay. The TextDisplay will present the appropriate stimulus on each time for the appropriate duration.
Example 2: In the same lexical decision task, trials will be broken up into two blocks. The experiment structure uses two Lists (e.g. TrialList1 and TrialList2). TrialList1 calls TrialProc1, which runs the Fixation1 object (i.e. fixation cross for 1000ms), the Stimulus1 object (i.e. stimulus that terminates upon a response), and the Feedback1 object. TrialList2 calls TrialProc2, which runs the Fixation2 object (i.e. fixation cross for 1000ms), the Stimulus2 object (i.e. stimulus that terminates upon a response), and the Feedback2 object. In this situation, the two separate Procedures are unnecessary. The Procedures themselves are identical (i.e. they both run the same number and type of objects), and the objects on each Procedure are also identical (i.e. same properties). This creates a large amount of unnecessary script. Here, it is recommended that TrialList1 and TrialList2 simply call the same Procedure. The stimuli will still be split between two blocks, but will use the same objects rather than two separate sets of objects.