Home

MKMSZR technical knowledge base

MKMSZR is a native-ROM randomizer project for Mortal Kombat Mythologies: Sub-Zero on Nintendo 64. The supported game target is the USA Rev. 0 release; exact ROM identity and low-level validation details live on the owning technical pages rather than here.

This Wiki is the current technical and product knowledge base for the project. Use it to find current project state, 1.0 requirements, runtime evidence, implementation/reference material, stage catalogs, donor research, and preserved failure/history records.

Start here

• Project status — current production, proof-only, pending, and priority state.
• 1.0 requirements and roadmap — canonical 1.0 scope, acceptance criteria, blockers, and dependency order.
• Runtime validation status — current evidence matrix and runtime-validation scope.
• Contributor start here — repository workflow, build/test entry points, and contribution routing.
• Architecture overview — high-level system boundaries and patch/runtime architecture.
• Research methodology and evidence — evidence labels, bounded-experiment method, and research provenance.
• Glossary — project shorthand, technical vocabulary, acronyms, evidence terms, and donor/importer terminology.

Evidence labels

The Wiki uses six evidence labels consistently:

• Runtime-confirmed — observed in game/emulator on a defined build, route, state, and lifecycle boundary.
• Static-confirmed — established from ROM, Ghidra, source, or other static analysis without runtime execution.
• Implementation/CI-confirmed — established by repository code, generated output checks, or automated tests; not by itself runtime confirmation.
• Hypothesis / strong inference — supported by available evidence but not yet confirmed at the required static or runtime boundary.
• Rejected / failed — tested or analyzed and shown unsuitable within the stated scope.
• Pending — not yet resolved or validated.

See Research methodology and evidence for how these labels are applied, bounded-experiment methodology, provenance, and validation limits.

Find the right owner

Core technical reference

Use Core runtime and native payload for bootstrap/runtime mechanisms, Memory and allocation map for literal ROM/RDRAM ownership, Function registry for function semantics, Address and patch-site registry for guarded edit sites, Data structures and encodings for stable structure/codec grammar, and Resource and overlay system for file/overlay/resource-loading rules. Address quick reference is a convenience subset, and Testing and CI owns automated validation/publication mechanics.

Randomizer and product systems

Current system owners are Stage flow and selector, Pickups and stage-local randomization, Global item materialization and solvability, Persistence, inventory and lifecycle, XP and progression, Native HUD and UI, Presentation and branding, Audio system, Palette and recoloring, and Web patcher and product.

Stage reference

Stage catalogs is the shared index/legend for the eight main-stage catalogs and links to Temple, Wind, Water, Earth, Prison, Fire, Bridge, and Fortress.

Gameplay, enemies, and donor research

Start with Enemy randomization or Player actions and special moves for MKMSZ gameplay research. For donor work, use the MKT compatibility overview, then its focused owners: MKT adapter primitives, MKT fighter asset translation, Sub-Zero to Sektor animation mapping, and Sektor takeover proof history. Toasty work is split between Toasty audio research and Toasty visual research. Platform-specific donor/reference material lives in PS1 research and N64–PS1 comparison. The future execution order for a full PlayStation port is owned by N64 -> PS1 port planning and strategy.

History, failures, and provenance

Use Experiments, failures and superseded findings for the cross-domain rejected/superseded index, Milestone timeline for major chronology, TEST LAB proof history for the hidden-room and cross-stage materialization proof line, and Library artifact index for preserved research/archive provenance.

Canonical ownership

Prefer the current canonical owner pages linked from this Home page and the sidebar. Older pages may remain at stable URLs as supersession stubs for historical or external links; when a stub points to a current owner, the current owner is authoritative. Do not treat a retired or superseded page as current technical truth merely because its URL still resolves.