@oss-idle/addon-sdk 0.0.0-stage → 0.6.0

package/dist/bridge/character.d.ts

@@ -0,0 +1,91 @@
+/**
+ * Bridge to the player's characters.
+ *
+ * The client stores skills as flat columns on the `character` table - one group
+ * per skill (`speed`, `speedXP`, `speedUpgrades`, `speedOverdrive`,
+ * `speedPrestige`, ...) - and reconstitutes them into `Skill` objects when it
+ * builds its DAO. An add-on reads the row here and reconstitutes them the same
+ * way, using the skill factory bundled from the game's own sim, so a simulated
+ * play sees exactly the character the player is on.
+ *
+ * **Which row is "the" character is not obvious, and guessing wrong is quiet.**
+ * The table holds two populations:
+ *
+ * - the **local lineage** (`local = 1`, negative ids) - the Guest and its past
+ *   generations. Exactly one carries `current = 1`, set by `makeCurrent()`,
+ *   which updates `WHERE local = 1` and so never touches an account character.
+ * - **cached account characters** (`local = 0`, the server's own positive ids),
+ *   written whenever a signed-in session resolves.
+ *
+ * So `current = 1` means "the live *guest*", not "the character being played" -
+ * reading it while signed in silently returns a much weaker character, and the
+ * only symptom is that simulated results come out too low.
+ *
+ * The client resolves the real answer from session state held in module memory
+ * (`Entities.character`), which an add-on cannot read. But the answer is still
+ * recoverable from data: every finished play is stored locally with the live
+ * character's id, so **the most recent score names the character being played**
+ * - across sign-in, sign-out and account switches alike. {@link live} resolves
+ * through that, and {@link list} exists so an add-on can still show its choice
+ * and let the player correct it.
+ */
+import { type SqlValue } from './db.js';
+export type CharacterRow = Record<string, SqlValue> & {
+    id: number;
+    name: string;
+    generation: number;
+    overallLevel: number;
+    overallTotalXp: number;
+    memoryResetAt: number;
+    /** 1 for the local guest lineage, 0 for a cached account character. */
+    local: number;
+    /** Marks the live *guest*; meaningless for account characters. */
+    current: number;
+};
+export declare const gameCharacter: {
+    /**
+     * Every character on this client, account characters first, then the guest
+     * lineage - each list strongest first, which is also the order of "most
+     * likely to be the one being played".
+     */
+    list(): Promise<CharacterRow[]>;
+    /**
+     * The character being played.
+     *
+     * Resolved in order of how directly each signal answers the question:
+     *
+     * 1. **The most recent stored score's `characterId`.** Plays are saved with
+     *    the live character's id, so this is the game's own record of who was
+     *    playing, and it follows account switches for free.
+     * 2. **A cached account character** (`local = 0`), for a signed-in player who
+     *    has no stored plays yet - a fresh install, or a cleared local database.
+     * 3. **The guest**, for a player who has never signed in.
+     *
+     * Only step 1 is a fact; the rest are inference, so an add-on that acts on
+     * this should still show which character it used.
+     */
+    live(): Promise<CharacterRow | undefined>;
+    /** One character by id. */
+    byId(id: number): Promise<CharacterRow | undefined>;
+    /**
+     * The live *guest* - the local lineage's current character.
+     *
+     * This is what `current = 1` actually marks. Use it only when you
+     * specifically want the offline character; for "who is playing", use
+     * {@link live}.
+     */
+    guest(): Promise<CharacterRow | undefined>;
+    /**
+     * Apply a character row onto skill objects built by the game's factory.
+     *
+     * Mirrors the client's `Character` constructor. `skills` is whatever
+     * `makeOrderedSkills()` returned - typed loosely so this module stays
+     * independent of the bundled sim's own types.
+     */
+    applySkills<T extends {
+        name: string;
+    } & Record<string, {
+        set(value: never): unknown;
+    }>>(skills: readonly T[], row: CharacterRow): readonly T[];
+};
+//# sourceMappingURL=character.d.ts.map

package/dist/bridge/character.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"character.d.ts","sourceRoot":"","sources":["../../src/bridge/character.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AAEH,OAAO,EAAU,KAAK,QAAQ,EAAE,MAAM,SAAS,CAAC;AAEhD,MAAM,MAAM,YAAY,GAAG,MAAM,CAAC,MAAM,EAAE,QAAQ,CAAC,GAAG;IACrD,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,cAAc,EAAE,MAAM,CAAC;IACvB,aAAa,EAAE,MAAM,CAAC;IACtB,uEAAuE;IACvE,KAAK,EAAE,MAAM,CAAC;IACd,kEAAkE;IAClE,OAAO,EAAE,MAAM,CAAC;CAChB,CAAC;AAEF,eAAO,MAAM,aAAa;IAEzB;;;;OAIG;YACW,OAAO,CAAC,YAAY,EAAE,CAAC;IAOrC;;;;;;;;;;;;;;OAcG;YACW,OAAO,CAAC,YAAY,GAAG,SAAS,CAAC;IAgB/C,2BAA2B;aACZ,MAAM,GAAG,OAAO,CAAC,YAAY,GAAG,SAAS,CAAC;IAIzD;;;;;;OAMG;aACY,OAAO,CAAC,YAAY,GAAG,SAAS,CAAC;IAMhD;;;;;;OAMG;gBACS,CAAC,SAAS;QAAE,IAAI,EAAE,MAAM,CAAA;KAAE,GAAG,MAAM,CAAC,MAAM,EAAE;QAAE,GAAG,CAAC,KAAK,EAAE,KAAK,GAAG,OAAO,CAAA;KAAE,CAAC,UAC9E,SAAS,CAAC,EAAE,OACf,YAAY,GACf,SAAS,CAAC,EAAE;CAgBf,CAAC"}

package/dist/bridge/character.js

@@ -0,0 +1,107 @@
+/**
+ * Bridge to the player's characters.
+ *
+ * The client stores skills as flat columns on the `character` table - one group
+ * per skill (`speed`, `speedXP`, `speedUpgrades`, `speedOverdrive`,
+ * `speedPrestige`, ...) - and reconstitutes them into `Skill` objects when it
+ * builds its DAO. An add-on reads the row here and reconstitutes them the same
+ * way, using the skill factory bundled from the game's own sim, so a simulated
+ * play sees exactly the character the player is on.
+ *
+ * **Which row is "the" character is not obvious, and guessing wrong is quiet.**
+ * The table holds two populations:
+ *
+ * - the **local lineage** (`local = 1`, negative ids) - the Guest and its past
+ *   generations. Exactly one carries `current = 1`, set by `makeCurrent()`,
+ *   which updates `WHERE local = 1` and so never touches an account character.
+ * - **cached account characters** (`local = 0`, the server's own positive ids),
+ *   written whenever a signed-in session resolves.
+ *
+ * So `current = 1` means "the live *guest*", not "the character being played" -
+ * reading it while signed in silently returns a much weaker character, and the
+ * only symptom is that simulated results come out too low.
+ *
+ * The client resolves the real answer from session state held in module memory
+ * (`Entities.character`), which an add-on cannot read. But the answer is still
+ * recoverable from data: every finished play is stored locally with the live
+ * character's id, so **the most recent score names the character being played**
+ * - across sign-in, sign-out and account switches alike. {@link live} resolves
+ * through that, and {@link list} exists so an add-on can still show its choice
+ * and let the player correct it.
+ */
+import { gameDb } from './db.js';
+export const gameCharacter = {
+    /**
+     * Every character on this client, account characters first, then the guest
+     * lineage - each list strongest first, which is also the order of "most
+     * likely to be the one being played".
+     */
+    async list() {
+        return gameDb.select(`
+			SELECT * FROM character
+			ORDER BY local ASC, current DESC, overallTotalXp DESC, generation DESC
+		`);
+    },
+    /**
+     * The character being played.
+     *
+     * Resolved in order of how directly each signal answers the question:
+     *
+     * 1. **The most recent stored score's `characterId`.** Plays are saved with
+     *    the live character's id, so this is the game's own record of who was
+     *    playing, and it follows account switches for free.
+     * 2. **A cached account character** (`local = 0`), for a signed-in player who
+     *    has no stored plays yet - a fresh install, or a cleared local database.
+     * 3. **The guest**, for a player who has never signed in.
+     *
+     * Only step 1 is a fact; the rest are inference, so an add-on that acts on
+     * this should still show which character it used.
+     */
+    async live() {
+        const lastPlayed = await gameDb.value('SELECT characterId FROM score ORDER BY playedAt DESC LIMIT 1').catch(() => undefined);
+        if (typeof lastPlayed === 'number') {
+            const played = await this.byId(lastPlayed);
+            if (played)
+                return played;
+        }
+        const account = await gameDb.first('SELECT * FROM character WHERE local = 0 ORDER BY overallTotalXp DESC LIMIT 1');
+        return account ?? await this.guest();
+    },
+    /** One character by id. */
+    async byId(id) {
+        return gameDb.first('SELECT * FROM character WHERE id = ? LIMIT 1', [id]);
+    },
+    /**
+     * The live *guest* - the local lineage's current character.
+     *
+     * This is what `current = 1` actually marks. Use it only when you
+     * specifically want the offline character; for "who is playing", use
+     * {@link live}.
+     */
+    async guest() {
+        return gameDb.first('SELECT * FROM character WHERE local = 1 ORDER BY current DESC, generation DESC LIMIT 1');
+    },
+    /**
+     * Apply a character row onto skill objects built by the game's factory.
+     *
+     * Mirrors the client's `Character` constructor. `skills` is whatever
+     * `makeOrderedSkills()` returned - typed loosely so this module stays
+     * independent of the bundled sim's own types.
+     */
+    applySkills(skills, row) {
+        for (const skill of skills) {
+            const set = (field, column) => {
+                const value = row[column];
+                if (typeof value === 'number') {
+                    skill[field].set(value);
+                }
+            };
+            set('level', skill.name);
+            set('xp', `${skill.name}XP`);
+            set('upgrades', `${skill.name}Upgrades`);
+            set('overdrive', `${skill.name}Overdrive`);
+            set('prestige', `${skill.name}Prestige`);
+        }
+        return skills;
+    },
+};

package/dist/bridge/db.d.ts

@@ -0,0 +1,44 @@
+/**
+ * Bridge to the game's local database.
+ *
+ * The client keeps its state in an in-page sql.js database persisted to
+ * IndexedDB, and publishes the managed handle as `window.db` (see the client's
+ * `db/dao.ts`). An add-on cannot import the client's typed DAOs - it is a
+ * separate module graph - so it talks to that handle in raw SQL instead.
+ *
+ * Reads go through `db.read`; writes go through `db.write`, which is what
+ * persists the database back to IndexedDB. Writing with `read` would mutate the
+ * in-memory copy only, and the change would vanish on reload.
+ */
+export type SqlValue = string | number | Uint8Array | null;
+/**
+ * The game's database, addressed in SQL. `T` is the caller's assertion about
+ * the row shape - the game's schema is not visible to this module graph, so
+ * nothing can check it for you; keep queries close to the tables you know.
+ */
+export declare const gameDb: {
+    /** Every row a query returns. */
+    select<T = Record<string, SqlValue>>(sql: string, params?: SqlValue[]): Promise<T[]>;
+    /** The first row, or `undefined`. */
+    first<T = Record<string, SqlValue>>(sql: string, params?: SqlValue[]): Promise<T | undefined>;
+    /** A single scalar (first column of the first row), or `undefined`. */
+    value<T extends SqlValue>(sql: string, params?: SqlValue[]): Promise<T | undefined>;
+    /** One write statement, persisted to IndexedDB. */
+    run(sql: string, params?: SqlValue[]): Promise<void>;
+    /**
+     * Several statements persisted as one save - cheaper than a `run` each, and
+     * it never leaves the database half-updated on disk.
+     */
+    batch(statements: readonly {
+        sql: string;
+        params?: SqlValue[];
+    }[]): Promise<void>;
+    /** Whether the game has published its database yet. */
+    available(): boolean;
+    /**
+     * Resolve once the database is published. The client opens it lazily, so an
+     * add-on mounted at boot can easily beat it there.
+     */
+    ready(timeoutMs?: number): Promise<void>;
+};
+//# sourceMappingURL=db.d.ts.map

package/dist/bridge/db.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"db.d.ts","sourceRoot":"","sources":["../../src/bridge/db.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,MAAM,MAAM,QAAQ,GAAG,MAAM,GAAG,MAAM,GAAG,UAAU,GAAG,IAAI,CAAC;AAsC3D;;;;GAIG;AACH,eAAO,MAAM,MAAM;IAElB,iCAAiC;WACpB,CAAC,kCAAkC,MAAM,WAAU,QAAQ,EAAE,GAAQ,OAAO,CAAC,CAAC,EAAE,CAAC;IAI9F,qCAAqC;UACzB,CAAC,kCAAkC,MAAM,WAAU,QAAQ,EAAE,GAAQ,OAAO,CAAC,CAAC,GAAG,SAAS,CAAC;IAIvG,uEAAuE;UAC3D,CAAC,SAAS,QAAQ,OAAO,MAAM,WAAU,QAAQ,EAAE,GAAQ,OAAO,CAAC,CAAC,GAAG,SAAS,CAAC;IAK7F,mDAAmD;aACpC,MAAM,WAAU,QAAQ,EAAE,GAAQ,OAAO,CAAC,IAAI,CAAC;IAI9D;;;OAGG;sBACqB,SAAS;QAAE,GAAG,EAAE,MAAM,CAAC;QAAC,MAAM,CAAC,EAAE,QAAQ,EAAE,CAAA;KAAE,EAAE,GAAG,OAAO,CAAC,IAAI,CAAC;IAOvF,uDAAuD;iBAC1C,OAAO;IAIpB;;;OAGG;+BAC8B,OAAO,CAAC,IAAI,CAAC;CAO9C,CAAC"}

package/dist/bridge/db.js

@@ -0,0 +1,83 @@
+/**
+ * Bridge to the game's local database.
+ *
+ * The client keeps its state in an in-page sql.js database persisted to
+ * IndexedDB, and publishes the managed handle as `window.db` (see the client's
+ * `db/dao.ts`). An add-on cannot import the client's typed DAOs - it is a
+ * separate module graph - so it talks to that handle in raw SQL instead.
+ *
+ * Reads go through `db.read`; writes go through `db.write`, which is what
+ * persists the database back to IndexedDB. Writing with `read` would mutate the
+ * in-memory copy only, and the change would vanish on reload.
+ */
+const handle = () => {
+    const db = window.db;
+    if (!db?.read) {
+        throw new Error('oss!idle database not found on window - the game has not opened it yet, ' +
+            'or this add-on is running outside the client.');
+    }
+    return db;
+};
+/** Reshape one sql.js result set into plain row objects. */
+const toRows = (result) => {
+    const first = result[0];
+    if (!first)
+        return [];
+    return first.values.map(row => {
+        const out = {};
+        first.columns.forEach((column, i) => { out[column] = row[i] ?? null; });
+        return out;
+    });
+};
+/**
+ * The game's database, addressed in SQL. `T` is the caller's assertion about
+ * the row shape - the game's schema is not visible to this module graph, so
+ * nothing can check it for you; keep queries close to the tables you know.
+ */
+export const gameDb = {
+    /** Every row a query returns. */
+    async select(sql, params = []) {
+        return toRows(await handle().read(db => db.exec(sql, params)));
+    },
+    /** The first row, or `undefined`. */
+    async first(sql, params = []) {
+        return (await this.select(sql, params))[0];
+    },
+    /** A single scalar (first column of the first row), or `undefined`. */
+    async value(sql, params = []) {
+        const result = await handle().read(db => db.exec(sql, params));
+        return result[0]?.values[0]?.[0];
+    },
+    /** One write statement, persisted to IndexedDB. */
+    async run(sql, params = []) {
+        await handle().write(db => { db.exec(sql, params); });
+    },
+    /**
+     * Several statements persisted as one save - cheaper than a `run` each, and
+     * it never leaves the database half-updated on disk.
+     */
+    async batch(statements) {
+        if (!statements.length)
+            return;
+        await handle().write(db => {
+            for (const { sql, params } of statements)
+                db.exec(sql, params ?? []);
+        });
+    },
+    /** Whether the game has published its database yet. */
+    available() {
+        return !!window.db?.read;
+    },
+    /**
+     * Resolve once the database is published. The client opens it lazily, so an
+     * add-on mounted at boot can easily beat it there.
+     */
+    async ready(timeoutMs = 30_000) {
+        const deadline = Date.now() + timeoutMs;
+        while (!this.available()) {
+            if (Date.now() > deadline)
+                throw new Error('oss!idle database did not open in time');
+            await new Promise(resolve => setTimeout(resolve, 100));
+        }
+    },
+};

package/dist/bridge/playlists.d.ts

@@ -0,0 +1,55 @@
+/**
+ * Bridge to the player's playlists.
+ *
+ * A playlist is local to the client's sql.js database: one `playlist` row and
+ * one `playlist_entry` per difficulty, keyed on `(playlistId, beatmapId)`.
+ *
+ * **Writes must go through {@link gameDb}'s write path.** It persists the
+ * database back to IndexedDB; a mutation issued on the read side applies to the
+ * in-memory copy and is gone at the next reload, with nothing to show for it in
+ * between.
+ *
+ * **A write here does not refresh the client's own views.** They re-query on a
+ * version counter the client bumps itself, which lives in module state an
+ * add-on cannot reach - so song select keeps showing the list it last read
+ * until something else makes it re-read. Tell the player to reopen song select
+ * rather than leaving them to wonder why nothing changed.
+ */
+export type PlaylistRow = {
+    id: number;
+    name: string;
+    createdAt: number;
+};
+export declare const playlists: {
+    /** Every playlist, with how many difficulties each holds. */
+    list(): Promise<(PlaylistRow & {
+        count: number;
+    })[]>;
+    /**
+     * The playlist with this name, oldest first.
+     *
+     * The game does not enforce unique playlist names - `Playlist.create` inserts
+     * whatever it is given - so a player can hold two called the same thing.
+     * Ordering by id makes the choice deterministic: regenerating a playlist
+     * keeps overwriting the same one instead of picking arbitrarily.
+     */
+    byName(name: string): Promise<PlaylistRow | undefined>;
+    /** The difficulty ids in a playlist. */
+    entries(playlistId: number): Promise<number[]>;
+    /**
+     * Create a playlist holding exactly `beatmapIds`, replacing one of the same
+     * name. A generated playlist is regenerated often, so replace is the useful
+     * default - and clearing and refilling in one batch means it is never
+     * persisted in a half-empty state.
+     *
+     * Replacing keeps the existing playlist's **id**, so anything already
+     * pointing at it keeps pointing at it.
+     */
+    replace(name: string, beatmapIds: readonly number[]): Promise<{
+        id: number;
+        created: boolean;
+    }>;
+    /** Delete a playlist and its entries. */
+    remove(playlistId: number): Promise<void>;
+};
+//# sourceMappingURL=playlists.d.ts.map

package/dist/bridge/playlists.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"playlists.d.ts","sourceRoot":"","sources":["../../src/bridge/playlists.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAIH,MAAM,MAAM,WAAW,GAAG;IAAE,EAAE,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,MAAM,CAAA;CAAE,CAAC;AAE1E,eAAO,MAAM,SAAS;IAErB,6DAA6D;YAC/C,OAAO,CAAC,CAAC,WAAW,GAAG;QAAE,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,EAAE,CAAC;IAS1D;;;;;;;OAOG;iBACgB,MAAM,GAAG,OAAO,CAAC,WAAW,GAAG,SAAS,CAAC;IAO5D,wCAAwC;wBACd,MAAM,GAAG,OAAO,CAAC,MAAM,EAAE,CAAC;IAQpD;;;;;;;;OAQG;kBAEI,MAAM,cACA,SAAS,MAAM,EAAE,GAC3B,OAAO,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,OAAO,CAAA;KAAE,CAAC;IA8B5C,yCAAyC;uBAChB,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;CAM/C,CAAC"}

package/dist/bridge/playlists.js

@@ -0,0 +1,85 @@
+/**
+ * Bridge to the player's playlists.
+ *
+ * A playlist is local to the client's sql.js database: one `playlist` row and
+ * one `playlist_entry` per difficulty, keyed on `(playlistId, beatmapId)`.
+ *
+ * **Writes must go through {@link gameDb}'s write path.** It persists the
+ * database back to IndexedDB; a mutation issued on the read side applies to the
+ * in-memory copy and is gone at the next reload, with nothing to show for it in
+ * between.
+ *
+ * **A write here does not refresh the client's own views.** They re-query on a
+ * version counter the client bumps itself, which lives in module state an
+ * add-on cannot reach - so song select keeps showing the list it last read
+ * until something else makes it re-read. Tell the player to reopen song select
+ * rather than leaving them to wonder why nothing changed.
+ */
+import { gameDb } from './db.js';
+export const playlists = {
+    /** Every playlist, with how many difficulties each holds. */
+    async list() {
+        return gameDb.select(`
+			SELECT p.id, p.name, p.createdAt,
+			       (SELECT COUNT(*) FROM playlist_entry e WHERE e.playlistId = p.id) AS count
+			FROM playlist p
+			ORDER BY p.createdAt DESC
+		`);
+    },
+    /**
+     * The playlist with this name, oldest first.
+     *
+     * The game does not enforce unique playlist names - `Playlist.create` inserts
+     * whatever it is given - so a player can hold two called the same thing.
+     * Ordering by id makes the choice deterministic: regenerating a playlist
+     * keeps overwriting the same one instead of picking arbitrarily.
+     */
+    async byName(name) {
+        return gameDb.first('SELECT * FROM playlist WHERE name = ? ORDER BY id ASC LIMIT 1', [name]);
+    },
+    /** The difficulty ids in a playlist. */
+    async entries(playlistId) {
+        const rows = await gameDb.select('SELECT beatmapId FROM playlist_entry WHERE playlistId = ?', [playlistId]);
+        return rows.map(row => row.beatmapId);
+    },
+    /**
+     * Create a playlist holding exactly `beatmapIds`, replacing one of the same
+     * name. A generated playlist is regenerated often, so replace is the useful
+     * default - and clearing and refilling in one batch means it is never
+     * persisted in a half-empty state.
+     *
+     * Replacing keeps the existing playlist's **id**, so anything already
+     * pointing at it keeps pointing at it.
+     */
+    async replace(name, beatmapIds) {
+        const existing = await this.byName(name);
+        if (existing) {
+            await gameDb.batch([
+                { sql: 'DELETE FROM playlist_entry WHERE playlistId = ?', params: [existing.id] },
+                ...beatmapIds.map(id => ({
+                    sql: 'INSERT OR REPLACE INTO playlist_entry (playlistId, beatmapId) VALUES (?, ?)',
+                    params: [existing.id, id],
+                })),
+            ]);
+            return { id: existing.id, created: false };
+        }
+        await gameDb.run('INSERT INTO playlist (name, createdAt) VALUES (?, ?)', [name, Date.now()]);
+        const created = await this.byName(name);
+        if (!created)
+            throw new Error(`Failed to create playlist "${name}"`);
+        if (beatmapIds.length) {
+            await gameDb.batch(beatmapIds.map(id => ({
+                sql: 'INSERT OR REPLACE INTO playlist_entry (playlistId, beatmapId) VALUES (?, ?)',
+                params: [created.id, id],
+            })));
+        }
+        return { id: created.id, created: true };
+    },
+    /** Delete a playlist and its entries. */
+    async remove(playlistId) {
+        await gameDb.batch([
+            { sql: 'DELETE FROM playlist_entry WHERE playlistId = ?', params: [playlistId] },
+            { sql: 'DELETE FROM playlist WHERE id = ?', params: [playlistId] },
+        ]);
+    },
+};

package/dist/bridge/scores.d.ts

@@ -0,0 +1,28 @@
+/**
+ * Bridge to the player's play history.
+ *
+ * Every finished play is stored locally in `score`, stamped with the character
+ * that played it and when. That makes this table the only record of what a
+ * player has actually been doing - the client's own session state is module
+ * memory an add-on cannot read.
+ *
+ * Both helpers here count plays across the whole library in one query rather
+ * than asking per map, because the callers that want counts want all of them.
+ */
+/**
+ * Plays of each map by this character since `since`, by beatmap id.
+ *
+ * Mirrors the client's `Score.countPlays`, which is called per map with the
+ * character's `memoryResetAt`: plays from before memory was last prestiged do
+ * not count towards it, because that training is what the prestige spent.
+ */
+export declare const playCountsSince: (characterId: number, since: number) => Promise<Record<number, number>>;
+/**
+ * Plays of each map in the last 24 hours, by beatmap id.
+ *
+ * Mirrors the server's `recentMapPlays`: the last 50 plays inside a 24h window,
+ * counted per map. That is the window the server scores repetition over, so an
+ * add-on predicting what a play is worth has to read it the same way.
+ */
+export declare const recentPlayCounts: (characterId: number) => Promise<Map<number, number>>;
+//# sourceMappingURL=scores.d.ts.map

package/dist/bridge/scores.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"scores.d.ts","sourceRoot":"","sources":["../../src/bridge/scores.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAIH;;;;;;GAMG;AACH,eAAO,MAAM,eAAe,GAC3B,aAAa,MAAM,EACnB,OAAO,MAAM,KACX,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAUhC,CAAC;AAEF;;;;;;GAMG;AACH,eAAO,MAAM,gBAAgB,GAAU,aAAa,MAAM,KAAG,OAAO,CAAC,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,CASvF,CAAC"}

package/dist/bridge/scores.js

@@ -0,0 +1,43 @@
+/**
+ * Bridge to the player's play history.
+ *
+ * Every finished play is stored locally in `score`, stamped with the character
+ * that played it and when. That makes this table the only record of what a
+ * player has actually been doing - the client's own session state is module
+ * memory an add-on cannot read.
+ *
+ * Both helpers here count plays across the whole library in one query rather
+ * than asking per map, because the callers that want counts want all of them.
+ */
+import { gameDb } from './db.js';
+/**
+ * Plays of each map by this character since `since`, by beatmap id.
+ *
+ * Mirrors the client's `Score.countPlays`, which is called per map with the
+ * character's `memoryResetAt`: plays from before memory was last prestiged do
+ * not count towards it, because that training is what the prestige spent.
+ */
+export const playCountsSince = async (characterId, since) => {
+    const rows = await gameDb.select(`SELECT beatmapId, COUNT(*) AS n FROM score
+		 WHERE characterId = ? AND playedAt >= ?
+		 GROUP BY beatmapId`, [characterId, since]);
+    const counts = {};
+    for (const row of rows)
+        counts[row.beatmapId] = row.n;
+    return counts;
+};
+/**
+ * Plays of each map in the last 24 hours, by beatmap id.
+ *
+ * Mirrors the server's `recentMapPlays`: the last 50 plays inside a 24h window,
+ * counted per map. That is the window the server scores repetition over, so an
+ * add-on predicting what a play is worth has to read it the same way.
+ */
+export const recentPlayCounts = async (characterId) => {
+    const since = Date.now() - 24 * 60 * 60 * 1000;
+    const rows = await gameDb.select('SELECT beatmapId FROM score WHERE characterId = ? AND playedAt >= ? ORDER BY playedAt DESC LIMIT 50', [characterId, since]);
+    const counts = new Map();
+    for (const row of rows)
+        counts.set(row.beatmapId, (counts.get(row.beatmapId) ?? 0) + 1);
+    return counts;
+};

package/dist/build/index.d.ts

@@ -0,0 +1,73 @@
+/**
+ * The add-on bundler.
+ *
+ * oss!idle stores an add-on as one `source` string and loads it with
+ * `import(URL.createObjectURL(new Blob([source])))`. A Blob module has no base
+ * URL and no import map, so **nothing** resolves at load time: React, the
+ * game's simulation, workers and CSS must all already be inside that one file,
+ * and it must be an ES module exporting `mount` and `unmount`.
+ *
+ * That is what this produces.
+ *
+ * Output is **not minified by default**. Published add-ons are read by a human
+ * moderator before they go live, and a single minified line is a poor thing to
+ * ask anyone to review.
+ */
+import { type Plugin } from 'esbuild';
+/**
+ * The individual esbuild plugins, for a build that needs to assemble its own
+ * pipeline rather than call {@link bundleAddon} - compiling a slice of an add-on
+ * for a test, say, or bundling a worker on its own.
+ */
+export { assetQueryPlugin, cssTextPlugin, dedupePlugin, hostReactPlugin, inlineWorkerPlugin, sharedSourcePlugin, stubModulePlugin, tsExtensionPlugin, } from './plugins.js';
+export type BundleOptions = {
+    /** Entry module, exporting `mount` / `unmount` (usually via `defineAddon`). */
+    entry: string;
+    /** Where to write the single-file add-on source. */
+    outfile: string;
+    /** Root of an oss!idle checkout, to resolve `@oss-idle/shared` against. */
+    gameRoot?: string;
+    /** Banner metadata, so a reader can tell what the file is. */
+    meta?: {
+        name?: string;
+        version?: string;
+        gameVersion?: string;
+        license?: string;
+    };
+    minify?: boolean;
+    sourcemap?: boolean;
+    /**
+     * Modules to replace with throwing stubs, by path suffix - for trimming a
+     * heavy dependency the add-on never calls. See `stubModulePlugin`.
+     */
+    stubModules?: Record<string, readonly string[]>;
+    /**
+     * Packages that must resolve to a single copy even though the add-on's
+     * sources and the game's sources sit in different checkouts. See
+     * `dedupePlugin` - without this, shared libraries are bundled twice and
+     * prototype patches and `instanceof` stop working across the seam.
+     */
+    dedupe?: readonly string[];
+    /** Directory the deduped packages resolve from. Defaults to the entry's directory. */
+    dedupeFrom?: string;
+    /**
+     * Extra esbuild plugins, for the add-on and every inlined worker. They run
+     * before the SDK's own, so an `onResolve` here can redirect an import -
+     * one of the game's own modules, say - before the SDK resolves it.
+     */
+    plugins?: readonly Plugin[];
+    /**
+     * Use the game's React (`globalThis.ossIdle.react`) instead of bundling one:
+     * a much smaller add-on, and one React on the page. Needs an oss!idle that
+     * hands its React to add-ons; an older one refuses the add-on with a message.
+     */
+    sharedReact?: boolean;
+};
+export type BundleResult = {
+    outfile: string;
+    /** Byte length of the emitted source - what the workshop stores. */
+    bytes: number;
+};
+/** Bundle an add-on into the single ES module the runtime loads. */
+export declare const bundleAddon: (options: BundleOptions) => Promise<BundleResult>;
+//# sourceMappingURL=index.d.ts.map

package/dist/build/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/build/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AAEH,OAAO,EAAuC,KAAK,MAAM,EAAE,MAAM,SAAS,CAAC;AAe3E;;;;GAIG;AACH,OAAO,EACN,gBAAgB,EAChB,aAAa,EACb,YAAY,EACZ,eAAe,EACf,kBAAkB,EAClB,kBAAkB,EAClB,gBAAgB,EAChB,iBAAiB,GACjB,MAAM,cAAc,CAAC;AAEtB,MAAM,MAAM,aAAa,GAAG;IAC3B,+EAA+E;IAC/E,KAAK,EAAE,MAAM,CAAC;IACd,oDAAoD;IACpD,OAAO,EAAE,MAAM,CAAC;IAChB,2EAA2E;IAC3E,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,8DAA8D;IAC9D,IAAI,CAAC,EAAE;QAAE,IAAI,CAAC,EAAE,MAAM,CAAC;QAAC,OAAO,CAAC,EAAE,MAAM,CAAC;QAAC,WAAW,CAAC,EAAE,MAAM,CAAC;QAAC,OAAO,CAAC,EAAE,MAAM,CAAA;KAAE,CAAC;IACnF,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB;;;OAGG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC,MAAM,EAAE,SAAS,MAAM,EAAE,CAAC,CAAC;IAChD;;;;;OAKG;IACH,MAAM,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;IAC3B,sFAAsF;IACtF,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB;;;;OAIG;IACH,OAAO,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;IAC5B;;;;OAIG;IACH,WAAW,CAAC,EAAE,OAAO,CAAC;CACtB,CAAC;AA8DF,MAAM,MAAM,YAAY,GAAG;IAC1B,OAAO,EAAE,MAAM,CAAC;IAChB,oEAAoE;IACpE,KAAK,EAAE,MAAM,CAAC;CACd,CAAC;AASF,oEAAoE;AACpE,eAAO,MAAM,WAAW,GAAU,SAAS,aAAa,KAAG,OAAO,CAAC,YAAY,CAiD9E,CAAC"}