Looking at the changelog for 10.3 I learned about the new conditional/tags that can be used for text replacement.
So how do we go about this? there isn't any docs attached about them, just for the new cron expressions.
For example: if i want to check a bool to see if it should use a {Name} or {P2_Name} depending on wich person is in the location?
P.S.: sorry if it's explained somewhere and i didn't realize, sometimes I have difficulty understanding some things on english if they are too technical i.e.: iff:condition=(MathExpression1);result=Hello World|condition=(MathExpression2) what the heck do they mean about mathexpression? anything i write there? or some math i did before on the event?

I haven't found an example of "iff", but you can see examples of the other condition on "Location\Onsen\Onsen Bath Shared\Btn_UseOsenBath" (typo!) and "Location\St Judas Church\Church Hall\MaxInteractions".

Math expression is just that: an arithmetic expression. If it is 0 it fails, and if it is not 0 it passes. That's why False and True are now constants that can be used on math expressions.

Yeah, I haven't gotten around yet to finish the primary use case event that made me want to introduce these new expressions. I've attached the current work-in-progress, in case you want to take a look. It takes me forever to write dialogue, this one has been brewing for several weeks by now...

I am likely only going to finish this one and leave it as an example for other people to fill in the other 48 fetishes. (Though to be fair, a lot of the others probably won't need to be as elaborate.)

You basically have two new conditions that work with math expressions. The math expressions are basically parsed like those of the new "Math Expression" operation, which also includes a reference sheet of all the available operations.

{if=[math expression];then=[text if expression evaluates to non-zero]}{if=[math expression];then=[text if expression evaluates to non-zero];else=[text if expression evaluates to zero]}will give you either the text from "then" or "else" depending on whether the math expression is true (non-zero) or false (zero).

{iff:condition=[math expression A];result=[text if expression A evaluates to non-zero]|condition=[math expression B];result=[text if the previous expressions evaluated to zero and expression B evaluates to non-zero]|[can keep adding as many as you want...]}will give you the text from the first condition that is fulfilled, going from left to right. If none is fulfilled, it won't give you anything, but you can just write 1 or True as the last condition to always get its text as fallback.

If you could only use hardcoded values as expressions, this wouldn't be of much use (other than using the built-in functions to generate a random number in the expression). So before evaluating anything else, the text parsing will now replace {var:My Variable Comment}, {var:123} (i.e. ID of a variable in the event) and {gvar:Name of a global variable} with the respective string representation of that variable.
That way you can get numeric values from already computed event variables into your "hardcoded" math expressions. If you reference a boolean variable this way, it will insert "True" or "False" into the expression, but it's okay because we've taught the parser that these should be treated as 1 or 0 respectively. And you can also just include the content of another string variable into your text for convenience.

If you want to nest expressions, for example
{if={var:A} * 2 > {var:B} - 15;then=Hello \{if={var:IsMom};then=mom;else=dad\}}you need to escape the inner curly brackets with backslashes, so they don't get confused as boundaries of the outer expression. \{ and \} will be turned into a regular { and } when the text is being resolved from the outer expression. If you want to nest even more layers, you would need to add even more backslashes. But at that point you should probably consider doing that stuff in regular VEE space for clarity.
The curly brackets from the inner {var:IsMum} do not need to be escaped because the engine will fill in the variable values before any of the conditional parsing is done, so the brackets will already be gone by the time the parser gets there.


In the end, the new expressions don't really let you do you couldn't already do with separate VEE operations that string together a bunch of text options. The expressions just allow you to move that complexity directly into the string variable, which can make the event a bit more concise at the cost of making the actual string variable more difficult to parse with your eyes.

Quote from: Shilo on Oct 07, 2022, 03:05 PMYeah, I haven't gotten around yet to finish the primary use case event that made me want to introduce these new expressions. I've attached the current work-in-progress, in case you want to take a look. It takes me forever to write dialogue, this one has been brewing for several weeks by now...

I am likely only going to finish this one and leave it as an example for other people to fill in the other 48 fetishes. (Though to be fair, a lot of the others probably won't need to be as elaborate.)

You basically have two new conditions that work with math expressions. The math expressions are basically parsed like those of the new "Math Expression" operation, which also includes a reference sheet of all the available operations.

Code Select Expand

{if=[math expression];then=[text if expression evaluates to non-zero]}

Code Select Expand

{if=[math expression];then=[text if expression evaluates to non-zero];else=[text if expression evaluates to zero]}will give you either the text from "then" or "else" depending on whether the math expression is true (non-zero) or false (zero).

Code Select Expand

{iff:condition=[math expression A];result=[text if expression A evaluates to non-zero]|condition=[math expression B];result=[text if the previous expressions evaluated to zero and expression B evaluates to non-zero]|[can keep adding as many as you want...]}will give you the text from the first condition that is fulfilled, going from left to right. If none is fulfilled, it won't give you anything, but you can just write 1 or True as the last condition to always get its text as fallback.

If you could only use hardcoded values as expressions, this wouldn't be of much use (other than using the built-in functions to generate a random number in the expression). So before evaluating anything else, the text parsing will now replace {var:My Variable Comment}, {var:123} (i.e. ID of a variable in the event) and {gvar:Name of a global variable} with the respective string representation of that variable.
That way you can get numeric values from already computed event variables into your "hardcoded" math expressions. If you reference a boolean variable this way, it will insert "True" or "False" into the expression, but it's okay because we've taught the parser that these should be treated as 1 or 0 respectively. And you can also just include the content of another string variable into your text for convenience.

If you want to nest expressions, for example

Code Select Expand

{if={var:A} * 2 > {var:B} - 15;then=Hello \{if={var:IsMom};then=mom;else=dad\}}you need to escape the inner curly brackets with backslashes, so they don't get confused as boundaries of the outer expression. \{ and \} will be turned into a regular { and } when the text is being resolved from the outer expression. If you want to nest even more layers, you would need to add even more backslashes. But at that point you should probably consider doing that stuff in regular VEE space for clarity.
The curly brackets from the inner {var:IsMum} do not need to be escaped because the engine will fill in the variable values before any of the conditional parsing is done, so the brackets will already be gone by the time the parser gets there.


In the end, the new expressions don't really let you do you couldn't already do with separate VEE operations that string together a bunch of text options. The expressions just allow you to move that complexity directly into the string variable, which can make the event a bit more concise at the cost of making the actual string variable more difficult to parse with your eyes.

Side note, I'd have named "iff" as "select" instead.

Quote from: dcsobral on Oct 07, 2022, 04:24 PMSide note, I'd have named "iff" as "select" instead.

Naming Things - The Hardest Problem In Computer Science.

At that point, I was basically just mirroring the "if function" from the mXparser lib, which is named the same way and also arranges its operands in the same way.