07. Wildcard rules

a) Wildcards cannot have upper case letters. The presence of at least one upper case letter tells the program to expand the wildcard by accessing special resources outside the XML document, in a specific Rimworld path. You can use underscore and all, but never an upper case symbol. For instance, I found out that [Animals] wildcard returns a random animal from a .txt resource in one of the Rimworld game subpaths.

b) Wildcards are InteractionDef-scoped. This means that if you use a [food] wildcard in one InteractionDef, it will be used in the whole InteractionDef (but not in others). So if your InteractionDef is very complex and rich (with many sub-sections), you must consider naming your wildcards in a more detailed way, to avoid ambiguities.
For instance, you can define a [food] wildcard in a ChitChat interaction and then a wildcard with the very same name in a DeepTalk interaction - this won't be a problem, as we're speaking of two distinct interactions.
But if you want to use a [food] wildcard in two sub-sections of the same ChitChat interaction, you must name wildcards with a per-section name, e.g. [food_1] and [food_2].

c) Whenever you create a wildcard, it is as if you created a new path to a new content. This content must lead to somewhere, or the code will generate an error. Consider this example:
<li>r_logentry->[my_wildcard]</li>
<li>my_wildcard(INITIATOR_opinion>=0)->Hello there!</li>
<li>my_wildcard(INITIATOR_opinion>=0)->Hi, friend!</li>

This code works only if the initiator pawn has a positive or zero opinion of the recipient pawn. Were this negative instead, the code would lead nowhere and generate an error. Let's see why:

• the code detects and expands the [my_wildcard] wildcard
• it tries to select the "Hello there!" line by checking if INITIATOR_opinion>=0, but it fails to do so
• it tries to select the "Hi, friend!" line by checking if INITIATOR_opinion>=0, but it fails to do so as well
• since the [my_wildcard] wildcard gave no viable result (none of the lines matched the conditions), the code will generate an error

We can avoid this kind of situation by guaranteeing that each wildcard always leads to somewhere valid. And I can think of two ways to do this.

The first one is including a set of conditions covering all the possibilities. As in the following example:
<li>r_logentry->[my_wildcard]</li>
<li>my_wildcard(INITIATOR_opinion>=0)->Hello there!</li>
<li>my_wildcard(INITIATOR_opinion&lt;0)->Get out of my way!</li>

As in the first example, I'm using the initiator pawn's opinion as a criteria - but this time I'm featuring all the possible cases: an opinion is a value ranging from -100 to 100 and so once I cover the ">=0" and the "<0" cases, I've covered all the possibilities.
Moreover, opinions are numbers, which in Rimworld code are always defined (if for any reason they are undefined, they default to zero). So the example above is really risk-free.

Yet, if you use another parameter, which can be undefined for any reason, it's safer to use another strategy:
<li>r_logentry->[my_wildcard]</li>
<li>my_wildcard(INITIATOR_trait==gourmand)->We're having quail legs with tamarind glaze and fig chutney for dinner.</li>
<li>my_wildcard(INITIATOR_trait==ascetic)->We're having raw rice for dinner.</li>
<li>my_wildcard->We're having pizza for dinner.</li>

The third line is unconditioned, so it is like a default if other lines fail to be selected.

Whenever you're unsure about if you're covering all the possibilities or not, you should guarantee a default option.
If you must use a default option, but you aren't sure as to what to write in it, you can still code this:
<li>r_logentry->[my_wildcard]</li>
<li>my_wildcard(INITIATOR_trait==gourmand)->We're having quail legs with tamarind glaze and fig chutney for dinner.</li>
<li>my_wildcard(INITIATOR_trait==ascetic)->We're having raw rice for dinner.</li>
<li>my_wildcard-></li>

The third line leads to an empty (yet valid) default sentence, which is fine code-wise - but it could be strange game-wise, since it's as if a pawn tries to speak something but nothing comes out. Moreover, this is risky for debugging, because an empty sentence cannot be easily detected while testing. If you wish, especially in debugging stage, you can code something like <li>my_wildcard->DEBUG</li> for the 3rd line.