User Tools

Site Tools



Previous examples have already shown variables exist - the various things like @a, @b, @x and the like (for historical reasons, numeric local variables such as @1, @2, etc… were also valid). These are all just places to store values, using the ← operator, which takes a variable on the left and an expression on the right and stores it into the variable. These examples are local variables - variables that exist within the given dice roll/formula/etc… But what if you want something like keeping track of the stats of a character? There are also global variables. These look just like local variables (e,g, @STR), but you can’t change them via the ← operator (if you try, it makes a local variable instead). Instead, there are other parts of the UI that let you edit them (if you really need to change them, there is a special way to do so). The reason for this has a lot to do with the evolution of the Dicenomicon, as well as some unique features. Since dice take time to roll on the screen, we want to bunch together as many dice as possible, and hold off dealing with the results of this until they have finished rolling. Originally, this was done by evaluating the formula to find all the dice rolls, rolling them, looking at the results, and then re-evaluating the formula with those results. This means that there were side effects from the first pass which could interfere with the second (i.e., a global variable could be set in the first pass and then the new value used in the second pass to get the “real” results). As a result, there originally were no “side-effects” allowed from evaluating a formula - you got a value, and that was it. To set global variables, values from formulas included special “augmented” features, which included a list of side effects to perform. So when we did it the first time, we ignored these augmented side effects, and only when we did it the second did we apply them - in this case, to alter the global variable (there are other potential side effect actions as well such as playing a sound). With the current version of the Dicenomicon, there is internal support for values such as dice rolls that are “future promises” of values, and it knows how to handle those. In a future version of ELDARScript, these explicit side effects will be handled in a much cleaner fashion.


Suppose you have a nice formula, but want to reuse it, changing, for example, the number of dice rolled, or a target number that you are comparing it to. This is the purpose of parameters - variables that bound values when the user selects the formula. This puts them half way between a global variable and a local one. What’s more, there is an explicit UI presented that asks for what the value of these parameters should be, complete with a prompt and definition of possible valid values. Parameters look slightly different. For example: #1. Two things to note - the use of a pound sign to indicate a parameter, and the use of numbers instead of letters (this is primarily historical, but due to how they are used, it is difficult to change this - since they are parsed just like normal numeric constants, the use of letters would confuse things horrendously). Nearly any place you can have a constant numeric value, you can use a parameter. In some of those places you could use a local or global value (such as a value in an expression), but in many places you can’t (such as the number of dice to roll, or how many sides they have). Furthermore, these values are a constant - you aren’t allowed to change their value inside your formula. You can, however, initialize them to another value, so long as that value is based on a constant or another parameter. This is handy when you, for example, need to roll N dice and N-1 dice:

1. #2 #1 - 1.

2. if (#2Gd6) > #1Rd6 then

3. “Success”

4. else

5. “Failure”

6. end

Note how line 1 initializes the value of #2, while line 2 uses both #1 and #2 to determine how many dice to roll (the “R” and “G” indicate the color of the dice). In case you are wondering why line 2 has parenthesis around #2Gd6, it has to do with an unfortunate side effect of “reducers” (see Dice section below) What is not possible, however, is to define a parameter based on an arbitrary expression such as a dice roll - i.e., you can not roll a die to determine the number of dice to roll using parameters (in theory, it is possible to do this for a limited set of possible dice). This is due to the feature of The Dicenomicon that allows you to re-roll dice (using “fate points”) - if you rerolled that first die, what to do with already rolled dice becomes an enigma.

Roll References

Finally, it is possible to refer to dice rolls more than once. For example, if you want to roll 6 six sided dice and compare the highest 3 with the lowest 3 (this example is easily solved without using roll references via various list functions) and if the high 3 are more than 3 times the low three, we succeed. To do this, we can refer to a previous dice roll using a roll reference such as $1. Looking through the formula, the first dice roll is $1, the next is $2, etc… So our example would look like:

1. if 6d6H3 > $1L3 x 3 then

2. “Success”

3. else

4. “Failure”

5. end

In this case $1 refers to the 6d6. The H3 and L3 are “reducers” which are explained in the Dice section below. More specifically, the roll reference applies to the dice before any roll reducers or roll macro values are applied. This can also be written without references as:

1. @1 ← 6d6@.

2. if high3(@1) > low3(@1) x 3 then

3. “Success”

4. else

5. “Failure”

6. end

In general, use roll references only when absolutely required - they are subtle and prone to break (for example, editing to add an additional dice roll will screw up the reference). Furthermore, roll macros often include side effects such as re-rolling dice, which doesn’t happen with roll references

elderscript_variables.txt · Last modified: 2019/07/12 11:16 by dicenomiwiki