retroph / speedrun-watch Goto Github PK

Notably for NES & SNES runs feeds (also required for the upcoming GBA & GB feeds, with the 3DS VCs, and also GB/GBA with the GB player)

TODO:

• Check what other platforms need this support
• Find proper heuristic for multiple plaftorms (e.g. for gb/nes games - generally can assume priorities nes < snes < gba?)
• Fully list platforms to support for each VC platform

Does a naive traversal of runs list (assumed ordered by descending time) looking for runs with lower time.

Should use correct comparison for ascending leaderboards.

Example: https://twitter.com/SNESRunsFeed/status/936483396351602688 https://twitter.com/SNESRunsFeed/status/936633749298696193

Search by player ID in leaderboard doesn't work for guests, first run with undefined ID (guest run) taken.

Example: https://twitter.com/SNESRunsFeed/status/935493751920873474 https://www.speedrun.com/run/y976lx2m

Example: 5/4 https://twitter.com/SNESRunsFeed/status/936919387734339584

Run processing directly reads run category name and fetches link to category leaderboard.

Issues for subcategories:

• only name of parent category posted
• placement & diff computing from the full merged leaderboard

Example: ALTTP Major Glitches https://t.co/nOX49dhYL8 https://twitter.com/SNESRunsFeed/status/936086327103279104

Did not support them at first because it was simpler and I was not sure it was a good idea. But there are not many IL runs so it wouldn't hurt adding them.

Some games like the classic Sonic have their run retimed after submission (e.g. to remove bonus countdown times). For new/unverified runs on those games leaderboard and player PB comparisions are completely wrong.

Add a static list of games for which to remove LB/PB comparisons for unverified runs.

For Twitter those are less of an issue, they just result in "status is a duplicate" errors.

Root cause: DB triggers (on run creation) are only guaranteed to be run at least once, and should be idempotent.

See #7

With our cache of SRL runs it's possible to detect changes in the run data when it's verified (if not verified too fast, of course). Should gather per-game statistics of changes of time after verification.

Problem: cannot filter by game series on the runs API. Will sadly have to poll the new runs for each game separately.

Ideally should not get the game series info from SRC on each run. Simple implementation: store game lists as static JSON files (and deploy bot to update). Next version: store game series in DB and update it on a low-frequency cron.

TODO: need to improve update scheduling to allow this to scale. Maintain a global update frequency (e.g. 1 or 2 hours) for the whole series and spread game updates over time.