Communique3 repeats and special recipient types

[ifly6]

Communique3 has a function called 'repeat'. It sets up the sending thread to repeatedly re-parse the given input until one of the sources is exhausted or the autoStop is engaged. Consider tag:delegates. There (almost certainly) will be delegates who no longer exist after the initial parse is executed.

When repeat is true, only the first 10 elements will be passed to the CommSender queue. Only when the CommSender queue is exhausted will it again poll the parser (via Communique7ParserMonitor) and re-parse. For tag:delegates this greatly reduces the chances that you telegram a delegate who no longer exists because it checks every 10 sends for a new list of delegates. If a delegate stopped existing in the last 10 minutes, it won't appear after the cache update.

The trade-off though, is that when you hit the repeat checkbox, the program will no longer tell you how many telegrams remain. This is because the number of telegrams remaining will change in unknown ways: imagine if all the delegates were un-elected (which happened once in NationStates when endorsements were purged). This also is inherent in some of the following special recipient types, which have reports based on someone on the site taking some actions.

Communique3 also introduces a number of special recipient types. They are:

• _happenings
• _movement
• _approval
• _voting

These all take special parameters. Examples are as follows.

Happenings

This recipient class does not inherently exhaust.

• _happenings:active returns active nations

Note. Happenings will later be extended.

Movement

This recipient class does not inherently exhaust.

• _movement:into; europe returns nations moving into Europe
• _movement:into; europe, the_north_pacific, europeia, balder returns nations moving into the listed regions, but no movements will be reported for nations moving between the listed regions. Do not include the_rejected_realms unless you are really sure
• _movement:out_of; europe returns nations moving out of Europe; this also works with a list of regions as above

Approval

This recipient class exhausts inherently when the proposal it is targeted towards ceases to exist (either because voting started or because it expired or was withdrawn).

• _approval:given_to; imperium_anglorum_1608498120 marks approvals given to the specified proposal ID
• _approval:removed_from; imperium_anglorum_1608498120 does the same, but for approvals removed
• ⚠️ _approval:__raids__ delivers recipients to people who had removed their approvals from a currently existing proposal, who later lost their delegacies, who are currently delegates; this is meant to be run for a long period of time

Voting

This recipient class exhausts inherently when the ID of the source proposal it was initially targeted towards no longer exists (ie the proposal at vote has changed).

• _voting:ga; for delivers everyone who is voting in the GA for the specified resolution
• _voting:sc; against is similar, for anyone who is voting against the specified resolution
• Combine this tag with +tag:delegates to limit to delegates or +region:authoritarian_region_here for people voting in the position noted who are in that specific region