Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.
Independent developer tools — private API55
The October20 team bundle now includes the matching runtime/writer, compiled/source SDK, eight scenarios, process-launch examples and complete dynasty integration documentation. This supersedes older no-package statements below for that requested delivery; native game proof and new package-specific headless checks remain separate.
Current work70: private API70e/API55 passes634 Windows tests/126 schemas; unchanged native70d retains470-check original/college adapter evidence. Original70liveo passes natural9–6 and college70liveq passes6–3, including copied native metadata, selected IFF reads, classification, independent immutable results and repeated ACK with zero faults. The college startup decoder fix is now game-verified. Both runs restore98 files/DLL50/INI; final preservation passes and custody is released for arena r11. Changed FT-count live verification remains limited to the recorded observations; no public/stable promotion. Earlier checkpoints retain their source scope. Current ledger.
These tools support third-party dynasty, career, scoreboard and mod applications through the same public HTTPv1 contract. They do not require a first-party app. The Windows adapter remains the original game with hooks; main snapshot ABI26/eventABI4 are unchanged. Work63's latest native additions still await their separate real-game acceptance. No new public Windows release is included here.
Check a match before launching
python -m openhoops_api.compatibility --request match.json --state PRIVATE_BROKER_STATE --game PATH_TO_NBA2K14_EXE --output report.json
The installed entry point is openhoops-check. Use the matching shared writer's absolute directory with --roster-tools when the request contains roster edits or lineup preparation. The output file is created exclusively; an existing report is preserved. Exit0 means the static checks passed,1 means a check failed, and2 means information is missing. No game is started and no match/request identity is reserved.
The same operation is available to authenticated clients through POST /v1/compatibility:
{"request":{"format":"openhoops.match_request","version":1},"game_path":"C:\\MyGame\\nba2k14.exe"}
The abbreviated request above must be replaced by a complete MatchRequest, including roster, configuration, preparation and identities. HTTP requests retain the existing64KiB JSON-body bound; the local CLI accepts request files up to256KiB. HTTP paths refer to files on the broker machine. Relative paths are resolved only by the CLI against the request file's directory. Existing content IDs need that broker's state.
Checks cover request shape/reuse, ROS checksum/framing/critical links, exact companion pairing, effective custom-field context, selected team/uniform ownership, player membership/names/slots, arena/playbook ranges, shared-writer edits, package/IFF hashes/conflicts, extension DLL envelopes and required hook version exports. Proposed edits and new archive intake use temporary scratch storage that is removed on completion. Source files, installed game files and the real broker state are unchanged. Package validation retains its3GiB floor and bounded size limits.
Every check has a stable ID, pass/fail/warning/unknown status, evidence and an actionable fix where applicable. Missing selections/backend/adapter information remain unknown. Runtime initialization, actual asset rendering, native callbacks and device behavior remain separate. Even a passed static report has live_readiness:"not_established"; the game can still refuse later if its actual state or input files change.
Typed TypeScript client
The local TypeScript SDK generates strict types for every maintained schema and HTTP operation. It provides authenticated JSON/binary requests, SHA-bound roster/metadata/asset uploads, cancellable SSE and durable-result consumption. Mutations are never retried automatically. An unavailable response from a mutation remains an unknown outcome; inspect the same command/request identity before deciding what to do next.
An application starts the existing broker with its versioned --match-request document to create an owned managed game. The TypeScript SDK talks to that broker; it does not silently create Windows processes. Loading/native Start, settings, leases and result transactions remain the documented public interfaces. Existing Python examples remain available.
Develop without a game
python -m openhoops_api.scenarios --state NEW_PRIVATE_SCENARIO_DIRECTORY --scenario successful-match
The installed entry point is openhoops-scenarios. It binds an automatically chosen loopback port and prints the base URL and private token-file path. Tokens never appear in URLs or console output. Each scenario uses separate persistent state. --resume accepts only a matching existing scenario manifest/database/token, and refuses unrelated broker directories. Stop with Ctrl+C; resume retains matches, results, command receipts and independent acknowledgments.
| Scenario | Behavior to exercise |
|---|---|
successful-match |
Bind, generate a coherent synthetic4–2 final, store before ACK, independent consumers and repeated ACK |
startup-refused |
Durable failed startup with started:false; no fabricated result |
uncertain-start |
started:null, scripted indeterminate Start and a lost command response; recover the same receipt |
stale-command |
A scripted clock-preimage conflict returns HTTP409 |
disconnect-recovery |
Preserve match/run identity across simulated source loss and reconnect |
abandoned |
An abandoned match produces no ordinary successful result |
review-required |
A changed roster context requires application attention; no ordinary successful result |
lost-ack |
Apply an ACK, drop its HTTP response, then recover from the client's committed inbox |
GET /v1/scenario returns the synthetic binding, request ID, scripted-command list and actions. Authenticate POST /__scenario/step with exactly one action: play, finish, disconnect, reconnect, abandon or review. These controls exist only in the separate scenario entry point; the production broker returns404. Steps are explicit and deterministic, with no wall-clock scoring progression. The simulator does not run a roster or assets inside the game.
The production Engine handles binding, event persistence, reconciliation, result schemas and ACKs. Snapshot inputs and the declared clock/Start outcomes are simulated. session.source is integration_scenario; matches/results retain metadata.openhoops_simulation:true and the scenario name. Use an application's development league/database for these fixtures. Simulation is evidence for client behavior, never native gameplay or rule acceptance.
Current acceptance and exact source identities. API tokens, scenario state and inbox databases stay private. The browser origin restrictions are unchanged; a hosted webpage needs an application's trusted local/backend bridge rather than putting the game token into a public site.