SimSt Config File

SimStudent comes with a text file simSt-config.txt. This file can be changed to personalize many of the options within SimStudent, especially for use in different domains. This is less to turn features on and off (which is done in the script to run SimStudent), and more to set the text and descriptive display options of the session.

Each section is started by a header (startStateElements, componentNames, quizProblems, examples, mistakeExplanations, problemChoiceExplanations, hintExplanations) and different sections are separated by a blank line.

startStateElements

This serves as the header for items which are unlocked when entering a new problem. All of them must be filled in before a new problem can be started. Each component name is on a different line after the header.

componentNames

This serves as the header for providing an alternative text for how components are described. Each of these descriptions is on a different line, and the first word of it is a regex to match any component names the replacement should be made for. Any further words are the description that should replace it, including any preposition, if appropriate. For example, the line 'dorminTable1_C.R. on the left-hand side' will describe any component in table1 as being on the left-hand side, regardless of column or row number. Descriptors should fit in the sentence 'I entered value descriptor.' sensibly. (ie I entered 3 on the left-hand side.)

quizProblems

This serves as the header for the different problems given to SimStudent on the quiz. Each problem is listed on a different line, in the order that they will be given. Problems are parsed into the different start state elements, split by the equal signs.

examples

This is the header for the different examples. Separate examples, which will appear on different tabs, are separated by a line with only a period. If the example starts with a 'text:', the text after that will appear in the dialog window when viewing the example. It is a good place to explain the example. Any other lines describe what to fill in to the interface's dorminTables. Each line describes a different filled-in component and is split in two by a %. Before the % is a 3-part segment of tableNumber columnNumber rowNumber, separated by #'s (eg 0#0#2). After the % is the value which is placed in that component.

explanations

There are three headers that fit under explanations, all of which have the same format. They are used only if selfExplanation is enabled. Questions are separated by a line with only a period. One of the questions is selected randomly from under the appropriate header when an event occurs which calls for that type of explanation. The question itself starts with 'text:', and any possible choices for answers to that question each appear on a separate line after it. If no answer choices are given, the question will take a free text response. If no questions are given for a particular header, or that header is not present, no question will be asked for that event.

Answer lines have two parts, separated by a colon (:). After the colon is the text of the answer which should appear in the drop-down menu. Before the colon are the conditions under which that answer should be available. A single standard condition is a string segment which must appear in the skill name that the event is related to. For example, add as a condition would match add, add-typein, badd. If prefaced by a !, the condition is that the skill name must not contain that string segment. Multiple conditions can be combined with commas and all of them must be met. Within a condition, an or can be used with a semi-colon. For example, multiply;divide will match either multiply or divide; both need not be present. As a full answer example: '!typein,add;subtract:Because I said so.'. If this answer line is listed after a question, 'Because I said so.' will show up as a possible choice for that question whenever the skill does not include the text 'typein', but does include either 'add' or 'subtract'. If there are no conditions listed (The answer line starts with a colon.), that answer will always show up any time that question shows up.

Answer and question text can also use context in one of two ways. There are six macro values represented by match symbols, which will be automatically replaced with relevant values. They are:

(E) - This will be replaced by an example from a previous time that that skill was used, including the state of the FOAs at that time. For example, if a student previously put divide 3 when the foas were 3x and 9, the (E) might be replaced by "divide 3 when 3x=9". This would show up when the skill divide is used. The exact wording will be determined by the foaGetter.

(I) - This will be replaced by the input relevant to the event.

(#) - This will be replaced by the operand of the input. That is, if there is a space in the input, the value after the space. If there is not a space in the input, the entire input.

(O) - This will be replaced by the operator of the input. That is, if there is a space in the input, the value before the space. If there is not a space in the input, the entire input.

(P) - This will be replaced by the current problem step.

(F) - This will be replaced by the most relevant term in the FOA. If the input is a transformation, the operand of that transformation will be used to match to the FOA, and the closest matching term will be used from either FOA. If the input is not a transformation, a transformation in one of the FOA would be used to match to the other FOA. Failing to find a term match, the first whole FOA would be used. As an example: FOA: 3x-5, 8. Input: add 5. (F) would get '-5'. A second example: FOA 4x, 3. Input: divide 4. (F) would get '4x'.

In addition to the macro values, operations can also be used. Any of the operations which are listed in operations.txt are valid. Operations are surrounded by < >. Within the angle brackets, the first word is the name of the operator, as it is used by jess (and set by setName in the operator definition). Arguments to the operator are separated by spaces within the brackets. For example: <add-term 2x 3x> would be replaced by 5x after the operator is executed. Multi-word arguments can be defined by putting quotation marks around them. For example: <get-operand "divide 3"> would result in 3, and <get-operand "(I)"> could be used in place of (#). If the operator cannot find an answer/returns null, or if the operation fails to parse correctly, the answer option will not be available in the drop-down. All macro values are replaced before any operations are run, so they can be used as arguments as appropriate. For example: <coefficient (F)> will be replaced with the coefficient of the most relevant FOA term, if it has a coefficient, or the option will not show up.

problemChoiceExplanations

This is the header for explanation questions which should come up right after a new problem is entered. (P) is the only macro available as there is no input, FOA or skill associated with starting a new problem. It is also appropriate that all answer choices start with a colon and have no conditions for this explanation type, as there is no skill for any conditions to be met. These questions are designed to be of the type "Why did you choose this problem?"

mistakeExplanations

This is the header for explanation questions which should come up after all of the activations in the activation list have failed for a particular step. The input, FOA and skill will be the ones for the last activation which was asked about and denied. These questions are designed to be of the type "Why is that input wrong?"

hintExplanations

This is the header for explanation questions which should come up after the student has demonstrated a step for SimStudent. It will only come up if a mistakeExplanation question has not already been asked on that step. The input, FOA and skill will be the ones for the hint that the student has just entered. These questions are designed to be of the type "Why did you do that input?"