Happy New Year

on

Firstly, Happy New Year!

Over the past few days, I’ve been exploring other games to see how they might help with hacking WCW/nWo Revenge. I ported my multicolored rope code over to VPW2, partly as a test and partly because I’ve been wanting to do a “WWF Golden Era” project in one of these games. VPW2 in particular has a great aesthetic that really fits the old-school Saturday Night’s Main Event feel.

I also took a look at the save mechanics in WrestleMania 2000. I was able to trigger an “Edit All” mechanism, but I am still learning how the game writes data to SRAM. By default, the game includes 50 WWF characters with name and attire editing, along with 16 Originals that allow full editing. The move set and parameter data for Original A appears immediately after the name and attire data segment.

The goal is to get slots 1 through 50 to appear before Original A, which would allow for a fully editable roster. That is on the back burner for now, but the findings are well documented for future reference.

I’ve also been indexing the moves in Revenge to better create movesets. Testing moves, identifying accurate reversal data, and documenting “glitched” or doubled data has been time-consuming. Moves that involve pinning, submissions, or repeating animations require multiple addresses to be properly linked in order to work correctly. The more I learn, the more I’ll be able to import and edit moves in the future.

Secondly, I have one main goal for this year: importing music into Revenge. Obviously, it’s not going to take the entire year, but it’s something I’ve always wanted to do. I actually started working on it today…

The Challenge

Importing custom MIDI music into WCW/nWo Revenge for N64 proved difficult. Existing tools can export BINs to MIDI, but importing fails with “Unsupported ASMICSng” errors. A manual reverse engineering effort was undertaken to understand the format.

Discoveries

File Structure

Revenge uses a three-pointer-table system:

  • Table 1 (0x00-0x5F): 17 main track pointers
  • Table 2 (0x78-0xC7): 17 secondary layer pointers (dynamics/variations)
  • Table 3 (0xD8+): 3 sparse additional pointers

Track Format

Each track follows this structure:

[Optional delay for tracks 2+]
99 60 00 XX 95 ff        ← Wait XX ticks before starting

[Track header]
81 XX                     ← Instrument select (0-36)
90 YY                     ← Volume
87 ZZ                     ← Reverb
a2 ??                     ← Unknown (always present)

[Note data - varies by instrument type]
Simple (drums): [pitch] [velocity] [pitch] [velocity]...
Complex (melody): 1b [vel] [pitch] 60 00 [dur]
           or: e4 [pitch] bc [dur]

95 ff                     ← End marker

Key Insights

  1. Monophonic tracks: Each track plays one note at a time. Full orchestration requires layering 17 simultaneous tracks.
  2. Timing delays: Tracks start at different times using 99 60 00 XX 95 ff commands between sections.
  3. Loop structure: First section (intro) plays once, then loops from the first 95 ff marker.
  4. Multiple note formats: Different instruments use different encoding:
    • Simple percussion: Direct pitch/velocity bytes
    • Melodic: Complex multi-byte formats with duration
  5. Pointer table complexity: Table 2 pointers point to mid-track positions, creating synchronized layers and variations—not separate tracks.

Why Conversion Is Difficult

The import problem exists because:

  • The multi-table pointer web with cross-references is incredibly complex
  • Multiple note encoding formats require context-aware conversion
  • The layering system doesn’t map cleanly to standard MIDI
  • Loop points and synchronized entry points are format-specific

Current Status

Testing confirmed the format by creating a minimal working BIN stripped down to two segments (0x345 and 0x146). It successfully plays 17 notes across 6 instruments with proper looping.

Next step: Encoding a simple custom track (nWo theme guitar riff) from scratch to validate the format understanding.

Tools used: Sekaiju (MIDI editor), VPWStudio (ROM injection), hex editors, Python parsing scripts

Conclusion: Custom music import is possible but requires building a sophisticated converter that handles multi-track splitting, timing synchronization, and format-specific encoding. Not a simple MIDI→BIN conversion like some other AKI games.

Thirdly, I want visitors to know that I’m not active in any other AKI communities and I don’t hang out on the various Discords. Everything you see here is done independently, in my own space and at my own pace.

This is a hobby I genuinely enjoy, and I intend to keep it that way. I’m here to build, learn, and document the process. Anything that takes away from that enjoyment simply isn’t something I’m interested in engaging with.

Lastly, there is still a lot to do. Between coding, editing rosters, testing moves, and eventually importing music, there is no shortage of challenges, but that is exactly what makes this project rewarding. It will take patience, focus, and persistence, but I am ready for the hard work.