-
Notifications
You must be signed in to change notification settings - Fork 9
Format: CsMO Scene
CsMO is the predecessor of the newer CST Scene script format. Both formats use the .cst
extension.
CsMO was present in the earlier half of CatSystem 1's life. Primarily found in CsPack1 Archives over the newer CsPack2 version, which hold CST Scene scripts instead.
Data Type | Value | Description |
---|---|---|
char[4] |
"CsMO" | File Signature |
uint32 |
" " | Unknown, possibly part of file signature, always 3 spaces |
uint32 |
CompressedInputsLength | Compressed length of InputOffsets table |
uint32 |
DecompressedInputsLength | Decompressed length of InputOffsets table |
bytes[CompressedInputsLength] | InputOffsets | Array of uint32 that point to the offsets I'd message inputs in LinesData |
uint32 |
CompressedLinesLength | Compressed length of LinesData region |
uint32 |
DecompressedLinesLength | Decompressed length of LinesData region |
bytes[CompressedLinesLength] | LinesData | Sequential script lines (messages, commands, etc.) |
These values are not necessary to read when parsing the file. They possibly mark the offsets of the script line after every Input line and most likely aid the game engine in skipping and loading game saves.
N = DecompressedInputsLength / 4
Data Type | Value | Description |
---|---|---|
uint32[N] | Offsets | Offset to start of each 'input' line in LinesData |
Note: The first (and second?) offset in InputOffsets points to byte offset 0, and byte offset 1 respectively in the Lines Table data. These first two bytes are not fully understood, as described in the following section.
The string data table for script lines. Each line has a type that determines what it does, and content that is either used to parse a command or display a message or name.
Script lines must be read sequentially, or from a known offset supplied by InputOffsets.
Data Type | Value | Description |
---|---|---|
Line[>] | Lines | Script lines in a scene, which can be commands, names, etc |
Note: The first two bytes of the Script Data are 0x00 0x01
, their usage is unclear, but skipping forward 2 bytes to start reading the script seems to work.
- Byte
0x00
May be a LineType denoting an Input (waiting for the user to press a button to continue). This would coincide with the inconsistent appearance of null terminators after Scene Line content, based on the Line Type. - Byte
0x00
is simply padding to align to a byte boundary. - Byte
0x00
is just a special handler case. The null terminators at the end of Monologue and Dialogue Line Types may be a runtime optimization.
An individual script line.
Important: When Type is 0x00
or 0x01
, the remaining structure is skipped (does not exist). These Type codes may serve a different purpose, but this method works well enough for reading scene lines.
Note: The Monologue and Dialogue line types always have zero byte (null terminator?) after the string content. This byte is not included in the Length field.
Data Type | Value | Description |
---|---|---|
uint8 |
Type | Action performed by the line (see Line Types) |
uint16 | Length | Length of content string |
char[Length] | Content | Content string of the line |
char | '\0' | Appears only at end of Monologue / Dialogue line types (?) |
(There may be more unknown values that are not listed here)
Name | Value | Description |
---|---|---|
None | 0x00 |
Seen at end and beginning of script, possibly Input: Wait for input after message |
Unknown | 0x01 |
Seen once as second byte in script, possibly Page: Novel page break and wait for input after message |
Monologue | 0x02 |
Display a message as internal monologue |
Name | 0x03 |
Change speaker of the message |
Dialogue | 0x04 |
Display a message with a speaker |
Command | 0x08 |
Perform any other command |
Note: Unlike in CST Scene scripts, the Name line type only changes the stored speaker name. It does not need to be redeclared after every message, and... due to the Monologue line type, does not need to be unset for monologue.