malleoz / mkwiitas

A one-stop shop to view all Nintendo track "Best Known Times" (BKTs) and current work-in-progress (WIPs) for Mario Kart Wii Tool-Assisted Speedruns.

Mario Kart Wii Tool-Assisted Speedrun Database

A one-stop shop to view all Nintendo track "Best Known Times" (BKTs) and current work-in-progress (WIPs) for Mario Kart Wii Tool-Assisted Speedruns. This repo also houses the Discord Bot that we use to interface with the repo from Discord.

Bot Features Implemented

Input parameters within [ ] are optional.

!bkt <track> [category] [laps]

• Retrieves the best-known time (BKT) for a (optional) given category and/or number of laps (3lap/flap)
• Directly links to the .rkg file for this ghost
• If no ghost file is uploaded, links to the YouTube encode

Todo

• Implement Discord Bot to create commits based off of messages posted to #collab-rksys. Otherwise, post notification in #collab-rksys if a commit is manually created on GitHub (if possible)
  • If user uploads directly, do we have a lists of pre-approved users or do we maintain a moderation process?
• Create folder hierarchy and establish how to organize BKTs vs. WIPs, and how to handle categories.
  • UPDATE: Added example folder hierarchy.
• Determine whether the repo should be public or limited to private chat members who wish to view it
  • If public, the process of uploading or replacing files is moderated through pull requests, so there is no risk of trolls trying to destroy repo.

mkwiitas's Issues

Future Workflow & Command Ideas (Part IV) - WIP Handling (Authors)

Author Handling

Automatically tracking authors of a given WIP

For every new upload from #collab-rksys-files, the username of the person who uploaded a file to the WIP will have their common name appended to the Names.txt file in a numbered list, given their name isn't on there already. This is useful for keeping track of how many people have worked on a TAS (and who) if there are enough people that it becomes difficult to keep track of (e.g. rBC glitch, only 1 or 2 people could have actually been able to find that 11 people worked on the run over the prior 4 months)

Retrieve list of authors of a given WIP

!name <track> <category> <laps>

Prints out track/category/lap data along with contents of Names.txt

Manually adding names to the author list

!add name <track> <category> <laps> <name 1> [name 2] [name 3] ...

Useful if there is an author not credited due to them not being the one who uploads the file to #collab-rksys-files

Manually removing names from the author list

!remove name <track> <category> <laps> <name #> [name #] [name #] ...
!remove name <track> <category> <laps> all

Useful if there is an author incorrectly credited due to them uploading someone else's file to #collab-rksys-files. Uses the numbers in the numbered list to know which names to remove without having to directly compare names (in case spelling and capitalisation are different). !remove name <...> all clears the entire list for when the WIP is over and you want to refresh the list.

Determine Workflow for Merging Finished WIPs into BKT branch

When a WIP is finished, handle the case where we want to merge this BKT back into the current branch.

There may be other files changed since this branch's origin, so we need to use the branch name to identify the file in question.

Future Workflow & Command Ideas (Part II) - BKT and WIP Storage

BKT & WIP Storage

Replacing a former BKT with a current BKT

!replace bkt <category> <laps> <rkg link or attached rkg>
!replace bkt <track> <category> <laps> <lua/csv link or attached lua/csv>
!replace bkt <license> <track> <category> <laps> <rksys link or attached rksys>

Can be used whenever a BKT is improved slightly and left for a while (butnot on mkwtas) or when a new run is added to mkwtas. Should not be used for WIP BKTs.

Creating new BKT category on a track

!new <track> <category>

Can be used whenever a new glitch is discovered that results in a new category being created. Creates category folder inside of both BKT and WIP sections.

Transferring BKT from one category to another

!tranfser <track> <category 1> <category 2> <laps>

Can be used in combination with !new or !old to move existing runs into the correct categories. Transfers files from/to category folders inside of both BKT and WIP sections.

Removing old BKT category on a track

!old <track> <category> 

Can be used whenever an unconfirmed new category is confirmed to be slower. Removes category folder inside of both BKT and WIP sections.

Manually uploading ghost to empty category folder

!add bkt <category> <laps> <rkg link or attached rkg>
!add bkt <track> <category> <laps> <lua/csv link or attached lua/csv>
!add bkt <license> <track> <category> <laps> <rksys link or attached rksys>

RKGs are kept in the same state as they are uploaded. LUA/CSV files are put through LUA-to-CSV and CSV-to-RKG converters. RKGs are extracted from within uploaded RKSYSes.

Future Workflow & Command Ideas (Part III) - WIP Handling (Ghosts)

WIP Handling

Manually uploading important ghosts for future reference

!add wip <category> <laps> <rkg link or attached rkg> [note]
!add wip <track> <category> <laps> <lua/csv link or attached lua/csv> [note]
!add wip <license> <track> <category> <laps> <rksys link or attached rksys> [note]

For every new rkg uploaded to a specific track/category folder, it gets assigned a 2 digit number (with leading zeroes) to the end of it (i.e. 3lap00, 3lap01, 3lap02, etc.) which serves as its ID and therefore can be used for ordering in a list when displayed.

Retrieving lists of ghosts in the WIP folder

!wip <track> [category] [laps]
!wip all
!wip new
!wip old

This would display a list of all WIP files for a certain track/category/laps restriction, sorted by ID, and displaying any notes provided in the !add wip commands. All lists all WIP files across all tracks, categories, and laps. New lists the newest 5 WIP files. Old lists the oldest 5 WIP files with the highest ID in its specific folder (i.e. the 5 WIPs that have lasted the longest without any progress - useful for keeping things moving).

Automatically uploading WIP files to WIP folders

<category> <laps> <rkg link or attached rkg> [note]
<track> <category> <laps> <lua/csv link or attached lua/csv> [note]
<license> <track> <category> <laps> <rksys link or attached rksys> [note]

Commands to be sent in #collab-rksys-files. Same extra steps and rules as !add bkt and !add wip

Manually removing unimportant ghosts to clean workspace

!remove wip <track> <category> <laps> <id>
!remove wip <track> <category> <laps> all

IMPORTANT COMMAND - would be used regularly by moderators to handle which RKGs stay in the WIP file list (this replaces the requirement of manual approval of repo branches). !remove wip <...> all removes all files in the WIP folder to do with that specific run for when a WIP is completed and the folder needs to be refreshed.

Replacing a former BKT with a new BKT from the WIP folder

!paste bkt <track> <category> <laps> <id>

Replaces BKT in BKT folder with specified WIP file (that contains the BKT) in WIP folder

Discord webhook test

Cool!

No need for WIP folders

There is no need for WIP folders, as we create forks to create WIPs.
Completing the WIPs causes forks to merge into the master.

Inconsistent subfolder hierarchy

We need to apply the following changes to the folder hierarchy:

1. Do away with the 3lap/flap folders. Instead, prefix each file with '3lap - ' or 'Flap - ' for example.

2. Standardize categories into one of the following:

   • UR: Unrestricted
   • NU: No Ultra
   • NG: No Glitch

   We believe this category organization is best due to complications that Supergrind categories present. In this standardization, Supergrind is treated as a Glitch.

Future Workflow & Command Ideas (Part I) - Repo Structure

tl;dr I'm hoping there's no need to use branches, also wips & bkts should be separate and there's lots of commands we can add.

all commands are assumed to be sent in #tas-github, except when specified explicitly

Structure of Repo

MKWiiTAS / Sections / Tracks / Categories / Laps

MKWiiTAS: This repository. Includes; README, Discord Bot, Compiled Rksys, and Section Folders
Sections: Best Known Times (bkt) and Works in Progress (wip) Folders
Tracks: Standard Abbreviations for NTSC-U names of the 32 nintendo tracks (prepending r for all retro courses)
Categories: Unrestricted (UR), No Ultra Shortcut (NU), No Glitch (NG)
Laps (in bkt section): 3lap/Flap.rkg for runs with ghosts, 3lap/Flap.txt for runs without ghosts (includes lap splits and YouTube URLs)
Laps (in wip section): 3lap##/Flap##.rkg, 3lap/FlapNames.txt

See reply for improved structure

Future Workflow & Command Ideas (Part V) - Help and Moderation

Help Commands and Moderation

Help commands

!repo Lists all of the following 5 commands

!repo <command> Prints how to use !
!store Lists all commands listed in #10
!work Lists all commands listed in #11 and mentions !work2
!work2 Lists all commands listed in #12
!mod Lists all the following 4 moderation commands

Moderation Commands

!addrole <type> <roleID> Gives a role permissions to use commands
!removerole <type> <roleID> Removes permissions for a role to use commands
!addchannel <type> <channelID> Adds a channel that you can use commands in
!removechannel <type> <channelID> Removes a channel that you can use commands in

Type label	Type description	Role	Channel(s) - doesn't include whatever mod channels exist
bkt	!bkt	TASer+	Bot spam Channels, VC Channels, TASChat, Technical TAS Discussion
wip	!wip	TASLabz+	Private Bot Spam Channels, Private VC Channels, TASChat
store	!store except !bkt	"BKT Site Mod", Repo Mod	TAS Github Channel
work	!work except !wip	Temp "WIP Mod", Repo Mod	TAS Github Channel, TASChat
work2	!work2	Temp "WIP Mod", Repo Mod	Private Bot Spam Channels, TASChat
mod	!mod	Repo Mod	TAS Github Channel

Wouldn't be exactly like this - these are just ideas like the other four parts.