So much data... Nice! <3 I need to update database and wiki with this. JWP, do you have wiki account?
@topic:
I investigated the harata.cnf file. I came up with another theory.
Battle module has rich debug data code written, but it's destroyed/unusableFrom the beginning: I traced all the way harata.cnf is loaded (the myserious file that looks like debug loader for battle programmer). Keep note battle is one module that has no DebugOutput strings. I didn't really find anything, it's loaded and that's kinda all. It's loaded by SmPcRead function before main menu shows along with font and namedic.bin and two hardcoded paths to Y:/work/battle/batwave.dat (Programmer loaded file independently to jumpover archive process). I tried to find the file in memory and see if there are any refferences, however I found the words that were made to recognize harata.cnf file like: 'start' 'manual' 'bdprint' 'pinch' and extreme amount of others that even harata.cnf consist. They ARE used, bad thing is their code is never used (I mean no function calls it- only jump, but it's impossible case due to battle state system overwriting update function for checking states).
Example for displaying/outputing/writing to log file (most probably) for showing current EncounterID from Scene.out:
47FCEE pushes this mysterious "SCENE " (Many of them further have the %s when pushing)
47FCF8 This is missing from final game. Did the programmer delete the "StreamToLogFile" like function? This looks like the programmer commented out the function before final release
47FD11 Puts EncounterID (01CFF8B8 ; unsigned __int16 EncounterID if you want
)
I don't understand this though:
push 1F800000h (and I think we all won't understand, since the function is null now.... )
The scheme for above example is like this:
mov edx, dword ptr EncounterID -Get Encounter ID to edx (Encounter ID is uint16 !!! )
and edx, 0FFFFh - Force EDX to be 16 bit by doing the bitwise operation
push edx - Push EncounterID
push 1F800000h - Push mysterious something??
call nullsub_7 - deleted output function
It's complete mess.
Any other data (that is used for writing log file) is obtained from dword_1CFFA28, the only instruction that writes it is 0047F0F9.
There's whole function for this. The function that consists jump to this unused section is: 0047EEF0
Well... the problem is it's fired, when battle state is == 4 (the only case when it's equal to 4 is BattleResultScreen). Simple? Nope. When the game goes into BattleState==4 it's automatically stopped, and the parent function reroutes the state to BattleResult screen, therefore the code for state 4 is never fired (it's no more called by update function). That way the code remain 'unused'. There's a way to force battleState = 4 by memory hacking, but the game crashes (After unlocking user from endless loop at 0047EF09) (the script also loads btitle.ovl file [this file doesn't exist])
Getting out of the loop and stepping over (to avoid instant crash, but to see all the logic) we find those variables are beign written for the first time (It's unknown size byte array):
unk_1CFFB98; unk_1D13C10; unk_1CFFBF4; unk_1D13C6C
We again get into endless loop at 0047F073 (the conditional jump to beginning of function without again testing variables makes it impossible case, till something bad happens). Let's break out of it. Finally we get into core unused sub-routine that directly manages the unused battle debug data.
The software crashes at 'mov ds:1F800000h, edx' because 1F800000h is unallocated.
Sad...
I found this function in FFVIII Demo version. It's decompilable there. There's pseudocode fragment:
v1F800000 = dword_CD2868 + 16496;
v1F800004 = 17;
v1F800006 = EncounterID;
v1F800008 = 1;
v1F80000C = &off_5FD158;
nullsub_7(528482304, (unsigned __int16)EncounterID_0, 0, 0);
v1F800000 = dword_CD2868 + 16496;
v1F800004 = 3;
v1F800006 = 00CFAACA + 1;
v1F800008 = v45;
v1F80000C = aTime;
nullsub_7(528482304, 0, 0, 0);
v1F800000 = dword_CD2868 + 16496;
v1F800004 = 17;
v1F800006 = 00CFAACA + 1;
v1F800008 = 1;
v1F80000C = &off_5FD164;
nullsub_7(528482304, dword_CD1944, 0, 0);
v1F800000 = dword_CD2868 + 16496;
v1F800004 = 3;
v1F800006 = 00CFAACA + 2;
v1F800008 = v46;
v1F80000C = aRate100;
nullsub_7(528482304, 0, 0, 0);
Looks now like it outputs Encounter data (only for this fragment)
Does anyone understand the 1F800000 phenomenon?
