projectmoon / matrix-dicebot Goto Github PK

Add the ability for users to define their own variables and reference them in rolls.

• Simple definition of variables, of a specific type. Number to begin with.
• Variables can be used in dice rolls, substituting their number for the name.

To do this, we have to implement a other things:

• Implement proper state management (Riker/actors).
• Add database connectivity and storage.

Then to implement this:

• Command to define variable.
• Rework of parsing code to read variable names.

The parser will throw an unconsumed input error when attempting to set it.

Right now it'll just execute every command given to it in one message. Limit it to something like 50, or maybe even configurable.

Right now it just says how many it executed.

The parser doesn't understand negative numbers at the moment.

Make sure help is up to date with new information:

• Variables
• Call of Cthulhu dice rolling
• And more...

Now that the Github Container Registry actually allows public pulls, use that instead of Docker Hub.

Database code is getting larger, and we are in need of a migration facility as we settle the schema.

• Split code for each type of data into separate files (e.g. variables.rs)
• Create migration code.

Migration Code

Store the current migration version in a specific migration tree as a single number. Hardcode the current database version into the binary (because embedded database and laziness). Produce a range of migration numbers to run on startup, which would be all versions between the old and current version, and including the current version. Migrations are functions that receive the Database object.

The code supports arbitrary success numbers, but it's hardcoded to check against 8 for success when checking if it needs to reroll a rote die.

This is necessary foundational work for managing the bot's services in a private chat (direct message) instead of spamming commands out in the open. As most commands are planned to be per-room, giving commands in a DM need to be contextually aware of a room, either by giving a room ID/number or setting the room and having all commands afterward operate on that room.

Checklist:

• Handle an event (which hopefully exists in matrix SDK) for when a user joins a room, and record the user in the rooms namespace in the database.
• Handle user leaving event and remove the user from the room list.
• On startup, sync room member lists as an async task. Update member list for every room the bot is in.

The bot should always exclude itself from member lists. Because direct messages are rooms, we might also want to ignore direct message rooms. This can be done with Matrix SDK.

Implement a command or process into the bot to resync all its data. This is useful while the database schema is changing, and also maybe necessary to catch up while the bot is offline, although perhaps the syncing of all missed events would allow it to catch up instead.

A minor issue with the dice pool roller. It resolves huge numbers (outside the bounds of i32) to variable names, because the resolver simply assumes the value is a variable if it cannot parse an i32. What it should do is check if all the characters in the element are digits, and if so try to parse an i32. If the i32 parse fails, return an error. If the element is not all digits, then we can assume it's a variable name.

It can sometimes be be difficult to tell how the dicebot is re-rolling dice in the Chronicles of Darkness dicepool system It would be useful to see something like 2 => 10 => 10, 8, 4 to indicate a reroll. There are two parts to this: changing code to support the possibility, and then making the formatting nice.

• Instead of having dice roll functions return a Vec<u32> and tacking that on to a full set of rolls, a dice pool roll should be represented by a Vec<SingleRoll>, where SingleRoll has one or more actual rolls in it.
• The SingleRoll trait can implement Display to provide the better formatting.
• Code for calculating successes etc needs to sum up the total successes of each single roll to be accurate.

Limit the maximum number of variables a user can define in order to prevent abuse of the bot.

• Room limit: how many variables can be defined in a specific room.
• Global limit: how many total variables can be defined.

Checklist:

• Increment a room limit key in the variables namespace if a new variable is defined (not updated).
• Increment a global limit key in the variables namespace if a new variable is defined (not updated).
• Decrement room limit key when variable deleted.
• Decrement global limit key when variable deleted.
• Deny !set of new variables when limit(s) reached (probably compare and swap)

Right now it only logs the user and command executed. Add room display name to it. Probably room ID also good.

Once we find out the rules for it.

There is no need to return an option when we have an IgnoredCommand, which is exactly what the calling function returns by translating a None to that error.

e.g. !rol 1d10 instead of !roll 1d10. This should return an error message instead of 0 commands executed. It's because the command parser doesn't currently show errors on multi-executed commands... or for one command apparently.

Add the "pill" username in html responses. Looks nicer and integrates with the room better.

Right now it returns the non-guaranteed order of the hash map. Sort it alphabetically by variable name before returning.

Variable count is stored as a variable for the user. Do not allow it to be deleted. It also should not show up in lists, or count towards the limit.

Need to settle the schema so it doesn't change too much.

• Use Trees for broad categories of data, e.g. rooms or variables.
• Each Tree has its own key subspaces for smaller categories, like metadata, or data types.

Something like: Tree ("variables"), metadata:roomid:username:variable_count, or variables:roomid:username:variablename.

To add proper variable support, we need to automatically chance dice pool qualities based on number of dice in the pool.

• Automatically go to a chance die if pool is <= 0.

If rolling 1 die, show "die." If rolling more, show "dice."

The dice bot should not run commands for old messages, in an attempt to cut down on duplicate spam if it's logged in from more than one place.

• Add a config parameter to control the oldest messages it should process.
• Default to 15 minutes (or maybe even less).
• Any messages older than current time - configured amount should be ignored when processing messages on startup.

Add a new device ID setting to the matrix configuration block, and use when connecting to the server with client.login. This should prevent the bot from creating endless secure sessions every time it logs in.