OPENHOOPS / 2K14Final team archive · November 9, 2026Reference libraryChecksums

Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.

Independent API clients — source0.2.0.dev55

Work64 adds the typed TypeScript client, read-only compatibility reports and eight game-free integration scenarios. See the developer guide. These tools passed headless acceptance; simulated inputs do not establish native gameplay acceptance.

Work63 adds native copied metadata, immutable match assets and additional scoped rule decisions. Headless checks pass; exact-DLL live game acceptance is pending. No public package is promoted.

Development53 adds the independent native C rule module, built against the matching experimental SDK. It selects frozen clock constants and a permission policy without a first-party application. Inspect /v1/rules and /v1/ball-state; unsupported mutation points remain unavailable.

Previous private51 also exposes rotation, timeout and connected-input controls through the same public HTTP/lease/command interfaces. No app-specific GUI or league database is required. Public preview2 remains the older API36.

These clients use the same HTTPv1 contract as third-party dynasty managers, career tools and mods. No first-party client or league database is required. Current private source is separate from public preview2/API36; see verification and external game flow for exact acceptance and limits.

Use a private token file; tokens stay out of URLs, plans and shared logs. Keep api on sys.path, and discover current capabilities, run/catalog/roster identities before applying commands. Game integration is Windows only; portable clients do not establish Mac/Linux game support.

Example Purpose
watch_scoreboard.py Current public snapshots in a terminal
watch.mjs Node HTTP/SSE reader; client owns cursor persistence, reconnect and deduplication
consume_results.py Basic independent result consumer; commit the app transaction before ACK
finish_match.py Durable SQLite inbox before ACK, lost-ACK recovery and optional explicit matching-owned-game closure
loading-screen.json Neutral version1 app-customizable managed loading configuration
launch_match.py Upload/hash-verify a prepared ROS, native load,13 pregame choices and direct native Start
prepare_matchup.py Export/preflight/apply13 pregame controls and loaded team/uniform choices
prepare_match.py Earlier eight-control preparation example
match_session.py Earlier phase10 attach/bind example, scoreboard and independent result transaction
scoreboard.py + scoreboard.html Local browser display through a token-holding backend

For a complete app-owned launch, use a version1 match request. It covers optional roster authoring/starting order/native minute preferences, roster intake/loading,13 pregame settings, per-child original/college duration and rules, startup options/sliders/controller preferences/coaching/defense, native camera, CPU or primary home/away participation and guarded phase4 external-identity binding. Product startup skips intro/title waits and uses a neutral/app-custom loading cover without generated input. Presentation, physical device selection/multiple humans and exact rotation scheduling remain separate.

Standalone preparation examples only configure the inactive game; launch_match.py or match requests perform loading/Start separately. Native roster replacement requires inactive Home, which managed startup retains under the loading cover. Quick Game uniform previews can lag; use requested values and gameplay readback. Registered ROS files can be queried/edited/prepared/exported with the optional shared writer; native load is a separate operation. No community roster is required.

For college, the app request selects1–20-minute halves with scaled OT and fixed TV marks. The generic pregame quarter_length_minutes field remains distinct; setting it does not change college half duration. Without a per-child override, the exe-local college INI remains the fallback. Use logical rule periods/ledger rather than interpreting raw NBA quarter labels. Ruleset identity metadata alone does not apply rules.

Live coaching/defense uses guarded paused commands. New substitution requests separately report queue acceptance and observed lineup entry. Lease, fresh revisions/preimages, run/period and native guards are required; the game controls the actual entry opportunity. Preferred defender is configuration, and physical holder/presentation remain observations rather than authoritative possession/live/dead-ball state.

For a finished managed match:

python examples/finish_match.py --token-file <private-token-file> --match-id <match-id> --consumer-id <app-consumer> --database <app-inbox.sqlite3>

Add --close-owned-game --client-id <launch-client-id> to explicitly close only the matching broker-owned run after the final result is stored and acknowledged. The helper never selects an unrelated process. Abandoned/review-required sessions need explicit app attention and do not produce fabricated results. A timeout sends no ACK or stop.

Commit (match_id,result_revision) idempotently in the app's league/career database. Repeated delivery or repeated ACK must not add totals twice; later immutable revisions reconcile the previous totals. Independent consumers acknowledge separately. The inbox helper is optional and does not couple the adapter to one client. Existing natural regulation/OT results retain their recorded scope; result export does not certify every basketball rule.

Use each script's --help for arguments. Recovery must inspect durable request/command receipts after ambiguous responses; never retry an uncertain Start with a new identity. Named SDK and HTTP interfaces remain available without any example UI. In-game presentation, unrestricted rule callbacks and asset hot-swap remain unavailable. Native metadata reads and selected per-match IFF overlays are separate opt-in candidate capabilities; inspect their committed/read status and current verification scope.