Why Can Wolverine Chain That Combo and Ryu Can't? It's 48 Bytes.

I have been taking Marvel vs. Capcom apart for about two years now. Character ports, a 999-hit counter, super cancels the arcade board never had. Every one of those started the same way: open the ROM, find the table, prove what it does.

Somewhere in the middle of that I realised I had been answering a question nobody asked me, while a question people ask constantly went unanswered. Not "can you add a character" — the question is "why does my character work like this?" Wolverine chains jab into short into strong into forward all the way up. Ryu cannot chain his jab into his short. Everyone who has played this game knows that. Nobody I have ever talked to could tell me why, and the answer you get in a Discord is always some version of "that's just how the game is."

It is not just how the game is. It is a 48-byte table, one per character, and the rule that reads it is four instructions long. This post is that table — and the training mode I built so you can watch it decide, live, for whoever you happen to be playing.

timeline
    2024-2025 : Character ports : find the table, prove it, move it
    Early 2026 : 999-hit counter : no ROM expansion, three hooks
    Mid 2026 : Super cancels : roster-wide, 21 identities
    Along the way : The chain rule : why Ryu cannot go jab into short
    August 2026 : The training mode : point all of it at the player

Street Fighter III Has Had a Real Training Mode for Years. This Game Has Had Nothing.

3rd Strike players have 3rd_training_lua — recorded dummy slots, hitboxes, frame advantage, parry drills — running as a Lua script on the same emulator Fightcade already uses. Marvel has had what the arcade board gave it in 1998, which is a versus screen and your own patience.

The obvious move is to port the 3rd Strike script. That is the wrong instinct, and it took me about an hour of reading to see why. Roughly half of that script is about mechanics Marvel does not have — parries, red parries, the stun gauge, Super Art selection, charge partitioning — and none of it knows about the mechanics Marvel does have: a three-level hyper meter, tag, Variable Counter, Duo Team Attack, special partners, advancing guard, ground recovery rolls, air combos.

What survives the port is the architecture. How you drive a pad one frame at a time. How you record input relative to which way you are facing, so a recording still works after a side switch. How you keep a menu on screen without desyncing anything. That part I kept nearly verbatim, because it is correct and it is proven, and I am not going to re-derive a solved problem to feel clever.

Everything above that line is new. And the reason it could be new is that after two years of pulling this ROM apart for other reasons, I already had the tables. The tool did not need a frame-data spreadsheet copied off a wiki. It could ask the game.

The Whole Magic Series Is One 48-Byte Table and One Strictly-Greater Comparison

Here is the mechanism. Every character has a 48-byte rank block, reached through a pointer table, laid out as eight rows of three strengths — one row per stance, split into punches and kicks:

row $00  stand punch       row $06  stand kick
row $0C  crouch punch      row $12  crouch kick
row $18  air punch         row $1E  air kick
row $24  super-jump punch  row $2A  super-jump kick

Press a button and the dispatcher computes rank = block[row + strength], where strength is the light/medium/heavy index at +$4D, and stores the result at +$B7. Then, when you try to chain, the check permits your next button only when all three of these hold at once:

+$64 & $E0 ≠ 0      you are still inside the current move
+$84       ≠ 0      the current move CONNECTED
rank(candidate) > +$B7

Strictly greater. That one word is the entire mystery.

The two blocks, side by side

This is the engineer-lane version of the same claim. Twelve bytes from each character — rows 0 and 1, stand punch and stand kick, which is where the entire story lives. Same offsets, same stride, two different fighters:

Diffing two blocks is the cheapest evidence I can offer that the field means what I say it means. If rank were something else — damage, startup, an animation index — those three bytes would not fall exactly where the two characters' chains diverge in play.

What that costs Ryu, counted

Six buttons give thirty ordered pairs. Run the strictly-greater rule over both blocks and count how many of those thirty the engine will actually allow:

Twelve against fifteen does not sound like much. The number that matters is what those transitions can be strung into, because the rule applies again at every step:

Ryu is not "worse at chains" because of some hidden property of his normals. He has three distinct ranks where Wolverine has six, and a chain is a strictly increasing walk through them. Three ranks, three steps. That is the ceiling, and it is arithmetic.

Here is the whole matrix for both, from-move down the left, to-move across the top. The upper-triangular shape falls out of the rule automatically — and the holes are where the character-specific quirks live:

The three bolded cells are the three bytes from the HexDiff. That is the whole difference between the two characters' ground games, written out.

So the Panel Does Not Ship a Chain Chart

The Move Lab reads the live block for whoever you are playing, reads your current rank at +$B7, checks the two gate bytes, and prints the buttons that are legal this frame. When you are not in a move it previews what would be legal if one connected.

Pick a character the tool has never seen — a hidden one, a variant, something from a modded build — and it still works, because the table is the character. There is no per-character data file in the package to go stale.

Eight Columns, Not Seven

The arcade board's hidden HIT TEST screen prints a per-move property row with Capcom's own column headers: Dmg Piy Sto Snd Slp Shc Grd Mut. Our earlier offline dump of those rows carried seven of the eight.

The one that got left behind is Mut — a big-endian word at +$1A. The consumer disassembly shows Mut & $3F seeding the post-hit invulnerability timer at +$106 and closing the vulnerability gate at +$83 for that many updates.

That is the rehit window: the reason a multi-hit move hits three times instead of thirty. It is now on screen next to damage, hit-stop, hitstun, guard stun, knockdown and dizzy accumulation, read from the row the move itself latched at +$80.

The move name I refuse to print

The ROM does contain a 320-entry pattern-name table, and it is extremely tempting — a panel that says "STAND SMALL PUNCH" instead of grp $10 reads better in every screenshot.

The join from a move id to a name index was tested and refuted during the earlier work. Two independent checks killed it: the damage profile of the supposed normals band does not match, and scanning every offset from −$20 to +$40 for a shift that separates the bands scores essentially zero for every character.

So the panel labels the animation group, using only the nine group ids that were hand-verified against live captures, and prints the raw hex for everything else. A tool whose entire pitch is "it reads the ROM instead of guessing" loses that pitch the first time it guesses.

The Frame Meter, and the One Number Nobody Ships

The rolling per-frame ribbon is the feature every modern fighting game now has and this one had to imitate. Both fighters, one square per frame, colours following the convention SF6 taught everyone to read: startup, active, recovery on the attacker; stun on the defender.

The part nobody ships is the derived question — is my blockstring actually tight? So the tool watches for the stretch where the defender is actionable between two hits of a string, and reports its width:

That feature also produced the most instructive bug in the whole project, which is two sections down.

What the Research Changed, Specifically

Before writing the dummy I had an agent sweep arXiv for anything from 2024 onward that bears on how a practice tool should behave. Four findings changed the design. I am naming which, because "we read some papers" is not a claim.

The dummy got a reaction delay, and the drill got an honest clock. A dummy that blocks on frame one is not a hard opponent, it is an impossible one, and it teaches expectations no human will meet — the fairness argument for injecting delay is made directly in arXiv:2312.16010. So the reaction drill times from the first frame the dummy's option is visually distinguishable, not from the frame the sequence was queued, and it will not credit a direction you were already holding. Hold down-back forever and the tool tells you that you never reacted, which is true.

Difficulty sliders got replaced by a band. The useful task is the one that is neither already solved nor still impossible — the Zone-of-Proximal-Development rule that ProCuRL (arXiv:2304.12877) derives rather than tunes, and that FightLadder (arXiv:2406.02081) implements by sampling opponents in proportion to 1 − P(win). The finding that settled the argument for me is arXiv:2512.17882: people left to choose their own difficulty systematically choose too easy, and perform just as well when a model pushes them harder, without extra frustration. So the adaptive dummy targets a 50–70% success band, moves exactly one knob per step so you can see what changed, and unwinds by restoring your settings rather than a default.

The tendency detector uses the features that were shown to work. arXiv:2408.06818 reports 82–87% next-action prediction from relative position plus current move alone — which is precisely what a RAM reader already has, and a useful reminder that you do not need a neural network to notice that someone always presses fierce at mid range. It buckets situation by distance, and ranks habits by what they cost rather than how often they happen. It only reports. Arming the dummy against your worst habit is a separate, explicit button, because a partner that punishes everything instantly becomes unusable (arXiv:2604.25796).

The overlays learned to get out of the way. Constant cueing induces overreliance and erodes retention — the explicit finding of arXiv:2603.06253 on dynamic versus static guidance, along with the asymmetric rule: fade out fast, fade back in slowly. So the assist overlays dim as your rolling success rises and return when you start dropping things.

One result is worth recording for what it says about the field rather than the tool. The esports scoping review at arXiv:2409.19180 finds no periodization framework, no exercise taxonomy and no defined training load in esports at all. And the sweep turned up zero 2024–2026 papers on optimal combo or punish search in fighting games. A punish finder that searches the legal cancel graph for maximum damage is apparently still an open problem — and now that the chain rule is machine-readable, it is a tractable one. That is the next thing I want to build.

Two Inversions That Reading the Code Would Never Have Found

I had an agent review this adversarially, twice — once after the first version and once after the research features. The first pass found 17 real defects. The second found 18 more. Two are worth writing down, because both read as perfectly sensible code and both were exactly backwards.

The adaptive ladder ran in reverse. The combo counter at +$120 belongs to the attacker. Crediting the dummy's combo as the player's success meant the tool made the dummy easier when you played well and harder when you were being comboed. A difficulty curve pointed precisely the wrong way, in eight lines that anyone would have signed off.

The gap detector measured the inverse of a gap. The first version counted frames while the defender was in blockstun — which is the definition of the string working. A perfectly tight blockstring reported a wide-open gap. A genuine 20-frame hole reported nothing at all. A gap is the stretch where the defender is actionable, so the state machine had to start counting when blockstun ends.

Both now have regression tests that assert the direction, not just the magnitude. A test that only checked "a gap was measured" passes happily on the broken version, which is the actual lesson.

The rest were more ordinary and no less real: a settings write that shelled out to mkdir on every menu keypress, which on Windows is a multi-second stall per button press; character-id flicker outside a match wiping recording slots and hammering the disk every frame; "infinite meter" writing 255 bars into a field that holds 0 to 3; and a reaction-delay bug where any non-zero value meant the dummy never blocked at all.

None of that is exotic. All of it was invisible until something ran the code and checked the number against what it should have been.

Status, Honestly

195 headless checks pass under both Lua 5.1 and LuaJIT, against a stubbed emulator API that models the RAM layout and the joypad contract. That catches logic, arithmetic, state machines and draw-call safety. It cannot catch a wrong address, and it cannot tell me the hitboxes land on the sprites. That is the next session, not this one.

The standing caveat for anything that writes to work RAM: this is a single-player tool. Running it during a netplay match will desync your opponent.

References

• 3rd_training_lua — the 3rd Strike training script whose architecture the input, recording and menu layers are built on.
• peon2/fbneo-training-mode — carries dammit's marvel-hitboxes.lua, the source of the mvsc camera transform and box profile.
• arXiv:2312.16010 — delay mechanisms and fair evaluation against fighting-game agents.
• arXiv:2304.12877 and arXiv:2406.02081 — curriculum by proximal difficulty, and opponent sampling by inverse win rate.
• arXiv:2512.17882 — people choose too-easy difficulty for themselves.
• arXiv:2408.06818 — next-action prediction from position and current move.
• arXiv:2603.06253 — dynamic versus static guidance, and why constant cueing erodes retention.
• arXiv:2409.19180 — the esports training-science scoping review, and the gap it documents.