Proposal to change how triggers are implemented

[asacolips]

In GitLab by @luizbgomide on May 20, 2021, 13:16

Summary

Today we have a system that tries to parse words and numbers to detect triggers on the card rolls and highlight them for the user.

Since this is a simple detection of words like: even, odd, hit, miss and patterns like [number] or [number]+, it can fail when parsing: Natural 16+ if escalation die is 3+; otherwise natural 20. There is no way for the system to guess which number to use.

There is also the issue with word detection that doesn't work on translated text. Even if we managed to add support for other languages, those are still prone to error since simple words like even/odd are translated as par/impar in Spanish and Portuguese, which could be misinterpreted. Finally, even if we manage to detect text in translations, we would be limited to a single language (unless the logic gets a lot more complex), if we are running Toolkit113 in Spanish it wouldn't detect triggers written in English (and vice versa).

Natural language processing is very hard!!!

Proposal

Allow trigger tags to be added to the named hits (hit1, hit2, hit3, hit4, hit5) in the Action Template and the Trigger property from the Power Template. Those tags would be surronded by { }, like the following examples (all taken from system):

Natural 16+ if the escalation die is 3+; otherwise natural 20.{16+ ed3+|20}

• 16+ is a shorthand to indicate a range of natural values on the d20 roll.
• ed3+ is the Escalation Die prefix with the same shorthand expresssion.
• |, a logical OR operator.
• 20 is a single natural value on the d20 roll.

Natural 5, 10, 15, or 20.{5,10,15,20}

• 5,10,15,20 is a list of possible natural values on the d20 roll.

Natural even hit{even hit}

• even is an even value on the d20 roll.
• hit is a target hit.

List of flags and operators

• |: not a flag, a logical OR operator, it allows for complex triggers to be created.
• !: not a flag, but an unary operator to negated the flags in front of it
• even: all even
• odd: all odd
• hit: a hit
• miss: a miss
• shield: the first suggested new flag, checks if the attacks has a shield
• ed[expression]: escalation die value matches the [expression]
• [expression]: the d20 roll result matches the [expression]
• ??: a flag to indicate that there are more requirements for the trigger that can't be determined by the system

Expression

The expression is a comma , separated list of following possible sub-expressions:

• [value]: a single value
• [value]+: equal or more than the [value]
• [value]-: equal or less than the [value]
• [start]-[end]: a range of values from [start] to [end]

If any of the sub-expressions are validated the expression is considered true.

Changes in the current system

There are 3 major changes needed to be implemented in the following order:

• [ ] Change how the trigger and hit[1-5].name are rendered to remove any text between { }. This would not affect the current system.
• [ ] Optional. Start adding the trigger flags to the corresponding Powers and Actions in the Compendiums.
• [ ] During the creation of the chat cards put the trigger flags into an HTML attribute that holds the text of the Trigger. Also automatically add trigger flags for properties like power.hitOdd (hit odd), power.Crit (20 or possibly 19+ or 18+ if this can be detected by the system), power.Hit (hit), etc to the HTML attribute of those properties. This would not affect the current system.
• [ ] Change the trigger handling routine to process the trigger flags in the HTML attribute instead of the current system of natural text parsing. This would affect how the system shows the triggers, but by this step the new flags should already be on the system. This is the first time the handling of the information will change but by now it should work as it did before or better.
• [ ] Optional. In the future create new tags account for hard to describe conditions. Since those can me written now as ??, meaning there are more criteria to be met, it is just a matter of searching the compendiums for ?? to find those candidates.

How the flags could be processed in the card

1. Get the list of flags from the HTML attribute
2. Split the list by |, each of the substrings is a possible trigger and only fully matching one of them is needed.
3. For each substring split the triggers by (space)
4. Pop all triggers in the format (even|odd|\d+(-\d+)?) and use them to build a list of possible d20 values.
5. Check if the d20 matches on the of the possible values, and then check every remaining trigger and they all must be true for the trigger to be considered valid. The ?? is always true, but if present the substring is at most a partial trigger.
6. If on substrings produces a full trigger the processes is finished, if not and there is a partial trigger then it can be used (the highlight can be in a different color) and finally if no full or partial trigger is found no highlight is added.

Advantages

Since the syntax has a fixed list of keywords, in English this is very close to natural language, and for usage in other languages this is still very easy to use due to small number of keywords needed to construct complex triggers. By comparison it is much simpler than generating dice rolls in Foundry.

For translators it is just a matter of not touching the text between { } and eveything just works.

A dialog could be added to help construct triggers trying to recognize the words used in the trigger natural text to suggest what might be needed, but this is very close to natural language in english as the examples belows demonstrated.

Examples:

• Any hit{hit}
• Any miss{miss}
• Any natural even roll{even}
• Natural 11+; use only twice per battle{11+}
• Natural 13{13}
• Natural 1–5{1-5}
• Natural 16+{16+}
• Natural 16+ if the escalation die is 3+; otherwise natural 20{16+ ed3+|20}
• Natural 16+ if the escalation die is 5+; otherwise natural 20{16+ ed5+|20}
• Natural 16+; if you fight with a shield, also any natural even roll{16+|shield even}
• Natural 19+{19+}
• Natural 19+, or Natural 18+ if you are a Shifter adept{19+|18+ ??}
• Natural 20{20}
• Natural 5, 10, 15, or 20{5,10,15,20}
• Natural even hit{even hit}
• Natural even miss{even miss}
• Natural odd hit or miss{odd}
• Natural odd roll{odd}

This is an example of a somewhat complex triggers that gets a bit more verbose:

• Natural roll is equal to or lower than the escalation die{ed1 1|ed2 2-|ed3 3-|ed4 4-|ed5 5-|ed6 6-}

The following are "problematic", but could be "fixed" in the future with more flags for conditions and maybe an operator to apply the flag to target (like > or something else), so staggered would trigger when the attacker staggered, and >staggered when the target is. But a partial trigger can be identified for all of them.

• Natural even hit against a dazed enemy{even hit ??}
• Natural even hit against a stuck or hampered enemy{even hit ??}
• Natural even hit against a target in heavy armor{even hit ??}
• Natural even hit against an ally{even hit ??}
• Natural even hit against an enemy{even hit ??}
• Natural even hit, or any hit against a weakened, stunned, or confused target{even hit|hit ??}
• Natural odd hit against a target in light armor or no armor{odd hit ??}
• Natural even hit or miss while the warrior is staggered{even hit|miss ??}

Note, natural language processing is so hard that the last trigger could be interpreted in 3 different ways...

[asacolips]

In GitLab by @luizbgomide on May 20, 2021, 17:47

Code in repository https://gitlab.com/luizbgomide/archmage

[asacolips]

In GitLab by @LegoFed3 on May 22, 2021, 04:53

If I undestand this right, the proposal is to eventually completely replace the current natural text processing with manually added tags. That is... annoying, since as a GM I'm hapy to have a bit of automation but frankly can't be bothered to manually code stuff that I can more quickly parse mentally those three times it comes up. I can see how this can be of interest to someone (you, for instance), but I'd recommend to leave the current natural text parsing in place, and before applying one or the other check for the presence of tags (i.e., stuff between {}). That way we can use the appropriate one without removing functionality for lazy GMs like me.

[asacolips]

In GitLab by @luizbgomide on May 22, 2021, 06:32

You mean existent functionality? My idea is to only replace the system once it does everything the current system does for all creatures and powers.

After the new system is implemented for English users it would be a matter of adding the criteria in pretty much natural language between brackets, since the keywords are English based and the shorthand are identical to what is used, and it can even be placed separated by triggers (also it can be at front, back, or in the middle of the text): Natural 16+{16+}; if you fight with a shield, also any natural even roll{shield even}.

In regards to keeping the natural system in place, my recommendation is that after someone fills text for action.hit[1-5].name and power.trigger (the only two custom trigger instances, the rest is all automatic) in the item settings and haven't filled up a trigger yet, detect which trigger he meant to use (now we can use translated natural language parsing) and show a popup (or something like it): "Do you to want detect "even hits" with that trigger?" And then the user can just confirm it. Since we would be dealing with a single line and can show a dialog asking for user confirmation, we can even construct multiple possible triggers and ask him what is the one he meant to use.

Yesterday I began tinkering with the system, so far I have the trigger processing complete, the trigger identification in the preprocessing of the chat card also complete (and I'm cleaning up a bit of code in that preprocessing that rely on hardcoded strings to work by default). After that the only remaining tasks are: adjusting the templates to hide the trigger text and adding the trigger information (I've already made two handlebar helpers that does just that), and go through the monsters srd hit1, hit2, hit3 to add trigger information and through the powers.trigger and all be ready for deployment. I think I can finish that by the end of the next week.