Sure.

By my count that's val_clamp, val_abs, store_sqrt, and store_pow. The fixed_point stuff isn't clear to me as yet, but I'll touch on it at the end.

**val_clamp** - This operation takes a value and forces it into a range. Whatever values the first argument may have had before, after the val_clamp it will be no lower than the second argument (the minimum value) and it will be strictly less than the third argument (the maximum value). This is 100% equivalent to calling (val_min, <value>, (<upper_bound> - 1)), then (val_max, <value>, <lower_bound>).

**val_abs** - Absolute value. If <value> is positive or zero, it's unchanged. If negative, the negative sign is stripped off, and the result (now positive) is returned.

**store_sqrt** - Square root. Stores the square root of the second argument. Note that this uses "fixed point" values, see below.

**store_pow** - Power or exponent. The comment in module_operations is incorrect for this - it's a copy-paste from store_sqrt above it. Raises one value to the power of a second value. The last argument is the exponent - the power - and the middle one is the base - the thing being squared, cubed, or otherwise exponentiated. Thus for example (store_pow, ":result", 5, 2) would put 25 into the result var - five squared.* If the last argument had been three instead, the result would be 125 - five cubed.

*[With a fixed_point_multiplier of 1 (the default), technically. You almost certainly don't want to ever use this operation with fixed_point_multiplier set to any other value unless that turns out to enable decimal values, and even then with extreme care. For example, 5^2 (= 25) is hardly equivalent to one-tenth of 50^20 (= almost 10 million billion billion billion)!]

As I said, fixed_point_multiplier is unclear to me. I'm still figuring out exactly how Armagan's using it. It appears to be a way to affect how much precision you obtain from various activities like square roots and position_get_x calls. For instance, it's clear that with a multiplier of 1, we're talking integer math and positions in *meters*, not centimeters. (I'm picturing ported Schattenlander potions flying kilometers away unless I get this right!) Thus if I were standing 275cm in Y from a scene prop, called a pair of (position_get_y) and subtracted them, I'd get an answer of 2. If I asked for the square root of twelve I'd get three. It appears that a fixed point multplier higher than this is used to get better precision, mostly for intermediate calculations since ultimately we still need an integer value. If I set the multiplier to 100 and did those two operations again, I'd get 275 from the position_y subtraction, and... um... 346 from the square root (root 12 = 3.64). In either case, if I didn't do anything else with it and just ran convert_from_fixed_point on my answer, the influence of the multiplier would go away; I'd end up with 2 and 3, respectively, again. What this lets us do, though, is add (say) a pair of square roots together, and lose less of our rounding in the process.

I think.