zkrising / tachi Goto Github PK
View Code? Open in Web Editor NEWA Cutting-Edge, Modular Score Tracker
Home Page: https://tachi.ac
A Cutting-Edge, Modular Score Tracker
Home Page: https://tachi.ac
Support for USCs IR mode
Should be decently easy to convert score-import-main into a queue-based thing.
Support for fervidexes' onScore hook - That is, when a score is posted from the score screen.
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.
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.
Should be straightforward
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?
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.
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.
Needs more investigation. Possibly a firewall bug, but dev can't continue under WSL2 because mongodb actually needs to connect.
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.
No tests are wrote, should probably get on that - Surprisingly, there isn't a lot to test.
Port from Kamaitachi issues. I have some decent ideas for this, should work out nice.
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.
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.
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.
Songs are done, charts aren't.
Support for barbatos's IR-style posts.
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.
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 ๐คฎ
Low Priority, but could be neat with the UI to give live feedback on file-based imports etc..
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.
Support for the beatorajaIR as specified in ktchiIR.java
Related to #5. This allows for more optimised lookups, and also reliably ignoring ancient charts.
IDK if the site has been updated yet, but we should eventually go and update our data (maybe when bistrover ends?)
We have a fresh BMS song database to work with, so we can probably just use that?
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.
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.
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.
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.
Coverage for UGS is rather low. It's stable from integration tests hitting it, but some unit tests wouldn't hurt. Low priority, though.
Needed for things like rating-core so it can ignore legacy scores (on charts that are no longer available and such)
Support for fervidexes static score submission feature (i.e. onCardIn requests). This produces less data than the alternative.
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.
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
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.
Separate project. Lets just whip together an electron UI or whatever. Should be alright. Then we can pipe things to ir/direct-manual.
Seems to be in demand, can leverage ktchiIR to send this over.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.