- This is a feature that never saw the light of day in this form, so get
rid of its vestigial remnants. (Note that this is NOT the l: print
formatter that causes the game to look up a string in the LANGUAGE
lump.)
- When trying to define a function with the -h switch, you previously
got two error messages on the token following the function, making it
unclear what the problem was. There is now only one error message at the
end of the function's parameter list.
- Script arrays are semantically identical to map arrays: They have fixed
sizes and can be multidimensional. They can also be initialized, although
this is just syntactic sugar. e.g.
int init_array[2] = { 10, 20 }
produces code identical to:
int init_array[2];
init_array[0] = 10;
init_array[1] = 20;
Script arrays are also implicitly initialized to 0, just like any other
variable in ACS.
- Unlike map arrays, they only exist for the life of the script, and each
script gets its own copy of the array.
- Script arrays exists in a separate space from script variables. I did
not repeat the bullshittery of map arrays here. (I still have no idea what I
was thinking when I designed them that way.)
- Each script and function that uses local arrays is recorded with a new
chunk: SARY for scripts and FARY for functions. The first two bytes are the
script/function number, and the rest of the chunk consists of four-byte
integers describing the size (in ints) of each array used by that
script/function. To determine how many arrays a script/function uses,
take the chunk length, subtract two, and divide by four.
- Fixed: You could not #define a string for use in a library, because it
was converted to a number at definition time and not at use time. This
is no longer the case. Symbolic constants now store the string in its
original form, and they now expand into the string when encountered
instead of their string table index.
- When this operator was added to the language, it never got added to the
constant expression path, so you could only use it in expressions
evaluated at runtime.
- SendExprCommand() evaluated all four of these as their inverse. I
wouldn't at all be surprised if this was caused by me fixing the
undefined behavior (Which PopExStk() is called first?) and not
even noticing that these were reversed because they popped off the stack
in reverse order.
- When SendExprCommand() evaluates constant expressions for || and &&,
it must explicitly pop both operands off the stack before pushing the
result. The compiler will do normal short-circuiting here, so if it only
needs one value to determine the result, only one would be popped off
the stack.
