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.

Research findings and experiment map

Current implementation/operations are summarized in CURRENT-STATE and API verification. BaselineCD-executable hashes, old startup blockers and proposed research sequences below are retained historical/source evidence. The supportedISOvariant has completed Windows matches and the agreedcollege mechanics/API reference exports are implemented. Full native boot is not the project goal; Mac/Linux delivery remains deferred.

Current scope (October13,2026): Windows-first deep editing and a public extension API; Mac/Linux compatibility follows later. Earlier native-port goals and next-step proposals in this evidence history are superseded. Technical observations and verification limits remain as recorded.

These notes connect the archived community material to this project's goals. Community observations remain hypotheses until checked against our own original game and controlled experiments.

Runtime and Mac/Linux baseline

The supplied executable is an x86 PE32 Windows image with version resource 1.0.1.1. Its SHA-256 is becdfca16a88f656bc20dde608bd38becf0b8e04bf41c8041d344e37d20e1d67. The inventory contains 4,906 files totaling 7,740,668,616 bytes, excluding .DS_Store. See executable metadata and game manifest.

The image contains a .securom section. That is a static observation, not a tested explanation of startup behavior. Imported APIs include Windows input, networking and runtime libraries. The game readme identifies DirectX 9 requirements; static imports alone do not characterize every rendering path.

The FPS discussion reports severe slowdown on exFAT that disappeared on NTFS, and stalls caused by attempts to contact retired servers. These are useful experimental controls, not established behavior of APFS, Linux filesystems or our executable. Record filesystem, network behavior, startup logs, menu responsiveness and frame timing separately. Avoid changing machine-wide networking based solely on an anecdote.

The SweetFX workaround concerns injected graphics components and driver compatibility. It does not demonstrate replacement of the engine's renderer.

Current sequence: complete the Windows deep-editing and public API workflow, then test compatible game execution on macOS/Linux, including graphics, audio, input, saves and resource loading. Full native recompilation is not a milestone in this plan. A renderer rewrite requires finding engine boundaries and resource ownership, not merely replacing DLL filenames. Since this initial research map, the supplied ISO variant reached active first-quarter play on Windows and the menu through Wine/Rosetta on Mac. Linux execution and native-game boot remain unverified. See current runtime evidence and customization strategy assessment.

File containers and resource ownership

The file structure reference is the best initial map:

File family Community-described role Research use
global Models, accessories, lighting and assorted menu assets/audio Identify independent resource types inside a shared container
english and other languages Text and some menu elements String tables, fonts and localization
gamedata, gamedataextra Replay indicators, officials, ability icons and other game assets UI/gameplay resource boundaries
newscorebug, overlay files Scoreboard and broadcast overlays Separate art/layout from data binding
jukeboxmusic Soundtrack Audio entry indexing and replacement
cloth, _param Uniform models and related parameters Geometry/parameter coupling
titlepage Intro-screen art Small initial UI round-trip fixture
nbaball, ball variants Ball assets Compact geometry/texture fixture

The texture-name index and authentic player IDs can seed lookup tables. They are historical mappings, not automatically valid identifiers in every roster or total-conversion mod.

Decompression requirements vary by operation. The HoS roster workflow needs a decompressed container, while the animation workflow explicitly asks for an original, non-decompressed container in RED MC. Keep both representations with provenance. Do not normalize every IFF in place.

First parser experiment: enumerate headers, resource tables, compression signatures and sizes on copies; compare an untouched file with one minimal editor change. Success requires preserving unknown chunks and game acceptance after save/load. Do not assume all .iff files share an identical schema.

Rosters, player creation and intake

HoS Profiles describes roster location precedence between the main directory and Online Data, separate cyberface/portrait/ASA identifiers, and reloading with Options → Reset Roster. This provides a documented menu-level reload workflow; it does not establish mid-possession hot reload.

The author describes stored ratings on a 0–255 scale and displayed ratings as stored / 3 + 25, with inverse displayed * 3 - 75. Validate rounding, bounds, integer representation and roster version before using the conversion in an importer. The post lists 42 rating rows; row 5 is explicitly unknown and must remain unknown until investigated.

Team insert/swap is relevant to team identity and cross-roster references. CAP diversification identifies Rookie_Templates, CAP_FType, CAP_Hlen, Muscles, and generated-player filters IsGener=1, IsRegular=1, IsUnused=0. Historical licensing requirements are described in the source, not inferred to be current.

Custom MyCareer sources: custom rosters, UBR-specific variant, existing player, custom MyPlayer. Treat save-file and roster-file schemas as separate until demonstrated otherwise. The draft-class discussion adds Association-specific context.

Proposed intake pipeline: import neutral records, validate ranges and referential integrity, show a human-readable diff, export into a copied roster, reload, then verify identities and ratings in-game. Never use player row position as a universal persistent ID.

UI, scoreboard and live updates

Start with title-screen editing, controller icons, and font65 editing. The font author reports historical 64-bit save crashes in the 2K9 editor and a 32-bit workflow. That is evidence about that tool, not a requirement for a new parser. The font recipe distinguishes group0/group1 mipmap behavior and alpha handling; preserve those differences in fixtures.

Custom UI has at least three investigations: resource decoding, layout/composition, and the game state feeding the screen. A new scoreboard skin does not by itself expose score/clock/foul data or let us replace interaction logic.

Proposed live-update experiment: track which files are read at startup, menu entry, game load and replay transitions; change one copied asset between safe states; record when the resource is reloaded. Only after identifying caching and ownership should we attempt runtime invalidation or hooks. No archived tutorial proves arbitrary mid-game file replacement is safe.

Animation and gameplay rules

New source lead: Elan 2K Mod implements live-memory changes for clocks, scoring and period behavior. It supplies concrete candidates for rule research beyond the tutorial corpus. Its two-halves implementation skips a period value; comprehensive college-rule behavior and compatibility with our executable remain unverified.

The animation thread explains named animation records, four-byte identifiers, byte reversal for searching, and adjacent parameters. Crucially, its January 2017 correction withdraws earlier executable-edit instructions after discovering the author had used a modified executable. The author did not verify the equivalent original 2K14 behavior. Do not carry historical executable offsets into our build without matching hashes and disassembly.

College presentation assets, roster size, team identities and actual rules are distinct. The archived court/uniform resources help presentation. They do not establish patch points for halves, shot clocks, bonus fouls, possession, timeouts, overtime or tournament scheduling. We need a rule-state model and independent tests for each proposed rule change. The blank schedule bug is a useful warning that mode state and calendar generation can interact.

Graphics assets and audio

High-resolution courts, court bump maps, uniform templates, cloth/net models, cyberfaces and accessories provide controlled asset-editing candidates. Increased texture resolution is not evidence of a modern graphics API.

Jukebox editing and hidden FIBA audio IDs suggest useful audio indexing work. An ID list establishes an author-reported mapping, not a complete audio format specification.

Historical initial work queue

This table preserves the original resource-research sequence. It is superseded by the Windows-first API, external-mode and deep-editing priorities in the current plan. Mac/Linux work comes afterward.

The community hooks archive now adds BodyHook's per-player resource maps and preview-refresh configuration, Blaze's C plugin ABI, NBA2K14 HOOK's compiled Lua editor/rule plugins, two shot-meter implementations and QOL2K's audio package. These provide implementation references for several experiments below. Loader collisions, fixed executable profiles and Windows overlay dependencies must be resolved independently; the packages have not been run locally.

Priority Experiment Completion evidence
1 Launch baseline and target-platform feasibility Repeatable startup, gameplay, audio/input and save/load logs
2 Container inventory and minimal round trip Original/edited hashes, bounded byte diff, accepted in-game asset
3 Roster schema and neutral importer Validated IDs, explicit unknown fields, successful reload
4 Scoreboard/UI asset and data flow Resource map plus verified clock/score bindings
5 Resource lifetime and reload boundaries Observed reads, cache behavior and safe update point
6 Rule-state and renderer boundaries Traced code paths and isolated proof-of-concept changes

Keep negative results and corrections alongside successes. Every technical claim should link to either a source post or a reproducible local experiment.