CHRONO CROSS ROOM SCRIPT INVESTIGATION THREAD (formerly event script thread)

[FaustWolf]

Holy COW, I didn't know you guys made all this awesome progress while I was gone. I honestly need to brush up on everything opcode related, but looks like all the game data is being cracked bit by bit (byte by byte, I should say).

Not sure if anyone's had a chance to investigate this yet, but any ideas on how we would go about finding pointers to model textures and 3D model data? I assume the fieldscript would contain pointers to overworld character models, whereas some kind of battle script would contain pointers specifying where player character battle models are. I've found where the pointers to NPC models are (these are oddly enough left out by Yazoo's dumper; see here), it's just the player character models that have escaped me.

Also, reflecting on our problem with using anything larger than Size 0 sprites for player characters in Chrono Trigger, I'm worried that Chrono Cross memory management may be set up to work with *only* textures of 128x128 pixel size for the overworld character models. NPCs and enemies can have 128x256 pixel textures or even two 128x256 pixel textures, but there isn't a single player character who uses anything larger than a 128x128 pixel texture on the overworld.

[Vehek]

I haven't completely deciphered fieldscript or battlescript yet, but I don't think they have pointers to things outside themselves.
I've tried messing with that file pointer table you found and it's worked for me.

[Vehek]

A3 aa bb* cc dd* ee ff*
Similar to opcode C9, but probably for more normal battles where the enemies involved vary.

For ffee on both C9 and A3:

• Bit 0x01: Keeps field music into battle
• Bit 0x02: Battle is losable.
• Bit 0x04: Caused party to have Dragoon disguise after battle
• Bit 0x10: No victory music
• Bit 0x20: Music in battle stays after battle
• Bit 0x40: Brink of Death music plays

AC xx yy zz*
Seems to be transparency related. When xx was FB, it affected the entity executing the command. FD, FE, and FF affected PC3, PC2, and PC1 respectively.




10 aa bb cc dd ee
Not sure. 10 vv uu xx yy 40 caused #yyxx to be stored to variable uuvv.

[FaustWolf]

Oh man, excellent work Vehek! This is really exciting.

[yaz0r]

Okay, I've been poking around the CC binary a bit and are the results.

Whatever the 0003 file of each room is, it interpreted by the 0002.out overlay, aka the field engine. This overlay is loaded at 0x800A3308 in memory. The code interpreting the script is the function at 0x800CECE4 and the opcode table is located at 0x800E16B8. I still have some doubts this is where most of the script interpretation is done because of a few details that don't match yet.

The 0003 file is composed of 0x80 bytes of header, a number of entry, followed by entries of size 0x40 times the number of entries. The script bloc starts just after that.

It can be argued that those entries are the script entities, and that the first UInt16 of each entry is the offset in the script bloc where the script for that particular entity begins.

[FaustWolf]

Thanks yaz0r! I don't know enough to comment on that at all, but do you agree that the 3.OUT could be the walkmesh, as I think has been proposed elsewhere?

[Vehek]

I don't know much about the code works, but I think the opcode table at 0x800E16B8 is the table for the FE subopcodes.
Regular field opcodes are at 0x800E18D0.

[yaz0r]

That would make more sense and clear up my doubts about if the opcode table I was seeing was for sub opcode or not. Seems that ran out of opcode while writing CC and added 134 extra opcodes.

@FaustWolf:
You're talking about 0004.out right ?

[yaz0r]

After a little more digging, it seems the 0003.out header is an array used to access the global variables form the local room.
Parameters of opcodes can be either variable or immediate value if the bit 0x8000 is set (the actual value is of course masked with 0x7FFF).
If it's a variable, the game compute the variable index like this:

int idx = (value & 0x7FFF) >> 6;
int localVariable = roomLocalTable[idx];
int globalVariableIdx = ((value & 0x7FFF) >> 1) & 0x1F

if(localVariable & (1 << globalVariableIdx)) // signed or not ?
{
    return (UInt16)variableTables[globalVariableIdx];
}
else
{
    return (Int16)variableTables[globalVariableIdx];
}

[FaustWolf]

Oh, .OUT 4 it is then. My bad. I'll label that appropriately in our wiki.

[yaz0r]

Those are just convensions
It could be the walk mesh. As anyone ever tried to display what the data would look like in 3d ?

[yaz0r]

I've started writting a little script decompiler. I have implemented a few opcodes so far and some part of the script are starting to make sense. Here is how the game randomize the title screen sequence:

0x015C: var[0x040E] = rand()
0x015F: var[0x040E] &= 3
0x0165: IF_JUMP(var[0x040E] == 0x0000, 0x0175)
0x016D: opD3("tit0")
0x0172: JUMP(0x01A5)
0x0175: IF_JUMP(var[0x040E] == 0x0001, 0x0185)
0x017D: opD3("tit1")
0x0182: JUMP(0x01A5)
0x0185: IF_JUMP(var[0x040E] == 0x0002, 0x0195)
0x018D: opD3("tit2")
0x0192: JUMP(0x01A5)
0x0195: IF_JUMP(var[0x040E] == 0x0003, 0x01A5)
0x019D: opD3("tit3")
0x01A2: JUMP(0x01A5)
0x01A5: op59()

[FaustWolf]

Wow, awesome! Thanks so much for your work yaz0r!

[yaz0r]

7F - Play movie

From the game assembly, 7F is just stalling the script until a variable is set. Probably waiting for the movie to end.

[Vehek]

I was probably just guessing and didn't test 7E by itself. I think all of my research is based off on context or observation of the in-game effects.

Are there any differences between opcode02 and the "Conditional Jump" Akari described?