foxlisk/nmg-league-bot

NMG League evil mastermind

nmg-league-bot's Issues

use DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE

/schedule_race takes a little while now, because it creates a bunch of posts and stuff. it would be a better UX to have a loading thing i think.

edit commentators on confirmed races

i often want to get a 1-comm race in front of ZSR but then be able to add comms to it later. currently i don't have a good way of doing this.

restream info in database

admin command to reschedule race

let users submit grievances via the bot?

seems like a good way to make grievance-submission private? idk if this is good or not

forfeit should ask for confirmation

validate twitch user_logins

reformat into lib with bins

its really nice, as i learned on the alttp queue bot project, to have the code structured mainly in a lib that i can write binaries off of. for example it'd be nice to be able to write a CLI tool to manipulate the database. but right now that would be very difficult.

handle players dropping

validate racetime usernames

when generating pairings, validate that it's possible *before* saving the new round

error handling

i think the way to do this might be to have handle_interaction dispatch to methods that return Result<InteractionResponse, String>. if they return an InteractionResponse, we respond to the original interaction with it; otherwise we send an error to the admin (async?) webhook.

probably String is worse and we want an error type - perhaps actually the error type encodes async vs admin messaging

reify bracket race info state?

that is to say, have a state field with options such as UNSCHEDULED, SCHEDULED, COMMENTARY_CONFIRMED, RESTREAM_CONFIRMED and maybe something like FINISHED to top it off

generate_pairings command spits out a bad link now that all my links changed

interaction custom IDs could have useful info

right now we have the "message id" tracked in the db, and custom IDs on interactions are like start_run

but presumably it would be fine to have custom IDs be like start_run_12345 and have that link back to races?

I don't know if that's user visible data or not, though; this is only a reasonable plan if the labels are never exposed to the end user

DM channel id in player record

probably doesn't matter but would save us an API request sometimes

Race management operations

Players should be able to manage the lifecycle of their races via bot:

• scheduling
• asyncing if necessary
• reporting times/winner/just the racetime room probably

i would like this to do neat things like "your opponent has scheduled a race for <time>. does this look right?" but maybe that's unnecessary

it would be pretty cool if creating application commands were sort of declarative

async table doesn't display times

/remove_player_from_bracket

twitch username/id/something in player model

prevent commportunity spam at least a little

right now every new reaction creates a sirius-inbox post if there's >=2 players signed up, which means if someone selects 10 emoji, we'll get 10 sirius-inbox posts :\

link accounts together properly

this would involve logging in with discord and then logging in with twitch to link the two

proper rtgg integration is also a possibility

Model players

get to zero panics after launch

eliminate every unwrap(), expect(), etc. panicking before launch is fine, e.g. on missing config values, but should have absolutely no crashes once running.

Model seasons

this ticket will include i think all the stuff to run "a season"

so we need

• Season
• Bracket
• (possibly Category)
• Round
• Pairing (once again, this line of work does not involve constructing pairings, just being able to model them)

anything else?

rescheduling should clear existing events and so on

if a scheduled race gets rescheduled, we should roll back some state about commentators, events, etc

let players update

e.g. users should be able to change restreams_ok and racetime_username

confirming commportunities post with nobody signed up is bad

it fails to create messages with empty bodies and stuff

Handle ZSR/comm/event stuff

races, when scheduled, should do things like:

• Create events
• Create a place for commentators to volunteer
• Let ZSR know that there's stuff to be scheduled
• Possibly publish to an external calendar?
• sync things up (make sure the event, the messages ZSR deals with, etc, are all synced up)

a way for admins to reschedule an arbitrary race

model messages better?

right now i'm just sticking tons of message IDs on BracketRaceInfos and sort of remembering what the channel_id is supposed to be

i kind of want to write down the channel_id as well, but that's a terrible number of fields for a model IMO

so it would be something like creating a messsages table and FKing it which also seems awful

so idk

a simpler way to keep discord state correct

a bunch of stuff is reactive right now that should probably be more stable

e.g. the information about "who has signed up to comm a race" only exists in the form of reactions in discord

you could imagine a world in which we write down everything. and then user interactions simply write state down, and there's some sort of worker task that enforces state coherence.

basically, i'm worried about complexity here. when some unexpected user action occurs - say, rescheduling a race that has commentators already assigned - are we really gonna clean up all state appropriately? it would be nice to be able to idempotently ensure it.

Investigate orms

we probably want some ORM. the ones i see so far are:

• ormx - seems very lightweight, but also very easy to drop in. not that i have that much db code to worry about yet or anything.
• diesel - seems very heavyweight. it's not async but i don't actually think that matters. also it seems like work to provide an async version is coming along.
• sea orm - seems somewhere in between, weightclass wise. based on sqlx so probably an easier migration story - also actually has a migration story, or at least a "get started from an existing db" story: https://www.sea-ql.org/sea-orm-tutorial/ch01-04-entity-generation.html. this doesn't seem that great. just like aesthetically, or ergonomically, the queries and stuff look gross to work with
• rbatis - this looks extremely non-ergonomic

/update_another_players_user_info

run start error handling sucks

take year boundaries into account

e.g. if you are scheduling a race on december 30th for january 2nd, that will not work right now

autocomplete

im not going to implement autocomplete yet. but i will (hopefully!) track places where it might be useful, in here

• create bracket
• report race
• generate pairings

standings page includes OMW

Admins can manage async run state

admins should be able to do things like mark a player as forfeited, or update their time/vod URL if necessary

runs that get finished should have their commportunities posts removed, too

handle race rescheduling better

right now we leave all the old stuff around and just create a new "commportunities" post

it would be good to do some things such as:

• delete the old commportunities post (if commentary not scheduled yet)
• delete the existing zsr post (if commentary already scheduled)
• potentially alert sirius/zsr to the new state of affairs more forcefully (with a new message or perhaps even a ping)

Let users create their own async races

Right now this has to go through an admin, which is like 10% so that an admin is involved and 90% because it was simpler to implement. I think letting players handle their own asyncs would be fine, though.

better state handling in async races

right now we're sort of counting on the message interactions to be in sync with the race state, but we should be more careful about that. at the minimum, we want to know about any discrepancies, even if we can't do much about them

twilight?

either serenity isn't a great pick for this or i just personally don't care for it, because i am finding it increasingly frustrating to use. maybe look into popping in twilight.

use global application commands?

Guild commands are available only within the guild specified on creation. Guild commands update instantly. We recommend you use guild commands for quick testing, and global commands when they're ready for public use.

https://discord.com/developers/docs/interactions/application-commands#registering-a-command

asyncs page should be sorted

admin command to update recorded race

races need a "ignore permanently" state or something like that

if races get in bad states the cron just prints out shit like Error fetching runs for race 7b7e3fa9-d515-44a4-9759-d562a106c7d1: Did not find exactly 2 runs forever, which sucks

warn on signups if conflicts are known

chex signed up for comms when he had a race of his own an hour later; probably we can call this out somewhere (in #sirius-inbox if nothing else) to avoid in the future