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

[MDenham]

I'm using pSX.

How can I figure out where the scripts begin? I think I have the pointers, but I don't know where they're going.

edit:
I think I have the pointers for the opcodes. They're at E18D0 in my memory dumps.

Can you track down when they get loaded?  Based on a disassembly (and guessing where things are loaded - 0000.out @(80)010000 [definitely - according to PS2DIS, at least], 0002.out @0A1200, 0003.out @0E0100, 0004.out @0E0A00) I'm not finding anything resembling pointers at that spot.

Alternatively, can you give what the first couple of pointers are?  I can track down which file they're in from that and that'd help me determine what's being loaded where (stupid "let's break the engine into four or more parts"...).

[Vehek]

I'm working with files made from RoomDecompress. That's the "OUT 3" I was referring to.
The pointers are in the same file as the fieldscript, but I can't figure out exactly where in the file they point to.

Edit:
I think the pointer to the decompressed fieldscript gets stored to (80)0E3A48 in memory.

[MDenham]

I'm working with files made from RoomDecompress. That's the "OUT 3" I was referring to.
The pointers are in the same file as the fieldscript, but I can't figure out exactly where in the file they point to.

They wouldn't be pointing to somewhere in the file; they'd be pointing to somewhere in memory in general (namely, the routines on a per-opcode basis).

...Though am I interpreting what you're saying correctly as that there's a separate table of opcodes->pointers for each room?  If so, that's one hell of a mess.  Fieldscript should use a single table of opcodes, and that table would be somewhere in the engine (which is 0000/0002/0003/0004.out from a "normal" dump of a full disc).

Tables that fit this pattern:
0000.out, 0x91700 - 176 pointers
0002.out, 0x00140 - 333 pointers
0002.out, 0x3E3B0 - 390 pointers
0004.out, 0x00834 - 192 pointers
0004.out, 0x36184 - 52 pointers
0004.out, 0x36404 - 229 pointers

Of those, at least one is Element-related (probably one of the two long ones in 0002.out), and I believe the 52-pointer table is related to character attacks.  The fieldscript opcode routine pointers...  well, I'm leaning towards that being the table in 0000.out, but I'm not sure.

[Vehek]

Sorry for being unclear. Each room is going to have pointers to the scripts for the entities in the room. Those were the pointers I was talking about in my previous post.

Edit-OK, looks like the script pointers go to: Script pointer + location after pointers.

[Vehek]

Further studies:
00 - Return
01 XX YY - Go to YYXX
0F XX 80 - Load NPC model XX
9E XX 80 - Set dialog portrait to XX.

Should I try to put what I've found so far in the encyclopedia?

[Akari]

Hmm looks a lot like opcodes in Xenogears. If so - 0x8000 bit means that this is immediate value. If this bit is not set that value will be taken from memory.

[MDenham]

Hmm looks a lot like opcodes in Xenogears. If so - 0x8000 bit means that this is immediate value. If this bit is not set that value will be taken from memory.

Not too surprising that the fieldscript engines are similar (if not identical)...

[Vehek]

I realized while looking at some fieldscript that opcode BB is more than Give Element.
ZZ controls what it does. So far, I have 82 for Element and 84 for Key Item.

Edit-01 in XX (of the BB opcode) takes away an Element or Key Item.

Edit 2- More on opcode BB, parameter ZZ:
I think 80 is for the rest of the items (materials, weapons, accessories, etc.)

[halkun]

The FF7 opcode list can be found here

I have a hard time believing they would recode the whole thing when there was a perfectly good parser to start with.

[MDenham]

The FF7 opcode list can be found here

I have a hard time believing they would recode the whole thing when there was a perfectly good parser to start with.

Recode, probably not.  Dummy out or repurpose opcodes that would have no relevance to the new game, though?  Fairly likely, especially if they ran out of opcodes that weren't used in FF7.

It's also entirely possible that they just wrote up a new table of opcodes - the parser doesn't really care what the opcodes in general do, it just converts them to function pointers (at least, that's how I'd write it - maximum code reusability, minimal hassle) - in which case the only way to tell which opcode does what is by checking against the possible options that are known from, say, FF7 (or blindly testing everything).

[Akari]

2halkun: Opcodes in FFVII (and ffvii itself) was written pretty badly and not optimized at all. In later games they rewrite opcodes and all system of working with savemap as well as all bool value was packed as bit flags. Its much closer to Xenogears than to FFVII. I believe FFVIII will be direct reference, but very little known about it.

Example:
In ffvii there was a lot of conditional jumps, better known as "if" opcode.
In xenogears there is only one such opcode: 0x02  or "ConditionalJump" description is

0x02 ConditionalJumpTo(u16 value1, u16 value2, u8 flag, u16 address);
    flag & 0xF0 - how read values.
        0x00 - v value1, v value2, sign from first value is used for both.
        0x40 - v value1, s16 value2, sign from first value is used for both.
        0x80 - s16 value1, v value2, sign from second value is used for both.
        0xC0 - s16 value1, s16 value2.
    flag & 0x0F - condition.
        0x00 - value1 == value2
        0x01 - value1 != value2
        0x02 - value1 >  value2
        0x03 - value1 <  value2
        0x04 - value1 >= value2
        0x05 - value1 <= value2
        0x06 - value1 &  value2
        0x07 - value1 != value2
        0x08 - value1 |  value2
        0x09 - value1 &  value2
        0x0A - (0 NOR value1) &  value2
    do condition with two values.
    if true continue with next opcode, jump otherwise.

As you can see it covers immediate values as well as variables read from memory, it covers signed values as well as unsigned.

General idea though stays the same.

[Vehek]

Some of the opcodes I have:
Arguments marked with '*' had bit 0x80 set in examples I saw.

5A aa bb* cc dd* - Jumpmap to map bbaa with parameter cc

96 xx yy* - Add character xx to roster?

25 aa bb cc dd ee ff gg - Set object coordinates. Ex. 25 DB 00 BA 06 C0 00 80 82.

42 00 aa bb cc dd ee ff? gg*? - Move object to coordinates?
42 01 - Needed right after for 42 00 to work?

41 xx yy* - Set movement speed

94 aa bb* cc dd - Conditional jump, checks if character aa is in party.

7E aa 80* - Set movie to be played

7F - Play movie

80 xx yy* - Involved with room graphics. Observed in unused orphanage demo scene to display drawings and reveal door.

02 seems to be a conditional jump command in Chrono Cross too.

[Akari]

42 00 aa bb cc dd ee ff? gg*? - Move object to coordinates?
42 01 - Needed right after for 42 00 to work?

This things can be meet in xenogears as well. I meet it twice and both times it repeat previous action with some other entity/parameters/window.

[Vehek]

Some other opcodes. Some of these are old ones I didn't post before.

88 xx yy* - Play song xx. I've also seen this used in the startup scripts in some of the fieldscripts I've looked at.

E3 aa* bb cc dd - Make character aa say dialog (cc?)bb if in party.

7B xx yy* - Add character xx to active party (if space available)

7C xx yy zz - Not sure, may be required to update after a 7B command. Ex. 7C 2D 02 80; 7C 35 01 0A

7D xx - Remove character xx from active party.

Opcode FE Additional Opcodes:
4A xx yy* - Rename character xx.

5E xx yy* - Element Shop xx.

68 xx yy* - Blacksmith xx

5B - Character Exchange

Edit-I've done some experiments recently, and concluded that 7C may actually have no parameters.

[Vehek]

C9 aa bb* cc dd* ee ff* - Battle related. bbaa is the battlescript used. (dd)cc is the battle field.
FE 10 - Initiates a battle
(For an example, go to 0x103464 in memory while at the Chief's Meadow in Home world.)

15 aa bb cc dd ee - Not completely sure yet. 15 80 00 05 00 40 set the fifth (when counting the lowest bit as #0) bit (0x20) of variable 0x80. Effects of other settings of ee not yet tested.