Goal support needs to be ported from Kamaitachi. We should consider changing the goal format - The additional power it brings (at the performance cost) isn't worth it.

Support our own batchmanual format, I guess? We should make a couple of extensions to it based on some new IDs that can be used to lookup data.

Songs are done, charts aren't.

A 1:1 engine for BATCH-MANUAL, but interprets the data from the body of a POST request, instead of as part of a multipart file upload. This makes things simpler for people who are integrating stuffs.

Complex, and might not even be worth it.

The current scenario is that people have been able to technically stonewall themselves out of storing data - If they import a score with 100ex +HC on chart foo, and then later import a score with the same EX and lamp, but different metadata (i.e. more fields about gauge or whatever), the new data will be ignored (score documents will not be updated if the ID conflicts).

This was deliberate, but I wonder if it would be worth considering updating score metadata. Maybe? The performance hit would be HUGE, so this is low priority.

I'm not funny.

This would be a sequel to Walkure, but more competently designed. It's possible this could be the default metric for BMS 7K.

As for 14K, I don't really know what we would do, I'd have to talk to the people who play 14K more.

Snover said he'd look into it, but he hasn't gotten back to me yet, If he doesn't get around to it, I probably will.

Separate project. Lets just whip together an electron UI or whatever. Should be alright. Then we can pipe things to ir/direct-manual.

Shouldn't be too hard. A good excuse to pull MMind out as a framework and go from there.

We can add more IPC hooks to it, and generally make it better.

Main issue with MMind right now is that its a glorified command line, and bordering on user-hostile.
It'll just be an even more glorified command line, but uh, atleast it'll be cooler. Low priority, anyway.

We have a fresh BMS song database to work with, so we can probably just use that?

Oh, this is a new issue.

http://ereter.net/iidxplayerdata/78507798/analytics/perlevel/

This could be leveraged for Sg, but would also be interesting to just straight implement in IIDX? We'll see. Shoutouts to mr HI.

Support for USCs IR mode

Should be straightforward

Support for the XML exported format of SOLID STATE SQUAD. This is a legacy format.

Some care needs to be taken with respect to parsing XML.

Seems to be in demand, can leverage ktchiIR to send this over.

Formally known as dans, but named classes in Kamaitachi so it can also be used for jubeat's colours and so on.

These should be ported. Could be handled in score-import-main.ts as a post-cycle hook. probably.

I guess the main issue is actually knowing when or how to update these. Certain requests (mainly IR requests) provide metadata that lets us update classes. Sometimes, a class is dependent on a rating property instead of IR info (i.e. skill > 6000, rather than IR saying you are kaiden), so this definitely seems rather import-dependent.

We could have something like a set of importType "handle class update" hooks, but maybe they'd need to be returned from the parser as things like file/json:batch-manual could cause obvious generic-issues.

Will sleep on it, but could be more of a pain than initially thought.

Although the latter works, its transparently a hack. This needs to be pulled out unto chart documents.

This would add some overhead to chart calls, but ultimately shouldn't be that bad. We're allowed to store duplicate difficulties now, maybe we should change up our system a bit so that any difficulty name is legal? This wouldn't actually be an issue for anything other than colorizing difficulties. -- Just storing old charts under "DJT ANOTHER", and hidden by default? seems sensible.

As of now I need to manually run ipconfig and find my local networking IP, then hook it through with WSL - I don't want to do that, so, maybe there's something nicer?

There's no session code available at the moment (We're referring the Kamaitachi's "score sessions", rather than authtokens).

Needs to be sorted out, but at the moment is just stubbed.

Related to #5. This allows for more optimised lookups, and also reliably ignoring ancient charts.

Needs to be ported for obvious reasons, but we should probably investigate optimising them.

Unlike goals, I think it's reasonable for these to stay as meta-queries, but limiting them to only songs-charts (and storing relevant data as dataprops) seems reasonable. Maybe we could add a third option for routing through tierlists, but I think that could just be done in post.

Regardless, we can make some obvious improvements by cacheing the returns of folders (since they are static, pretty much) and using those instead of ever fetching things again. This would improve performance on goals, too, since we could perform reverse lookups and normal lookups on folder chartIDs.

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

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

Support for barbatos's IR-style posts.

Support for fervidexes' onScore hook - That is, when a score is posted from the score screen.

Low Priority, but could be neat with the UI to give live feedback on file-based imports etc..

Milestones need to be ported from Kamaitachi. We should look into creating "Milestone sets" (it's turtles all the way up!), so things can be grouped more appropriately.

We also need to completely redo a lot of the existing milestone goals -- they're broken in creative ways.

IDK if the site has been updated yet, but we should eventually go and update our data (maybe when bistrover ends?)

Support for the beatorajaIR as specified in ktchiIR.java

We could just go for something like

(method of entry):(filetype):(name)

such as

file:csv:eamusement-iidx
api:json:arc-iidx

this seems more reasonable

Coverage for UGS is rather low. It's stable from integration tests hitting it, but some unit tests wouldn't hurt. Low priority, though.

Need to speak with my favourite soup fella about this, since ATM chunitachi uses direct manual, when we could probably provide a more dedicated version of IR-style hooks for them.

Lower priority, not really needed for MVP.

We could investigate setting up webhook support, so people could create their own ktchi-dependent bots, or set up channels in their servers or whatever. I doubt anyone would ever use this though, so it's lower priority. Maybe I'll find some use out of it.

Needed for things like rating-core so it can ignore legacy scores (on charts that are no longer available and such)

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.

It is possible for a user to submit two identical scores in the same import. This could result in a scoreID collision mid-air, as the scoreQueue holds the scoreID that needs to be checked. This could be trivially worked around, I think?

Possibly. It could also end up as a race condition.

Needs investigating?

Port from Kamaitachi issues. I have some decent ideas for this, should work out nice.

Support for fervidexes static score submission feature (i.e. onCardIn requests). This produces less data than the alternative.

Should be decently easy to convert score-import-main into a queue-based thing.

Needs more investigation. Possibly a firewall bug, but dev can't continue under WSL2 because mongodb actually needs to connect.

No tests are wrote, should probably get on that - Surprisingly, there isn't a lot to test.