And if you set your webhook, say Discord, with a payload of { "content": "@", "username": "$1" }, chat triggers like (.+) says, \"(.+)\" with a message of $2 will trigger webhooks that look like they're from the character that sent them.
After doing all this refactoring, I started thinking maybe I should remove the Payload aspect of each webhook and make the payload independent of the webhook and let each trigger set it. If you noticed above, to get a Discord webhook to set the username property on the payload, the regex capture group has to be number 1 ($1) which works in the example I gave you but it's not flexible. A more flexible solution is to make the Message field on the triggers the full JSON payload instead of the Payload field on the webhook. This is a breaking change and folks would have to change things and would lose settings. Do you think it's worth it?
Basically, backreference support makes for some nice additional features but isn't as flexible if the Payload is tied to the webhook. It's more flexible if the payload is tied to the trigger.
For now I'm going to keep things how they are but I wanna leave this open for posterity.
From a message I sent Trevis:
Basically, backreference support makes for some nice additional features but isn't as flexible if the Payload is tied to the webhook. It's more flexible if the payload is tied to the trigger.
For now I'm going to keep things how they are but I wanna leave this open for posterity.