Debug and test switches

Source

docs/executable/debug-switches.md

SHA-256

29a668b4…3562ce68

What is left in the executable of the developers' debug and test switches, and whether any of it can be reached in the shipped game: the auto_test switch, the shop's debug sequence, the @debug font and the debug memory heaps. Also the settings file config.ini, the one outside file the game reads switches from. None of it gives a debug menu: each piece is either compiled out, never offered, or ordinary code with a debug name. The work it serves is R14, testing edits in the game.

Summary

config.ini

The game keeps its display settings in config.ini, a text file of Key=Value lines in the user's save folder. It isn't a game data file and isn't in Data/; the game writes it, so a mod never ships one.

• likely: it's in the save folder: <Documents>\My Games\Tactics Ogre Reborn\Steam\<SteamID64>\ when Steam is running, else SaveData\ beside the executable. The platform setup (0x140180c80) builds the Steam path from FOLDERID_Documents (the GUID at 0x1406AEF60); the framework setup (0x14015d120) falls back to SaveData\ and stores the folder in the file manager at +0x48 (0x14015bf60); 0x14032d3c0 appends config.ini to it.
• likely: the game reads it at startup: the SystemInitData object is made with defaults (0x14032ce60), then the file is loaded (0x14032d070), both from 0x1402c2110. App init (0x140034d30) reads it once before that, with fopen, only to find the GraphicDeviceId= line and pick the graphics adapter before the renderer starts.
• likely: the game writes it (0x14032d2f0) at shutdown (0x1402c3470) and when the player quits from the menu (0x140314600), from the display in use, once per run unless forced, and never when auto_test is set.

Keys

Eleven keys, in this order, which is also the order the game writes them. Their names and types are a table of 0x24-byte records at 0x140687050 (a 32-byte name, then a type: 0 text, 1 integer, 2 decimal); the values live from 0x140F22490, 0x88 bytes each (127 characters of text, then an s32 and an f32). Source: xxd of both; the struct the loader fills (0x14032d070) and the code that applies it (0x14032c610).

How the game reads it

• likely: each line is Key=Value. The key ends at a space or = and is matched ignoring case against the key table, by the length of the key in the file, so a shortened key matches the first key it begins (Screen is ScreenMode). A line with an unknown key, or one starting //, is skipped. The value runs from after the = to a tab, carriage return or line feed, at most 127 characters, and is kept as text; it's also read as a number, a decimal (atof) if it has a ., else an integer (atoi). Source: 0x1404458f0.
• likely: the game writes every key as Key=Value and a line feed, text as is and integers in decimal (0x1404460b0), so the file always has all eleven keys.

For in-game tests, ScreenMode=Window with ScreenWidth and ScreenHeight runs the game in a window.

auto_test

likely: the switch only stops the game writing config.ini, and it can't be turned on. The save (0x14032d2f0) first asks the framework (the object at 0x140F6C778) whether an option named auto_test is set, by a direct call to 0x1400349d0, and writes the file only when it isn't. 0x1400349d0 is three bytes, xor al, al; ret: it always answers false. Source: objdump -d of both.

• likely: 0x1400349d0 is a shared stub for every function that only returns false, folded together by the linker: script natives 272 and 273 call it too (What the natives do), as does game setup (0x1402c1970) twice, with no arguments. Ghidra names it SQEX::CDev::Engine::Sd::Driver::IStreamReader::vfunction3 from one of the classes that share it.
• likely: auto_test is the only option name the code asks the framework about, from exe.strings and the stub's callers in exe.calls.

The shop's debug sequence

likely: the shop has a ninth mode, Taco::Application::DebugSequence, that no shop offers. Every shop builds all nine of its mode objects (0x14030d0c0, ShopMenu::vfunction4), and the top menu (0x14040e430, TopMenuSequence::vfunction6) maps the chosen command to a mode:

• likely: the debug mode opens the hero's name entry (MenuNameInput) for command 8 (0x1402fdf20) or the title screen's birthday entry, Title::BirthDayInputMenu, for command 9 (0x1404a1040), waits for it to close, then returns to the top menu. Source: DebugSequence::vfunction2 (0x140408d40) and vfunction6 (0x14040b290).
• likely: commands 8 and 9 are never in the menu. The top menu's list is built by 0x140409850, which adds commands 0 to 7 (4 and 5 only when a game-state check allows them, 0x1402cdd10 and 0x1402cdd30), through 0x14030c1e0; those are its only 8 calls (exe.calls). Reaching the debug mode would take a patch to the executable that adds a command, which the project doesn't do (rule 5).

The @debug font

likely: not a debug feature. While the language's font package is read (0x1402ac010), every face of every outline font gets a slot and is registered under its family name; the first face of the first font whose debug_font field is set is also registered, in slot 0, as @debug font, with the value 52 (0x34) set on that text font (font.md). Nothing else refers to the name.

The debug heaps

likely: the memory system (0x140036e10) registers 28 named heaps, among them DEBUG (ID 0x14), DEBUG_MENU (0x15) and debug (0x1C), but no allocation in the code names any of the three: the allocator 0x140198c90 is called only with other heap IDs (MENU, 8, for the shop windows; SAVELOAD, 0x12, for the system settings), or with a heap chosen at run time. Source: the heap table in 0x140036e10 and its name strings at 0x1406AF5A8; every constant heap ID passed to 0x140198c90 in the decompiled code.

Leads

• Whether an in-game test confirms config.ini's location and keys: running the game once and reading the file it writes would raise every fact in config.ini to confirmed.
• What the framework setup does with the command line WinMain passes it (0x1400362c0, then 0x14015d120): no code was seen looking for an option in it, but it wasn't followed to the end.
• 0x140314600: the names list calls it QuitGame_Update (guess) and this doc reads it as quitting from the menu, while overview calls the same code "a system error or quit prompt". It shows message DAT_140ece60c (0x815 or 0x81c, set by 0x1403145c0 from four callers) with rows 6001/6002, then on yes fades, saves config.ini and calls a framework method; decoding menu_data #2 and #6 would give the texts. If it is the exit prompt, the game's word is "Exit" (COMMAND_LC_COMMAND_NAME_EXIT_TEXT).
• Shop command 7 is called "exit" by the shop's COMMAND_LC_COMMAND_NAME_SHOP11_NAME "Exit"; the mapping from command numbers to menu_data #20 rows wasn't checked.
• Command 8: mode 0 of 0x1402fdf20 takes its name from 0x14031de20 on the party object, unread, so that it edits the hero's name is likely, not confirmed.
• The heap IDs passed at run time (the 0xFFFFFFFF and 0xFFFFFFFE calls to 0x140198c90, and the other allocator 0x140037650) weren't followed, so a debug heap could still be picked by one of them.