mirror of
https://github.com/zkldi/Tachi.git
synced 2026-09-26 08:57:58 +03:00
zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
60 lines
1.7 KiB
Markdown
60 lines
1.7 KiB
Markdown
# Personal Bests
|
|
|
|
Tachi has a lot of scenarios where it needs to reference
|
|
a users best score alongside their best lamp.
|
|
|
|
This is a standard for most arcade games to conjoin the
|
|
best aspects of all your scores, so Tachi needs to
|
|
replicate that behaviour.
|
|
|
|
However, not all games agree on what aspects to join about
|
|
scores. Although in most scenarios we will be joining
|
|
a user's best lamp with their best score, there are some
|
|
games (like IIDX) which have other statistics that need
|
|
to be conjoined.
|
|
|
|
*****
|
|
|
|
## Calculating Personal Bests
|
|
|
|
A user is only allowed one personal best per chart, this
|
|
allows us to know what personal bests need to be modified
|
|
by looking at the set of chartIDs modified from this import.
|
|
|
|
We can iterate over that set and recalculate the users
|
|
personal best for each chart.
|
|
|
|
Firstly, we select the users score on the chart with the
|
|
highest percent, then we select the users score on the
|
|
chart with the highest lampIndex.
|
|
|
|
We can then join the relevant properties of this
|
|
into a PBScore, where the best parts of the lampPB
|
|
are unioned with the best part of the scorePB.
|
|
|
|
!!! info
|
|
A ScorePB refers to a user's best Percent/Score on a chart.
|
|
|
|
A PBScore refers to the aforementioned conjoined score
|
|
document.
|
|
|
|
## Game Specific Things
|
|
|
|
Some games require specific conjoining code. The below games
|
|
have said exceptional behaviour.
|
|
|
|
### SDVX, USC
|
|
|
|
VF5 and VF6 depends on the users best lamp and their best score.
|
|
|
|
That is, you cannot just select the larger volforce from
|
|
the two scores, as HC 9m -> NC 9.1M should have the
|
|
volforce of HC 9.1M.
|
|
|
|
### IIDX, BMS
|
|
|
|
IIDX and BMS have BP. This number is the amount of bads
|
|
plus the amount of poors a player made. The lowest non-null
|
|
value for this should be selected as that property for the
|
|
PBScore.
|