Instead of relying on all parts of the application to construct both
HTML and plain-text responses, we now construct only HTML responses,
and convert the HTML to plain text right before sending the message to
Matrix.
This is a first iteration, because the plain text has a few extra
newlines than it should, created by use of nested <p> tags.
This upgrade introduces a handful of breaking changes in the Rust
Matrix SDK.
- Some types have disappeared and changed name.
- Some functions are no longer async.
- Room display name now has a Result type instead of just returning
the value.
- Client state store has breaking changes (not really a big deal).
This required introduction of a new type to store room information
that we are interested in on the context struct. This new RoomContext
is required mostly due to unit tests, because it is no longer possible
to instantiate the Room type in the Matrix SDK.
This gives it parity with the other systems: cofd and cthulhu. More
refactoring and a rewrite later as we trend towards more
system-specific implementations.
Also comes with reorganization of the dice rolling code to centralize
the variable -> dice amount logic, and changes the way the results of
those rolls are displayed.
The database API for user variables has changed somewhat again, this
time closer to the proper vision. There are now two separate sled
Trees in the Variables struct, one for user-defined variables, and one
for counts. Keys have been changed to be username-first, then room ID.
The signatures of the functions now also use a strongly-typed struct,
UserAndRoom.
As part of this, the Context object now once again avoids allocating
new strings.
Other random changes included here:
- Remove tempfile crate in favor of sled temporary db config.
- Add bincode crate in anticipation of future (de)serializing.
This commit introduces the Sled embedded key-value store for keeping
track of user variables on a per-room basis. Extensive changes were
made to the command module to separate concerns and also pass the
database "connection" down the line.
- A new "Context" object was created to hold information and state
needed for command execution (namely the database).
- Database is very simple for now, storing only user variables.
Refactoring later for storing more complicated types.
- State actor moved into Actors struct, in preparation for either
more actors, or ripping the whole thing out entirely.
- Other modules are also more properly separated, notably
the config module is entirely self-contained.
This commit refactors the parsing and rolling for the dice pool system
to prepare for support of user variables. The nom parser was dropped
in favor of the easier-to-understand combine parser in most parts of
the code.
A breaking change was introduced into the dice pool syntax to allow
for proper expressions and variables. The syntax is now
"modifiers:pool-amount", e.g. "n:gnosis+8". The simple single-number
syntax with no modifiers is also still understood.
Dice pool expressions are translated into a Vec of "Amount" objects,
stored by the DicePool struct. They have an operator (+ or -) and
either a number or variable name. When the dice pool is rolled, this
list of Amonuts are is collapsed into a single number that is rolled,
as it was before the refactor.
The following changes were made to the dice rolling code:
- Store Vec<Amount> on DicePool instead of single number to roll.
- New struct RolledDicePool to store result of a dice pool roll.
- Remove Display trait from DicePool, move it over to RolledDicePool.
- Separate extra dice pool info into DicePoolModifiers.
- DicePoolModifiers is shared between DicePool and RolledDicePool.
- Dice parsing and rolling now return standard Result objects.
This commit does NOT enable support of actually using variables. Any
dice pool roll containing a variable will result in an eror.
The command parser was also rewritten to use combine and rely on the
standard Result pattern.
This behavior became broken again after switching away from the
macro-based command parsing. The bot would return any non !command
message as an error, which would cause it to read more messages, and
return those as errors, until finally the matrix SDK would throw up.
Command parser now more properly handles empty messages and
non-commands, but we also simply abort processing if the incoming
message doesn't start with an exclamation point.
By using the alpha1 function in complete mode, we are able to handle
arbitrary single-word commands (e.g. "!help") and proprly map the
remaining input to an empty string.
projectmoon
Taylor C. Richberger