from daidepp import create_daide_grammar, daide_visitor

grammar = create_daide_grammar(level=130)
message = <MESSAGE>
parse_tree = grammar.parse(message)
output = daide_visitor.visit(parse_tree)
print(output)

When message is PRP (ALY (FRA ENG) VSS (GER RUS))the visitor works
However, when message isPRP (ALY (FRA ENG) VSS (GER))
i.e. when only 1 country is preceded by VSS,
it raises parsimonious.exceptions.ParseError: Rule 'ws' didn't match at '))' (line 1, column 28).

On version 1.1.4, I get an error when attempting to parse: PRP ( AND ( XDO ( ( AUS AMY BUD ) MTO SER ) ) ( XDO ( ( AUS AMY VIE ) MTO TRI ) ) ( XDO ( ( AUS FLT TRI ) MTO ALB ) ) ( XDO ( ( ENG AMY LVP ) MTO WAL ) ) ( XDO ( ( ENG FLT EDI ) MTO NTH ) ) ( XDO ( ( ENG FLT LON ) MTO ECH ) ) )

The DAIDE that is being parsed was generated by creating DAIDEPP objects PRP, AND, XDO, etc.

Code to replicate:

from daidepp import create_daide_grammar, daide_visitor
grammar = create_daide_grammar(level=130)
print(daide_visitor.visit(grammar.parse(grammar)))

The error:

Traceback (most recent call last):
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in visit
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/daidepp/visitor.py", line 217, in visit_and
    _, _, arrangement, _, par_arrangements = visited_children[0]
ValueError: not enough values to unpack (expected 5, got 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jale/diplomacy/pinnacle/utils/messages/message_utils.py", line 44, in parse_str
    return daide_visitor.visit(grammar.parse(filtering))
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in visit
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in <listcomp>
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in visit
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in <listcomp>
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in visit
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in <listcomp>
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in visit
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 213, in <listcomp>
    return method(node, [self.visit(n) for n in node])
  File "/home/jale/miniconda3/envs/deepmind/lib/python3.8/site-packages/parsimonious/nodes.py", line 225, in visit
    raise VisitationError(exc, exc_class, node)
parsimonious.exceptions.VisitationError: ValueError: not enough values to unpack (expected 5, got 0)

Parse tree:
<Node called "and" matching "AND ( XDO ( ( AUS AMY BUD ) MTO SER ) ) ( XDO ( ( AUS AMY VIE ) MTO TRI ) ) ">  <-- *** We were here. ***
    <Node matching "AND">
    <RegexNode called "lpar" matching " ( ">
    <Node called "sub_arrangement" matching "XDO ( ( AUS AMY BUD ) MTO SER ) ">
        <Node called "xdo" matching "XDO ( ( AUS AMY BUD ) MTO SER ) ">
            <Node matching "XDO">
            <RegexNode called "lpar" matching " ( ">
            <Node called "order" matching "( AUS AMY BUD ) MTO SER">
                <Node called "mto" matching "( AUS AMY BUD ) MTO SER">
                    <RegexNode called "lpar" matching "( ">
                    <Node called "unit" matching "AUS AMY BUD">
                        <Node called "power" matching "AUS">
                            <Node matching "AUS">
                        <RegexNode called "ws" matching " ">
                        <Node called "unit_type" matching "AMY">
                            <Node matching "AMY">
                        <RegexNode called "ws" matching " ">
                        <Node called "province" matching "BUD">
                            <Node called "prov_landlock" matching "BUD">
                                <Node matching "BUD">
                    <RegexNode called "rpar" matching " ) ">
                    <Node matching "MTO">
                    <RegexNode called "ws" matching " ">
                    <Node called "province" matching "SER">
                        <Node called "prov_landlock" matching "SER">
                            <Node matching "SER">
            <RegexNode called "rpar" matching " ) ">
    <RegexNode called "rpar" matching ") ">
    <Node matching "( XDO ( ( AUS AMY VIE ) MTO TRI ) ) ">
        <Node matching "( XDO ( ( AUS AMY VIE ) MTO TRI ) ) ">
            <RegexNode called "lpar" matching "( ">
            <Node called "sub_arrangement" matching "XDO ( ( AUS AMY VIE ) MTO TRI ) ">
                <Node called "xdo" matching "XDO ( ( AUS AMY VIE ) MTO TRI ) ">
                    <Node matching "XDO">
                    <RegexNode called "lpar" matching " ( ">
                    <Node called "order" matching "( AUS AMY VIE ) MTO TRI">
                        <Node called "mto" matching "( AUS AMY VIE ) MTO TRI">
                            <RegexNode called "lpar" matching "( ">
                            <Node called "unit" matching "AUS AMY VIE">
                                <Node called "power" matching "AUS">
                                    <Node matching "AUS">
                                <RegexNode called "ws" matching " ">
                                <Node called "unit_type" matching "AMY">
                                    <Node matching "AMY">
                                <RegexNode called "ws" matching " ">
                                <Node called "province" matching "VIE">
                                    <Node called "prov_landlock" matching "VIE">
                                        <Node matching "VIE">
                            <RegexNode called "rpar" matching " ) ">
                            <Node matching "MTO">
                            <RegexNode called "ws" matching " ">
                            <Node called "province" matching "TRI">
                                <Node called "prov_land_sea" matching "TRI">
                                    <Node matching "TRI">
                    <RegexNode called "rpar" matching " ) ">
            <RegexNode called "rpar" matching ") ">

What functionality will your new tokens add?

Currently, the DAIDE grammar level 8000 proposes "Free Text Press" where any power can communicate with any ASCII characters. "Freer Text Press" proposes natural language communicate using any Unicode characters. I suggest UTF-8 encodings to start with.

Describe the precise changes you'd like

Add this to daide-specification.md:

## Level 8010: Freer Text Press

This level allows natural language press. Both message and reply can be any string of UTF-8 encoded Unicode characters.

Additional context

This is 100% serious.

I am from SHADE and would like to use this library as our main parser. We are currently using this library: https://github.com/trigaten/DAIDE, which provides simple parsing, as well as DAIDE message construction using DAIDE keywords, like the following:

# easily compose DAIDE keywords
>>> from DAIDE import Order, Unit, ORR, HLD
>>> arrangement = ORR([Order(Unit("FFF FFF FFF"), HLD()), Order(Unit("FFF FFF FFF"), HLD())])
>>> str(arrangement)
'ORR ((FFF FFF FFF) HLD) ((FFF FFF FFF) HLD)'

It would be very useful if your parser provided this support. How difficult would this be to add?

What functionality will your new tokens add?
A new token might be added for requesting an offer from power or demanding an offer from power.

Describe the precise changes you'd like

• Along with using existing tokens, we are proposing a new token ROF for requesting an offer or demand an offer by insistence.
• Daide clauses for these two might be “SND (power power…) (PRP(ROF))” and “SND (power power…) (INS(ROF)) ” for Requesting and Demanding for offer respectively.
• Example of request an offer – if any power is requesting Germany and Russia for an offer, the Daide clause might be “  SND (GER AUS) (PRP(ROF))”
• Example of demanding an offer -if any power insisting or demanding Germany and Austria for an offer, the Daide clause might be “ SND (GER AUS) (INS(ROF))"

Additional context
For the negotiation between agents, we are proposing Daide extension.

What functionality will your new tokens add?
New tokens might be added for sending messages with trust and distrust information
We propose “Send trust message” and “Send distrust message”.

Describe the precise changes you'd like

• The existing Daide specification already has a token for making a statement called “FCT”. Along with this, we are proposing a new token, such as TRU, for the trust and distrust statement.
• Daide clauses for these two might be “SND(power power …) (FCT(TRU(power power…))) 
  ” and “ SND(power power …) (FCT(NOT(TRU(power power…))))  ”for Trust and Distrust Respectively.
• Example of a trust statement- if any power sends Germany and Russia a press_message such as, “I trust Russia and Italy.”,
  the Daide clause might be “SND (GER RUS) (FCT(NOT(TRU(RUS ITA )))”
• Example of a distrust statement- if any power sends Germany and Russia a press_message such as, “I don’t trust Russia and Italy”, the Daide clause might be “SND (GER RUS) (FCT(NOT (TRU(RUS ITA ))))”
  Additional context
  For the negotiation between agents, we are proposing Daide extension.

As shown in the README:

>>> from daidepp import AND, PRP, PCE
>>> str(AND(PRP(PCE("AUS")), PRP(PCE("AUS", "ENG"))))
AND ((PRP (PCE (AUS))) (PRP (PCE (AUS ENG))) (PRP (PCE (AUS ENG FRA))))

But per the DAIDE syntax, AND should follow this format:

arrangement = AND (arrangement) (arrangement) (arrangement) ...

This means we are adding an unnecessary left parenthesis at the beginning and an unnecessary right parenthesis at the end. The output should be this:

AND (PRP (PCE (AUS))) (PRP (PCE (AUS ENG))) (PRP (PCE (AUS ENG FRA)))

The same issue is present in ORR.

Being able to install the parser as a library via adding a setup file would make integrating the code easier.

That way, by doing something like pip3 install git+https://github.com/SHADE-AI/daidepp.git one would be able to simply import the parser as a package.

What functionality will your new tokens add?
New tokens might be added for emotional state. We propose “Send Emotional State Message”.

Describe the precise changes you'd like

• We are proposing some new tokens, EMO, HPY, UHY, ANG for sending emotion state.
• Daide clauses for this might be “SND (power power …) (EMO(emotion_type)) where, emotion_type = HPY/UHY/ANG for sending happy, unhappy or angry emotion respectively.”
• Example: Any power sending its emotional state as Unhappy to Russia with “SND (RUS) (EMO(UHY)) ”

Additional context
For the negotiation between agents, we are proposing Daide extension.

I tried to parse a SCD arrangement using the following code snippet:

from daidepp import create_daide_grammar, daide_visitor

grammar = create_daide_grammar(level=130, string_type='all')
message = 'SCD (FRA HOL)'
parse_tree = grammar.parse(message)
output = daide_visitor.visit(parse_tree)
print(output)

Error message is as follows:

Traceback (most recent call last):
  File "C:\Users\daidepp\keywords.py", line 21, in __post_init__
    _grammar.parse(str(self))
  File "C:\Users\parsimonious\grammar.py", line 111, in parse
    return self.default_rule.parse(text, pos=pos)
  File "C:\Users\parsimonious\expressions.py", line 130, in parse
    node = self.match(text, pos=pos)
  File "C:\Users\parsimonious\expressions.py", line 147, in match
    raise error
parsimonious.exceptions.ParseError: Rule 'supply_center' didn't match at '['HOL'] )' (line 1, column 11).

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\parsimonious\nodes.py", line 213, in visit
    return method(node, [self.visit(n) for n in node])
  File "C:\Users\daidepp\daide_visitor.py", line 263, in visit_scd
    return SCD(*power_and_supply_centers)
  File "C:\Users\daidepp\keywords.py", line 376, in __init__
    self.__post_init__()
  File "C:\Users\daidepp\keywords.py", line 23, in __post_init__
    raise Exception("Incorrect values passed, object is not valid DAIDE")
Exception: Incorrect values passed, object is not valid DAIDE

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\validation.py", line 6, in <module>
    output = daide_visitor.visit(parse_tree)
  File "C:\Users\parsimonious\nodes.py", line 213, in visit
    return method(node, [self.visit(n) for n in node])
  File "C:\Users\parsimonious\nodes.py", line 213, in <listcomp>
    return method(node, [self.visit(n) for n in node])
  File "C:\Users\parsimonious\nodes.py", line 225, in visit
    raise VisitationError(exc, exc_class, node)
parsimonious.exceptions.VisitationError: Exception: Incorrect values passed, object is not valid DAIDE

Parse tree:
<Node called "scd" matching "SCD (FRA HOL)">  <-- *** We were here. ***
    <Node matching "SCD">
        <Node matching " (FRA HOL)">
            <RegexNode called "lpar" matching " (">
            <Node called "power" matching "FRA">
                <Node matching "FRA">
            <RegexNode called "ws" matching " ">
            <Node called "supply_center" matching "HOL">
                <Node matching "HOL">
            <Node matching "">
            <RegexNode called "rpar" matching ")">

SCD object can be constructed using
SCD(PowerAndSupplyCenters("FRA ", Location("HOL"))
just can't be parsed using the above snippet.

What functionality will your new tokens add?
New tokens might be added for canceling the query request that one power has already made towards another power regarding an arrangement. We propose “Sending cancellation of query request ”.

Describe the precise changes you'd like

• The existing Daide specification already has tokens for Query and Cancellation that are QRY and CCL, respectively.
• We are proposing a new Daide clause with the existing tokens. The clause might be “SND(power power …) (CCL(QRY(press_message))))”
• Example - if a power wants to cancel the query request it has made to Germany regarding the press_message with ally arrangement that Germany has sent to the power earlier, the Daide clause might be "SND (GER)(CCL(QRY(PRP(ALY (AUS GER) VSS (RUS TUR)))))"

Additional context
For the negotiation between agents, we are proposing Daide extension.

What functionality will your new tokens add?
A new token might be added for sending a message requesting the Best Alternative proposal against a proposal that has been received. Another new token will be needed to send the best alternative to a previously sent proposal.

Describe the precise changes you'd like

• Using existing tokens, we propose two new tokens, such as BTR for the Best Alternative Request and BAT for sending the best alternatives.
• Daide clauses for these two might be “SND (power power…) (BTR(PRP(arrangement))” and “SND(power power…) ((PRP(new_arrangement)) BAT(PRP(prev_arrangment)))" for Best Alternative Request and sending best alternatives respectively.
• Example for BTR – if Germany sends Russia a request for the best alternative to the order proposal Russia sent before to Germany , the Daide clause might be “SND(RUS) (BTR(PRP(XDO(GER AMY BER HLD)))))”
  -Example for BAT - if any power sends Germany a new order proposal against a previous order proposal.
  THE DAIDE CLAUSE might be “ SND (GER) ((PRP(XDO(GER AMY BER HLD)BAT(PRP(PEC(RUS GER))))))“

Additional context
For the negotiation between agents, we are proposing a Daide extension.

During some of my unit test cases, I came across a DAIDE message that should be valid but cause a Parsimonious ParseError due to a hole in the support move grammar.

The message below (an order sampled from a pool of possible orders from the SHADE game engine) returns parsimonious.exceptions.ParseError: Rule 'prov_no_coast' didn't match at 'CLY)).

PRP(XDO((ENG FLT EDI) SUP (ENG AMY LVP) MTO CLY))

Clyde (CLY) is correctly listed as a coastal province in the grammar, and the grammar only specifies 'prov_no_coast' for support move.

This would allow generating DAIDE messages like this: https://www.nltk.org/howto/generate.html

Now that we've hit version 1.0.0, the output is fundamentally different (i.e. much better!). This should be reflected in the README.

What functionality will your new tokens add?
A new token might be added for sending potential/indeterminate acceptance responses to an order proposal.

Describe the precise changes you'd like

• Along with using the existing Daide token, we propose a new token PAC for sending responses as potential/indeterminate acceptance of arrangement.
• Daide clauses for this might be “SND (power power …) (PAC (PRP(arrangement)))”
• Example - if a power sending Russia a potential acceptance of the order proposal that Russia sent to them earlier, the Daide clause might be “ SND (RUS)(PAC(PRP(XDO((RUS AMY MOS) SUP (GER AMY BER))))) ) “

Additional context
For the negotiation between agents, we are proposing Daide extension.

Is this a mistake? According to the markdown documentation the token should be ROF.

What functionality will your new tokens add?
By providing optional tonal modifiers to DAIDE statements DAIDE can be made more expressive and closer aligned to human language. Invariably in real negotiations, tone is conveyed either mechanistically through verbal intonation, through word selection, or a combination of the two. The proposed modifiers support the latter.

Describe the precise changes you'd like
Currently we support the following tones:

• Objective
• Hostile
• Friendly
• Fearful
• Confident
• Empathetic
• Upset

In our version of the game engine these are not treated as additional tokens in DAIDE but rather external modifiers. For example:

FRM (AUS) (ENG) (PRP (XDO ((ENG FLT LON) MTO WAL)))

would be modified by one of the tones. This could be embedded into DAIDE itself:

HOSTILE: FRM (AUS) (ENG) (PRP (XDO ((ENG FLT LON) MTO WAL)))

or

CONFIDENT: FRM (AUS) (ENG) (PRP (XDO ((ENG FLT LON) MTO WAL)))

or these tones could be treated separately altogether.

Additional context
From Jataware's standpoint tones should be ignored by teams that do not wish to support them, but if others are interested in using them we should have a broader discussion about whether this should be included as an addendum to DAIDE or whether we should treat tone separately (as we do currently).

For reference, our module that converts DAIDE + tone to human language can be found here.

>>> grammar = dpp.create_grammar_from_press_keywords(
                [
                    "PRP",
                    "PCE",
                    "ALY_VSS",
                    "YES",
                    "REJ",
                    "XDO",
                    "DMZ",
                    "AND",
                    "NAR",
                    "CCL",
                    "FCT",
                ]
            )
>>> grammar.try_tokens
`['AND',
 'DMZ',
 'FCT',
 'NAR',
 'NOT',
 'PCE',
 'PRP',
 'QRY',
 'REJ',
 'XDO',
 'YES',
 'ALY',
 'VSS']`

These two tokens are added unnecessarily.

What functionality will your new tokens add?
New tokens might be added for Return Favor Commitment and returning the favor.

Describe the precise changes you'd like

• We are proposing two new tokens, such as RFC for Return Favor Commitment against a proposed arrangement and RFV for Returning any Favor that was committed before.
• Daide clauses for these two might be “SND (power power …) (RFC(PRP(arrangement)))”
  and “SND(power power…) ((PRP(new_arrangement)) RFV(PRP(prev_arrangment)))” for Return Favor Commitment and Favor Return Respectively.
• Example for RFC –Turkey sending Germany and England such as, "If you two allied against Italy and Russia, I will return you a favor", the Daide clause might be “SND ( GER ENG) (RFC(PRP(ALY(GER ENG) VSS (ITA RUS))))) ”
• Example for RFV - if Turkey provides a return favor to Germany by calling for peace with them as a return favor, the Daide clause might be
  "SND(power power…) ((PRP(PEC(GER TUR))) RFV(PRP(ALY(GER ENG) VSS (ITA RUS)))"

Additional context
For the negotiation between agents, we are proposing Daide extension.

There are two visit_prov_coast methods in the DAIDEVisitor class. One needs to be removed.

This is an edge case that may not necessarily occur, but when translating something like DMZ ( GER RUS ) ( BLA SEV (STP NCS) ) , the parser throws a ParseError due to Rule prov_no_coast' didn't match at '(STP NCS) ).

The agents may not be negotiating about making a coast a DMZ specifically for fleets since that seems sort of nonsensical, but the error is there.

Broken link is here:

The machine-parsable grammar can be found in this .py file

What functionality will your new tokens add?
Add a new arrangement that specifies utility upper/lower bound for a particular power. This is intended for use with threats to show how much cooperation benefits the receiver over the threatened punishment.

Describe the precise changes you'd like

• New token ULB used to specify utility lower bound for a power.
• New token UUB used to specify utility upper bound for a power.
• Daide clauses would be in the format (ULB power float) or (UUB power float)
• Float is a new nonterminal representing a floating point number in some format that can easily be parsed from python
• Added to lowest new DAIDE level, which I think is 140
• Example usage: England sends Germany IFF (XDO((GER AMY BER) MTO MUN)) THN (PRP (ULB GER 0.8)) ELS (INS (UUB GER 0.1))
• This is a threat from England to Germany that says if you move BER to MUN then I will move to give you at least 0.8 utility, but if you do anything else I will move to prevent you from getting more than 0.1 utility.
• In this case the utility represents England's estimate of Germany's utility
• Different bots may have different ideas of utility that are not comparable, but providing the utility estimates from the same bot for different potential actions can emphasize that a threat is serious and make it clearer when something is considered a threat
• It could also be used outside threats for expressing preferences during negotiations
• Should be simple to implement because it does not wrap any other messages
• Requires adding floating point parsing, but that is built into python so it should not be too bad
• If people are very resistant to adding floats, we could use the existing ints and just multiply utilities by 100 before sending

Arrangements like PCE ( AUS GER ) have the powers in the arrangement rendered in the order in which they were passed. This is problematic because if we compare PCE ( AUS GER ) to PCE ( GER AUS ) they will be treated as different if we're comparing their string representations. We should automatically sort powers for easy comparison.

What functionality will your new tokens add?

This would subsume some of the other proposals. Any well-formed coherent DAIDE message can also have a free text explication that can convey tone, elaborate, and

Describe the precise changes you'd like

To the root non-terminal, add a free text explanation. E.g., for a request message MSG, add the explication:

(Explication "This is not a request, it is a demand" MSG)

A DMZ proposal only makes sense with prov_no_coast, since a unit occupies a province regardless of which coast it is on.

What functionality will your new tokens add?

Allow any well-formed DAIDE statement to be weighted by a real-valued probability between 0 and 1.

Describe the precise changes you'd like

For any valid DAIDE message MSG:

(PROB 0.7 MSG)

The Gulf of Bothnia should be GOB, but right now it is BOT.

Notes

Can use this workflow.

We would like to be able to parse ANY DAIDE string, not just messages. This means that a grammar object should be able to parse a message, arrangement, order, unit, or any other string which represents a coherent component in DAIDE.

The three letter code for certain provinces do not match between the daidepp grammar and the diplomacy game engine.

The ones I have encountered thus far are (diplomacy/daidepp):

• Gulf of Bothnia (BOT/GOB)
• English Channel (ENG/ECH)
• Gulf of Lyon (GOL/LYO)

Encountering one of the diplomacy engine version of the province names causes the parser to crash. This is slightly inconvenient as we have to do some extra translation between DAIDE and diplomacy. Translating from the diplomacy engine to DAIDE for ENG is particularly thorny because it could be referring to either the english channel or England the power.

When testing #55 I got a ValueError saying not enough things to unpack in visit_not. I fixed this error by changing visited_children[0] to visited_children without indexing. However, when i pushed that commit it failed the automated tests.

Eventually, I realized that using indexing results in ValueError when level 60 is not included in the grammar but works when level 60 is not included. I have temporarily included level 60 in my grammar to work around this issue.

Level 60 extends not to wrap queries in addition to arrangements which I believe causes this difference. It seems like daide_visitor needs some logic to detect whether level 60 is included to decide whether to index visited_children.

https://www.seanh.cc/2022/05/21/publishing-python-packages-from-github-actions/#automatically-generating-the-next-version-number

What functionality will your new tokens add?
New tokens might be added for threatening a power on certain actions.
We propose “Send break friendship threat” and “Send last offer threat”

Describe the precise changes you'd like

• The existing Daide specification already has a token for making a statement called “FCT”. We are also proposing two new tokens, such as BFT for Break Friendship Threat and LOT for Last Offer Threat.
• Daide clauses for these two might be “SND (power power …) (FCT (BFT(arrangement)))” and “SND (power power…) (FCT(LOT(arrangement)))” for Break Friendship Threat and Last Offer Threat Respectively.
• Example for BFT – if any power sends Russia a press_message such as, “if you set peace with Germany and Austria, you aren’t my friend anymore", the Daide clause might be “SND (RUS) (FCT(BFT(PCE(RUS GER AUS )))) ”
• Example for LOT- Germany sends England a press_message such as, “I am proposing you to ally with me against Italy and Russia. It will be my last offer to you if you don’t agree to this", the DAIDE clause might be “ SND (ENG) (FCT(LOT(PRP(ALY(GER ENG)VSS(ITA RUSS)))))".

Additional context
For the negotiation between agents, we are proposing Daide extension.

We should test that code, commits, docstrings, etc. follow the appropriate formatting whenever a PR is submitted.