codehowlermonkey / hitfactor.info Goto Github PK

Because certain classifiers meet the bar for high-quality in some divisions and not others (particularly with fixed time classifiers that are too easy in PCC but more well-calibrated for minor handgun divisions), we should implement an Overall Quality score in its own tab under the Classifiers section.

This could be as simple of taking the MIN of the quality score for the classifiers across the more significant divisions (LO, CO, PCC, OPN, LTD).

This Overall Quality tab could serve as a one-stop shop for match directors looking to pick high-quality classifiers without needing to verify quality against all relevant divisions.

For testing purposes, it is helpful to reduce the polling intervals in uploadsWorker. We should not require one to change code every time uploads should be tested locally.

To achieve this, we can wire up a few additional environment variables to control polling frequency for fetch/upload.

I think we can just use https://primereact.org/messages/ and show it on top of Classifiers table with info style and something like: "Looking for which Classifier to Run? Select Your Most Popular Division and Sort by "Div. Qual". Or by OA Div. Qual to accomodate most divisions. Note: classifier quality isn't reflective of USPSA's official HHFs accuracy, and is only considering the accuracy of scores distribution.

Prob should fix 500, return empty table and no frontend fix required

Reclassify shooters is currently not implemented for SCSA.

Need to:

1. Implement method of computing + storing quotients of peak times and recommended peak times against shooter's current stage totals
2. Plumb the recommended classifications through to the Shooters/Runs pages

table is calculated when update is triggered for shooter, but graph is always fresh recalculation.

Should probably just use fresh recalc for table. Might even simplify things with RQ and staleTime. Just grab last value from the graph

Might need a PractiScore account, since there seems to be no open data to see something like https://practiscore.com/clubs/CLUB_NAME/results

1. Add hq/cur/rec letters to api/shooters/:division
2. Filter out where letters don't match
3. Probably do different modes: hq-vs-cur, hq-vs-rec, I think cur-vs-rec isn't needed as both are synthetic
4. review that classification percentage differences that we need for all modes are already there
5. api can return all needed data and not be aware of the mode
6. frontend can group by GMs/Ms by using multisort
7. additional mode/toggle can be all/demotions/bumps

OG idea from howler monkey discord server, if you're from there and have something to add -- please leave a comment.

Subj.

LO/CO is a synthetic division made out of a merge between LO and CO data.

It was hacked up as quick as possible, simply to make app not crash.
We need to review debug everything we can with LO/CO div and make sure it doesn't crash and also uses proper data.

Right now all HHFs for it are LO HHFs, and instead we should pick the highest from CO and LO. And maybe show both

Tooltip component from prime react library is unreliable and has weird targeting.

Replace it everywhere where we have tooltips with something else

Mostly this is useful for catching cheaters / reviewing clubs that have shooters with sus scores.

See #22

In Discord, the Monkeys have identified several serial cheaters, which often would edit their scores MUCH later than a reasonable match frame.

We already have reports and ability to mark scores as "bad", maybe we can look into edit history and auto-report scores for manual review, without the need to someone stumble upon them in the first place.

HF entries for classifiers above 120% could be marked as suspicious as well.
TODO: think about other automatic suspicious activity detection ideas and open issues for them

penalties field isn't consistent, instead to support procedurals we need to use proc, but that requires mapping + re-import.

Right now, things like filters, pagination, and sort aren't reflected in the URL.

It's not super hard to support this, but it requires significant effort for not-so-much of a reward (quick linking for sending your analysis data sources to someone else for discussion / review).

Parking this as a known issue / TODO / improvement

All classification algos should ignore zeros, but looks like something is blocking whatIf from firing if one of the classifiers has 0 hf.

Could be api, could be frontend. Probably just a falsy check instead of '' | undefined that should be used instead

Could be a good way to quickly look up something about the shooter that isn't available in the ShooterTable or RunsTable.

Maybe we can even fit graph in there, and definitely some version of a card, to show other divisions.

Could be web only using existing endpoints api/shooters/A99999

Probably can just use a simple fs.stat on one of the files updated by the import script.

Or even make import script write the date on start / completion.

should also include:

1. Rec. Percent in classifier scores table
2. Rec. GMs / Ms/ As in classifiers table
3. "Rec HHF" and "CurHHF - RecHFF" columns in the classifiers table
4. Rec. Percent & Rec. Class in Shooters Table
5. Same as 3. for shooters info

Related to #9, but unlike queryString params, this is about storing the default sort for each table in localStorage, so when user navigates to url without sort params -- we apply their last choice automatically.

Broke downloads with mongo, needs to be re-implemented.

top20 to infinity and beyond, use data from classifications at first and nothing else

clicking anything in that table goes to #3

When classifier scores were fetched we filtered out the inactive (as of Jan 2024) members.
The fetch for classifications of members was done after that only against active members.

This resulted in some scores show up with X classification and "Expired / Not Found".

We need to refetch expired members and possibly support active/inactive expiration status in addition to what we have now.

Probably is blocked by #2

Currently everything is stored and pre-hydrated on server start in-memory, often duplicating the same data multiple times for easier access (e.g. classifier runs by shooter or by division/classifier).

This causes 2 main problems:

1. Server requires quite a lot of RAM to run
2. It takes a noticeable time to hydrate the data, multiple minutes on M1 Pro Macbook, resulting in serious loss of productivity, when constantly changing the API and reloading the server.

We need to find a way to optimize both of these things, but the second one is more important, at least until we get to really high RAM usage, which will force us to change hosting (right now app idles at slightly above 4GB with legacy scores, and around 2 without).

Some ideas how to achieve this:

1. Sequelize + sqlite in memory, with proper DB tables design and basically rewrite of the whole model layer. HUGE EFFORT, HIGH CHANCE OF REGRESSIONS, if you can do this -- you're basically a legit senior backend dev.
2. RxDB, has in memory, is basically nosql, but has schemas, maybe can be hacked together moderately easy-ish. Higher Middle Dev Level
3. Just make GB+ JSON files work, JSONStream, await-sync, etc. Anything that will simply save shit to disk and cache it there. Won't help with memory, probably will make it worse. But should make development faster.
4. Any other ideas?