Crusader_Decomp/docs/jp-remorse-cheats-and-launch-params.md

Japanese No Remorse Cheats And Launch Parameters

Scope

This note records the current live-Ghidra read of /ja/CRUSADER.EXE for two questions:

1. did the hidden cheat/debug features survive in the Japanese Windows build?
2. which launch parameters still survive in executable code?

Active Ghidra target for this note: /ja/CRUSADER.EXE.

Short Answer

Yes, important cheat/debug features clearly survived in the JP Win32 build.

Current strongest proof:

• -laurie is still parsed explicitly and still enables the broader cheat/debug gates
• the hidden JASSICA16 sequence matcher still exists as live code
• the JP option-key cheat handler still contains the immortality on/off path with live UI messages
• the JP parser still recognizes a broad launch-option table including -debug, -u, -setver, -vesatest, -asylum, -warp, -skill, -mapoff, -egg, and -demo

The main caution from this pass is that the JP Win32 parser is not yet proven to support every old DOS-side syntax exactly as previously documented. In particular, this pass did not recover a JP parser branch that consumes positional X/Y/Z arguments after -warp; the live JP parser block currently closes only the -warp <mission> form.

Main Findings

1. -laurie definitely survived

00466774, now named handle_commandline_args_jp, still special-cases -laurie outside the normal option table.

Recovered behavior:

• exact literal compare against -laurie
• sets the two broad cheat/debug gate bytes at 0x4957d8 and 0x495830
• prints the message at 0046ea5a: FART ...TRY... -laurie (Have fun, Jely)

This is strong evidence that the JP Windows build still preserves the Laurie/debug enable lane rather than removing it.

2. The JASSICA16 hidden-sequence lane definitely survived

00418454, now named key_check_jassica16_toggle_jp, is a live hidden-sequence matcher.

Recovered behavior:

• consumes incoming key bytes
• compares them against a byte sequence table starting at 0x47b1c9
• on full match, toggles the global cheat-active state
• emits the live messages:
  • Cheats are now active.
  • Cheats are now inactive.

Adjacent JP data still contains the literal string JASSICA16 at 0047b1cc.

The safest current read is:

• the hidden JASSICA16 cheat-enable concept survived
• the JP executable still has executable code that toggles cheat state from a secret key sequence

3. The option-key cheat handler still contains immortality

00415eec, now named key_handle_option_cheats_jp, still contains the immortality toggle path.

Recovered behavior inside that function:

• checks cheat/debug gating before entering the relevant branch
• still reaches both live strings:
  • Immortality enabled.
  • Immortality disabled.
• still pushes those strings into the normal in-game message path

This is direct proof that at least one high-value keyboard cheat survived beyond the sequence matcher itself.

The same function is larger than just the immortality branch and still appears to host a broader cheat/debug action menu. This pass did not fully close every other branch in that handler.

4. -u survived, and the JP build gives it a clearer meaning than the older notes

The JP parser block at 0046688f consumes the next argv token and copies it into the fixed buffer at 0x47be40.

That buffer is later consumed by 00466ebc, now named startup_apply_u_override_if_present.

Recovered behavior in startup_apply_u_override_if_present:

• checks whether s_usecode_0047be40 is non-empty
• if so, routes startup into a replacement usecode/EUSECODE load path instead of the default one

This is the strongest current JP-side closure for -u:

-u <path-or-name> is a live startup override for the usecode/EUSECODE load source.

That is materially better than the older unresolved -u note.

Launch Parameter Table

Definitely recovered as live JP parser behavior

Argument	Current best JP syntax	Confidence	JP evidence
-laurie	-laurie	High	Explicit special-case in handle_commandline_args_jp; sets cheat/debug gates and prints the Laurie joke string.
-debug	-debug	High	Dedicated parser block sets debug state, writes 0x0a to the debug level word at 0x482620, and prints Debugging mode ON..
-u	-u <arg>	High	Parser consumes the next token into 0x47be40; later startup code uses that as a live usecode override path.
-warp	-warp <mission>	High	JP parser consumes one following numeric token, stores it, and prints Warping to mission %d..
-skill	-skill <n>	High	JP parser consumes one following numeric token and prints Defaulting to skill level %d.
-mapoff	-mapoff <delta>	High	JP parser consumes one following numeric token and prints Map offset = %d.
-egg	-egg <id>	High	JP parser consumes one following numeric token and prints Destination Egg = %d.
-demo	-demo	High	JP parser sets the demo flag and prints Demo mode..

Present in the JP parser table, but not fully re-closed in this pass

Argument	Current best JP syntax	Confidence	Current best JP read
-?	-?	Medium	Still present in the JP option table. Likely some help/usage-style path, but the exact handler was not isolated in this pass.
-setver	-setver <text>	Medium	Still present in the JP option table. Existing non-JP notes still make displayed version/build string override the best read, but this exact JP handler was not re-closed here.
-vesatest	-vesatest	Low	Still present in the JP option table. The exact JP-side effect remains unresolved.
-asylum	-asylum	Low	Still present in the JP option table. The exact JP-side effect remains unresolved in this pass.

Important JP-Specific Caution About -warp

The older DOS-side command-line note documents a positional coordinate form:

• -warp <mission> <x> <y> <z>

This pass did not re-close that form in the JP Win32 parser.

What the live JP parser block at 004668e2 actually does:

• call the tokenizer once more
• parse a single numeric token
• store that value as the mission id
• print Warping to mission %d.
• return to normal token scanning

What this pass did not recover:

• a branch that consumes three extra positional numeric tokens after -warp
• a JP-side format string of the older Warping to mission %d @ x:%d y:%d z:%d. style

So the safest current JP statement is:

-warp <mission> is directly proven. The positional JP Win32 coordinate form is not yet proven by this pass and should not be assumed from the older DOS-side note.

Cheat-State Model After This Pass

The current strongest JP cheat/debug model is:

1. -laurie still raises the broad cheat/debug enable gates.
2. The hidden JASSICA16 matcher still exists and can toggle cheat-active state independently.
3. The option-key handler still contains at least the immortality toggle and a wider cheat/debug action family.

That means the Japanese Windows build did not merely keep some orphaned strings. It still preserves executable cheat/debug machinery.

Ghidra Changes Made During This Pass

Renamed and commented in the active /ja/CRUSADER.EXE database:

• 00466774 -> handle_commandline_args_jp
• 00415eec -> key_handle_option_cheats_jp
• 00418454 -> key_check_jassica16_toggle_jp
• 00466ebc -> startup_apply_u_override_if_present

Decompiler comments were added to each of those entry points to preserve the evidence in the live database.

Open Follow-Up

1. Recover the remaining JP option-table handlers for -?, -setver, -vesatest, and -asylum explicitly rather than by table presence only.
2. Re-open the JP -warp lane and prove whether any positional coordinate form still exists in some later startup consumer.
3. Identify the exact key bytes in the JP 0x47b1c9 matcher table and compare them byte-for-byte against the ASCII-adjacent JASSICA16 data.
4. Walk the rest of key_handle_option_cheats_jp so the non-immortality branches are named and classified.
5. Compare the JP cheat/debug global addresses directly against the English DOS build to see which lanes were ported verbatim versus re-laid for Win32.
6. Runtime-test the JP build with -laurie, -debug, -demo, -warp, and -u to confirm the static conclusions from the Windows binary.