SDVX6 adds a new scoring system -- EX Score. This causes a myriad of problems for the site if we choose to support it, but it seems like more and more people are using it as a metric.

Infact, as time goes on I expect people to be using this more and more as players get bettter at PUCing charts.

This sucks, because it's very hard for us to implement it.

Outline

Tachi has no support for multiple scoring systems inside a score. You have score, percent and lamp. Those are all of the base properties. Since EXScore doesn't really fit into any of those, we can't use them.

Options

New Field

We could add a new object to all scores, called otherScores, or something. This would define a must-include list of other scoring systems that should be included as part of the score. This would allow us to overload a score document indefinitely with other scoring systems.

n.b. There are other games (such as DDR) which have many scoring systems actively used by the community, so this might be useful there.

HitMeta

We could put the value in HitMeta. It meets all the criteria to be hitMeta from a semantic perspective, but this isn't great. Scores can't have their hitMeta updated once they've been inserted into the database, and most of the time when people care about SDVX EXScore, they're getting a PUC. This means the score will have the same scoreHash, and therefore they would never be able to update their EXScore.

There is a separate issue (#622) that might be able to give us some more wiggle room there.

ScoreMeta

This does not make sense to go in ScoreMeta. Also, scoreMeta should have really been called playerMeta, or something.

CalculatedData

Not really. It can be calculated from judgements, but it shouldn't be.

cg505 appears to be championing this quite a bit as an idea, and there's no reason we can't. We'll just have to sit down at some point and talk about how the game works and then parse some chart data. Sounds easy enough. Which means it'll be fiendishly difficult.

Motivation: Getting someones "PB" is a very common operation. This was initially optimised for Kamaitachi 1.6 not long ago, with the isScorePB and isLampPB flags. The main issue is that these are disjoint flags, and don't exhaust all states of a "pb".

Functions like AutoCoerce handle the joining of isScorePB and isLampPB, but it's a weird performance hit.

The other issue is that there are other things (like BP in iidx) which may be under neither flag (although this is rare). Could we perhaps do something like a "pb-scores" collection which is updated on score-submission? This would be heavily optimised, and reduce calls to things like AutoCoerce.

Downsides: Heavy redudancy! We're copying score documents, more or less. We're conjoining scores that can't properly be referenced, either.

This should probably be sat down and thought on. We'll see how everything looks when we approach the tail end of the score import cycle, since that should give us a better idea. I think this might be good though.

When a push is made to the main branch the bot should auto-deploy to the server.

The following secrets need to be set up on the repo:

ENV=PROD
PROD_DISCORD_TOKEN=discordToken

These env vars are used by createEnv.sh to generate the bots environment file. When pushing the bot to the server ensure you run this script beforehand and also push the generated .env file

This ticket is blocked until TNG-dev/tachi-bot#10 is merged

I want to display a Ranking-over-time graph on the overview, and maybe a cumulative playcounts one.

The latter can be derived cheaply, but the former absolutely can not. Could we set up some sort of cronjob to do this?

cc: @ereti

By using beatoraja's table functionality, we can create dynamic pseudo-tables based on some things users have going on. This might open the door for some interesting concepts.

We don't have to actually honour the concept of a table being an ascending list of folders, but rather take advantage of the fact that we can just create folders dynamically -- things your rivals have played recently, things you've highlighted recently, etc, definitely challenge integration.

We'll see.

Amusing note: The checksums used by USC include the chart level; this means that people playing the game cannot change their levels locally, or they will no longer have the same chart checksum as everyone else. Wonderful!

However, we can change this in the seeds and it will propogate fine in the UI (and fix some faulty VF calcing)

Needs to be ported from KT. Should be decently simple, maybe. This is related to TNG-dev/Tachi#462, too (sorta?).

Could be done tonight, seems easier than writing goal support 🤮

Oh Boy, this might be worse than any other data issue we've had to deal with so far.

Overview

Charts in USC are identified by their sha1sum. This is great for avoiding stupid things like songtitle matching (which is a terrible idea). BMS uses this with md5/sha2, and it works great over there. The difference - however - between bms and usc in this regard is that USC charts are mostly converted by hand from SDVX.

It's also worth noting that 10 minutes ago I was told that almost every single convert has a noticeable error, such as missing notes, notes on completely wrong snaps, or holds that end way too early. This is the crux of the issue -- so many people are silently playing on broken or different versions of the 'same' chart.

Since we use the sha1sum to identify charts, all of these charts are regarded as different charts. This means the IR inevitably gets flooded with garbage, and we have to deal with it all. There isn't a nice fix for this at the moment.

I'm thinking of standardising on the oniichan converts, since those seem to be what most players use. However, there's no telling whether they'll silently back-update charts, or some garbage like that.

Standardising doesn't help much either, since thousands of players still have incorrect converts on their harddrive, and asking them to update to different versions is going to be a massive pain. I think we are actually just kind of screwed here.

Unscrewing

One of the hacks we could use is rejecting new charts on the IR if and only if they have the same song title as an official already on the IR, and the same difficulty. This would reject spam small diffs to the IR, and ultimately reduce the amount of cleaning that has to be done.

I'll also need to append the sha1sums from oniichan at some point. That'll be fun.

I've been playing it too much and it'll take too long to write my own client (even though that's 100% what needs to be done.)

This is a stopgap solution but I think it'll be fun. We'll fork the groovestats launcher and push tachi into it, then we'll roll.

I only intend to support ITG Stamina at the moment -- they'll be separate GPTs (ITG Stamina (Single), maybe?). Then I'm just going to add support for all the packs I care about. That's ECS8 -> ECS10.5 and SRPG3-5. That's enough content for everyone, right? I don't really know. Our tables/folders solution should end up being fairly elegant though.

I wonder what kind of data we can pull from the client?

For scoring, I'm torn on what to actually use. EX Score is probably better for Stam FA nerds? I don't really know or care that much, since I think I'm personally only going to be focused on lamps.

We'll use a profile rating of like, avg best 20 blocks. Seems good to me. We can also have server announcements for when someone raises their block level.

This support will effectively just be for my personal usage, I don't intend for this to be a groovestats replacement or anything (Those guys are working on a full site rewrite, so god knows what I'm intruding on.)

This would allow for better in-game integration of quests and goals. The playlister .json format is documented in the 🐽 thread

A playlist would contain folders only for specific timing/clear goals, for example the Approaching Chuuden playlist would have HARD CLEAR, CLEAR, AAA and MAX- folders. For a CLEAR any one of type of a goal, a separate folder with just these charts would be created.

updating the seeds to match with live JP ratings.

currently a draft PR since i'm going through all the charts for each decimal level, shouldn't take too long to go through them all though as i only need to go down from 14.9 to 12.7.