A look inside The Link @ wiki - User contributions [en]

Myst scripts

2008-09-22T23:07:34Z

Di gama: More coming (the 3xx are incorrect)

{{Myst}}
This page contains, or will contain, a list of all known commands in Myst, as used in record types 5, 6, 7, 8, 10, 11, and 12. The script format always starts with an unsigned short representing the command count, and then per command has this structure:

{| class="structure"
|unsigned short||opcode
|-
|unsigned short||var
|-
|unsigned short||num_values
|-
|unsigned short||values[num_values]
|}

The way scripts are stored, they each contain a command number, a variable number, and any number of arguments. When a variable number is not given, a "0" is used. So when the key below says that the variable is "optional", that means that it has been found both with and without a variable being passed in. In some cases, the syntax of the arguments depends on whether a variable was passed in. In this case, the variable/arguments header is repeated for each form of the command.

==Commands 0-99==
These are suspected to be general-purpose commands.
===Command 0===
*'''Variable:''' Optional
*'''Arguments:''' None
Seems to toggle a variable between 0 and 1. For example, see the marker switches on MYST island.

===Command 1===
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

Could mean "set variable to ''u0''". ''u0'' takes on any number between 0 and 7 (maybe a bit field?)

===Command 2: alternative destination===
*'''Variable:''' Yes
*'''Arguments:''' ''dest''

This command goes to ''dest'' instead of the regular destination if ''var'' is a certain (unknown) value. (Only used for SELEN 1240 and CHANNEL 3359)

===Command 3: change cursor===
*'''Variable:''' Yes
*'''Arguments:''' ''clrc_id''

*''clrc_id'' is always 800, 801, or 802. (Only 5 different cases). These are the "animated" cursors of dropping the white, red, and blue pages, respectively.

This command seems to change cursor to ''clrc_id'' if var is a certain (unknown) value.

===Command 4===
*'''Variable:''' Optional
*'''Arguments:''' None

===Command 6===
*'''Variable:''' Optional
*'''Arguments:''' None

===Command 7===
*'''Variable:''' Optional
*'''Arguments:''' None

===Command 8===
*'''Variable:''' Optional
*'''Arguments:''' None

===Command 9===
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' is always either ''FFFF'' or omitted.

===Command 12===
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

''Related to [[#Command 13|command 13]]''.

*''u0'' appears to be a nearby card.

This may have similar function to [[#Command 2|command 2]].

===Command 13===
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

''Related to [[#Command 12|command 12]]''.

*''u0'' appears to be a nearby card.

This may have similar function to [[#Command 2|command 2]].

===Command 14===
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

*''u0'' is always 0, 1, or 2.

===Command 15===
*'''Variable:''' Yes
*'''Arguments:''' [''u0'']

*''u0'' is always 0 or omitted.

===Command 16===
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' appears to be a nearby card.
*''u1'' is always 0.

===Command 17===
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' appears to be a nearby card.
*''u1'' is always 4, 5, or 6.

===Command 18===
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' is always 4, 5, or 6.

===Command 19: enable hotspots===
*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count'']

This seems to enable a list of hotspots. All of the ''u0'' numbers are small (0-13, 21).

===Command 20: disable hotspots===
*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count'']

This seems to disable a list of hotspots. All of the ''u0'' numbers are small (0-13, 21). These, unlike [[#Command 19|command 19]], can also be -1, which seems to disable the invoking hotspot.

===Command 21===
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''u2'' ''u3'' ''u4'' ''u5''

There are this command is used 6 times.

*''u0'' is always 0, 74, 76, 117, or 198.
*''u1'' is always 0, 48, 213, or 226.
*''u2'' is always 327, 406, 429, 459, or 544.
*''u3'' is always 257, 332, or 333.
*''u4'' is always 0, 1, 5, 6, or 11.
*''u5'' is always 5 or 25.

===Command 22===
*'''Variable:''' No
*'''Arguments:''' None

===Command 23===
*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count'']

*The ''u0'' numbers are all 0, 4, or 5.

===Command 24===
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' appears to be a sound ID.

===Command 26===
*'''Variable:''' No
*'''Arguments:''' None

===Command 27===
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' appears to be a sound ID.

===Command 28===
*'''Variable:''' No
*'''Arguments:''' (<''l t r b''>|''FFFF'')

*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.

===Command 29===
*'''Variable:''' No
*'''Arguments:''' ''pict_id'' <''l t r b''> ''u0'' ''u1''

*''pict_id'' appears to be a picture ID.
*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.
*''u0'' appears to be a variable number (it is sometimes 0).
*''u1'' may also be a variable number (it is sometimes 0, 1, or -1).

This command seems to copy picture ''pict_id'' over the hotspot, using <''l'' ''t'' ''r'' ''b''> as the source rect. Additional data is unknown.

===Command 30===
*'''Variable:''' No
*'''Arguments:''' <''msnd_id'' ''flags''> [...]

*''msnd_id'' looks like background sound ID to play.
*''flags'' looks like a bit field.

Normally there is only one pair of above values, with a single exception: CHANNEL.3225 has 4 pairs.

===Command 31===
*'''Variable:''' Yes (only ever 30)
*'''Arguments:''' ''u0'' ''u1''

*''u0'' is always 0.
*''u1'' looks like a card ID.

===Command 32===
*'''Variable:''' No
*'''Arguments:''' None

===Command 33===
*'''Variable:''' No
*'''Arguments:''' ''card'' <''l t r b''> ''u0'' ''u1''

*''card'' appears to be a card ID.
*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.
*''u0'' appears to be a variable number (it is sometimes 0).
*''u1'' may also be a variable number (it is sometimes 0).

===Command 34===
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' looks like a card ID.
*''u1'' is always 0, 1, 4, 5, 6, 9, 10, or 11.

===Command 35===
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''u2''

*''u0'' looks like a card ID.
*''u1'' looks like a card ID.
*''u2'' is always 0, 6, or 10.

===Command 36===
*'''Variable:''' No
*'''Arguments:''' ''u0''

This command is only used twice.

*''u0'' is 900 or 903.

===Command 37===
*'''Variable:''' No
*'''Arguments:''' None

===Command 38===
*'''Variable:''' No
*'''Arguments:''' None

===Command 39===
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' is 100, 200, 400, 500, 1000, or 1100.

===Command 40: travel to destination age===
*'''Variable:''' No
*'''Arguments:''' ''dst_age_id'' ''src_msnd_id'' ''dst_msnd_id''

*''dst_age_id'' is one of 0 (selen), 1 (stone), 2 (myst), 3 (mechan), 4 (channel) or 6 (dunny).
*''src_msnd_id'' is a sound ID to play in source age.
*''dst_msnd_id'' is a sound ID to play in destination age.

===Command 41===
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''u2'' ''count'' ''u3''[''count'']

*''u0'' looks like a card ID.
*''u1'' looks like a sound ID.
*''u2'' is always 5 or 10.
*''count'' is only ever 6 or 12.
*''u3'' may be divided into groups of sixes.

===Command 42===
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''count'' ''u2''[''count'']

*''u0'' looks like a sound ID.
*''u1'' is always 5, 10, 15, or 20.
*''count'' is only ever 6 or 12.
*''u2'' may be divided into groups of sixes.

===Command 43===
*'''Variable:''' No
*'''Arguments:''' None

===Command 44===
*'''Variable:''' No
*'''Arguments:''' None

===Command 46===
*'''Variable:''' No
*'''Arguments:''' None

==Commands 100-199==
These are suspected to be age-specific, as their syntax changes depending on the age.
===Command 100===
*'''Variable:''' Optional
*'''Arguments:''' [''u0'']

*''u0'' is always 4, 6, or omitted.

===Command 101===
*'''Variable:''' No
*'''Arguments:''' [''u0''|''u1''[6]]

*''u0'' is always 4225 or omitted.
*''u1'' is a series of 6 positive numbers.

===Command 102===
*'''Variable:''' No
*'''Arguments:''' [''u0'' ''u1'' [''u2'']]

*''u0'' looks like a card ID (or 0).
*''u1'' looks like a card ID.
*''u2'' looks like an (optional) bit field. (only 0x64 or 0)

===Command 103===
*'''Variable:''' Yes
*'''Arguments:''' ''bit''

This form of the command most likely negates bit ''bit'' of ''var''.

*''bit'' is a power of 2 (bit mask).

*'''Variable:''' No
*'''Arguments:''' ''u0'' [''u1'']

This form of the command likely makes specified hotspot drawable.

*''u0'' is a number between 13 and 18. It seems to refer to a hotspot index (see stone 2197).
*''u1'' is either 1 or omitted.

===Command 104===
*'''Variable:''' No
*'''Arguments:''' [''u0'']

This command likely makes specified hotspot not drawable.

*''u0'' can be 0, 1, omitted, or 13 to 20. It seems to refer to a hotspot index (see stone 2004 and 2197).

===Command 105===
*'''Variable:''' Optional (set to 9 at one point, but usually not)
*'''Arguments:''' [''u0'']

*''u0'' looks like a sound ID.

===Command 106===
*'''Variable:''' 10
*'''Arguments:''' 2287 (looks like sound ID)

This command is only used once.

===Command 107===
*'''Variable:''' 11
*'''Arguments:''' 2287 (looks like sound ID)

This command is only used once.

===Command 108===
*'''Variable:''' 12
*'''Arguments:''' 2287 (looks like sound ID)

This command is only used once.

===Command 109===
*'''Variable:''' Optional
*'''Arguments:''' [''u0'']

*''u0'' is ''FFFF'', 1, omitted, or 2287 (looks like sound ID).

===Command 110===
*'''Variable:''' No
*'''Arguments:''' 1180 1179 12 203 78 345 167 6 10 203 166 345 306 5 10

This command is only used once.

===Command 111===
*'''Variable:''' No
*'''Arguments:''' [''u0'']

This command likely makes specified hotspot not drawable.

*''u0'' is 14 to 20 or omitted. It seems to refer to a hotspot index (see stone 2004).

===Command 112===
*'''Variable:''' 29
*'''Arguments:''' ''u0'' ''u1'' ''u2''

This command is only used twice.

*''u0'' is 0 or 1800.
*''u1'' is 400 or 2000.
*''u2'' is 1.

===Command 113===
*'''Variable:''' No
*'''Arguments:''' 5143 10 6 339 237 423 333 0 10

This command is only used once. 5143 is likely sound ID.

===Command 114===
*'''Variable:''' No
*'''Arguments:''' 5143 10 6 339 237 423 333 1 10

This command is only used once. 5143 is likely sound ID.

===Command 115===
*'''Variable:''' Yes
*'''Arguments:''' ''u0''[3]

*The ''u0'' look like card ID's.

*'''Variable:''' No
*'''Arguments:''' 1139 1140 1140 10 6 204 64 343 279 6 50

This form of the command is only used once.

===Command 116===
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' is 0, 1, or 6006.

===Command 117===
*'''Variable:''' No
*'''Arguments:''' [''u0''|''u1'' ''u2'']

*''u0'' is 0, 1, 2, 3, or omitted.
*''u1'' and ''u2'' are 5698 and 6698 (only used once).

===Command 118===
*'''Variable:''' No
*'''Arguments:''' [4707 5707 6707 7707 4705]

This command is only used 3 times (once with values and twice omitted). Values are likely sound IDs.

===Command 119===
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' is 0, 1, or omitted.

===Command 120===
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' is 0, 1, 2, 3, or omitted.

===Command 121===
*'''Variable:''' Yes
*'''Arguments:''' None

*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' is 0 or a card ID.
*''u1'' is a card ID.

===Command 122===
*'''Variable:''' No
*'''Arguments:''' None

===Command 123===
*'''Variable:''' No
*'''Arguments:''' ''u0'' [''u1'']

*''u0'' is 0, 1, or 960.
*''u1'' is 960, 1920, or omitted.

===Command 124===
*'''Variable:''' No
*'''Arguments:''' None

===Command 125===
*'''Variable:''' No
*'''Arguments:''' None

*'''Variable:''' 21
*'''Arguments:''' ''u0''

*''u0'' is 13 or 14.

===Command 126===
*'''Variable:''' No
*'''Arguments:''' None

===Command 127===
*'''Variable:''' no
*'''Arguments:''' ''u0'' ''u1''

*''u0'' is 1, 2, or 3.
*''u1'' is 0 or 1.

===Command 129===
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' looks like a sound ID.

===Command 133===
*'''Variable:''' No
*'''Arguments:''' 6500

This command is only used once. Value is a sound ID.

===Command 164===
*'''Variable:''' No
*'''Arguments:''' None

===Command 169===
*'''Variable:''' No
*'''Arguments:''' None

===Command 198===
*'''Variable:''' No
*'''Arguments:''' 5143 10 6 339 237 423 333 1 10

This command is only used once. 5143 is likely a sound ID.

===Command 199===
*'''Variable:''' No
*'''Arguments:''' None

==Commands 200-299==
These are only seen in the [[Myst INIT resources|INIT]] scripts.
===Command 200===
*'''Variable:''' Optional
*'''Arguments:''' None
*'''Seen:''' DUNNY, INTRO, MECHAN, SELEN, STONE

*'''Variable:''' No
*'''Arguments:''' ''u0 u1''[3]
*'''Seen:''' MYST

*''u1'' appears to be three sound IDs.

===Command 201===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:''' CHANNEL, INTRO, SELEN, STONE

*'''Variable:''' No
*'''Arguments:''' ''u0''
*'''Seen:''' MYST
*''u0'' looks like a sound ID.

*'''Variable:''' No
*'''Arguments:''' 0 4 5
*'''Seen:''' MECHAN

===Command 202===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:''' MECHAN, SELEN, STONE

*'''Variable:''' Yes
*'''Arguments:''' None
*'''Seen:''' CHANNEL

*'''Variable:''' No
*'''Arguments:''' 13
*'''Seen:''' MYST

===Command 203===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:''' CHANNEL, MECHAN, MYST, SELEN

*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count''] ''u1''
*'''Seen:''' STONE

*''u0'' look like node IDs.
*''u1'' looks like a sound ID.

===Command 204===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:''' MYST, SELEN, STONE

*'''Variable:''' No
*'''Arguments:''' ''u0''
*'''Seen:''' MECHAN

*''u0'' looks like a sound ID.

===Command 205===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:''' MYST, SELEN

*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count''] ''u1''
*'''Seen:''' STONE

*''u0'' look like node IDs.
*''u1'' looks like a sound ID.

*'''Variable:''' No
*'''Arguments:''' ''u0''[4]
*'''Seen:''' MECHAN

*''u0'' look like sound IDs.

===Command 206===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:''' MYST, SELEN, STONE

*'''Variable:''' No
*'''Arguments:''' ''u0''[6]
*'''Seen:''' MECHAN

*''u0'' look like sound IDs.

===Command 207===
*'''Variable:''' No
*'''Arguments:''' STONE

===Command 208===
*'''Variable:''' Yes
*'''Arguments:''' None
*'''Seen:''' MYST

*'''Variable:''' No
*'''Arguments:''' ''u0''[3]
*'''Seen:''' STONE

===Command 209===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 210===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 211===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 212===
*'''Variable:''' No
*'''Arguments:''' None

===Command 213===
*'''Variable:''' No
*'''Arguments:''' None

===Command 214===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 215===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 216===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 217===
*'''Variable:''' No
*'''Arguments:''' None

===Command 218===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 219===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 220===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 221===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 222===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

==Commands 300-399
These are only seen in the [[Myst INIT resources|INIT]] scripts.
===Command 300===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 301===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 302===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 303===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 304===
*'''Variable:''' No
*'''Arguments:''' None

===Command 305===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 306===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 307===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 308===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 309===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

===Command 312===
*'''Variable:''' No
*'''Arguments:''' None
*'''Seen:'''

Myst scripts

2008-09-22T20:41:09Z

Di gama: command groupings

Myst scripts

2008-09-10T06:43:26Z

Di gama: oops, clarification

{{Myst}}
This page contains, or will contain, a list of all known commands in Myst, as used in record types 5, 6, 7, 8, 10, 11, and 12. Specifics on the format itself can be found at [[Myst RLST resources]]. The way scripts are stored, they each contain a command number, a variable number, and any number of arguments. When a variable number is not given, a "0" is used. So when the key below says that the variable is "optional", that means that it has been found both with and without a variable being passed in. In some cases, the syntax of the arguments depends on whether a variable was passed in. In this case, the variable/arguments header is repeated for each form of the command.

==Command 0==
*'''Variable:''' Optional
*'''Arguments:''' None

==Command 1==
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

*''u0'' takes on any number between 0 and 7 (maybe a bit field?)

==Command 2: alternative destination==
*'''Variable:''' Yes
*'''Arguments:''' ''dest''

This command goes to ''dest'' instead of the regular destination if ''var'' is a certain (unknown) value. (Only used for SELEN 1240 and CHANNEL 3359)

==Command 3==
*'''Variable:''' Yes
*'''Arguments:''' ''u0''

*''u0'' is always 800, 801, or 802. (Only 5 different cases)

==Command 4==
*'''Variable:''' Optional
*'''Arguments:''' None

==Command 6==
*'''Variable:''' Optional
*'''Arguments:''' None

==Command 7==
*'''Variable:''' Optional
*'''Arguments:''' None

==Command 8==
*'''Variable:''' Optional
*'''Arguments:''' None

==Command 9==
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' is always either ''FFFF'' or omitted.

==Command 12==
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

''Related to [[#Command 13|command 13]]''.

*''u0'' appears to be a nearby node.

This may have similar function to [[#Command 2|command 2]].

==Command 13==
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

''Related to [[#Command 12|command 12]]''.

*''u0'' appears to be a nearby node.

This may have similar function to [[#Command 2|command 2]].

==Command 14==
*'''Variable:''' Optional
*'''Arguments:''' ''u0''

*''u0'' is always 0, 1, or 2.

==Command 15==
*'''Variable:''' Yes
*'''Arguments:''' [''u0'']

*''u0'' is always 0 or omitted.

==Command 16==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' appears to be a nearby node.
*''u1'' is always 0.

==Command 17==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' appears to be a nearby node.
*''u1'' is always 4, 5, or 6.

==Command 18==
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' is always 4, 5, or 6.

==Command 19==
*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count'']

*All of the ''u0'' numbers are small (0-13, 21).

==Command 20==
*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count'']

*All of the ''u0'' numbers are small (0-13, 21). These, unlike [[#Command 19|command 19]], can also be ''FFFF''.

==Command 21==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''u2'' ''u3'' ''u4'' ''u5''

There are this command is used 6 times.

*''u0'' is always 0, 74, 76, 117, or 198.
*''u1'' is always 0, 48, 213, or 226.
*''u2'' is always 327, 406, 429, 459, or 544.
*''u3'' is always 257, 332, or 333.
*''u4'' is always 0, 1, 5, 6, or 11.
*''u5'' is always 5 or 25.

==Command 22==
*'''Variable:''' No
*'''Arguments:''' None

==Command 23==
*'''Variable:''' No
*'''Arguments:''' ''count'' ''u0''[''count'']

*The ''u0'' numbers are all 0, 4, or 5.

==Command 24==
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' appears to be a node number, but it sometimes has a different 1000's place digit (like the numbers in the VIEW resources).

==Command 26==
*'''Variable:''' No
*'''Arguments:''' None

==Command 27==
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' appears to be a node number, but it sometimes has a different 1000's place digit (like the numbers in the VIEW resources).

==Command 28==
*'''Variable:''' No
*'''Arguments:''' (<''l t r b''>|''FFFF'')

*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.

==Command 29==
*'''Variable:''' No
*'''Arguments:''' ''node'' <''l t r b''> ''u0'' ''u1''

*''node'' appears to be a node number.
*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.
*''u0'' appears to be a variable number (it is sometimes 0).
*''u1'' may also be a variable number (it is sometimes 0, 1, or ''FFFF'').

==Command 30==
*'''Variable:''' No
*'''Arguments:''' ''node'' ''flags''

*''node'' looks like a node number.
*''flags'' looks like a bit field.

==Command 31==
*'''Variable:''' Yes (only ever 30)
*'''Arguments:''' ''u0'' ''u1''

*''u0'' is always 0.
*''u1'' looks like a node number.

==Command 32==
*'''Variable:''' No
*'''Arguments:''' None

==Command 33==
*'''Variable:''' No
*'''Arguments:''' ''node'' <''l t r b''> ''u0'' ''u1''

*''node'' appears to be a node number.
*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.
*''u0'' appears to be a variable number (it is sometimes 0).
*''u1'' may also be a variable number (it is sometimes 0).

==Command 34==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' looks like a node number.
*''u1'' is always 0, 1, 4, 5, 6, 9, 10, or 11.

==Command 35==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''u2''

*''u0'' looks like a node number.
*''u1'' looks like a node number.
*''u2'' is always 0, 6, or 10.

==Command 36==
*'''Variable:''' No
*'''Arguments:''' ''u0''

This command is only used twice.

*''u0'' is 900 or 903.

==Command 37==
*'''Variable:''' No
*'''Arguments:''' None

==Command 38==
*'''Variable:''' No
*'''Arguments:''' None

==Command 39==
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' is 100, 200, 400, 500, 1000, or 1100.

==Command 40==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''u2''

*''u0'' is always 0, 1, 2, 3, 4, or 6.
*''u1'' looks like a node number.
*''u2'' looks like a node number.

==Command 41==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''u2'' ''count'' ''u3''[''count'']

*''u0'' looks like a node number.
*''u1'' looks like a node number.
*''u2'' is always 5 or 10.
*''count'' is only ever 6 or 12.
*''u3'' may be divided into groups of sixes.

==Command 42==
*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1'' ''count'' ''u2''[''count'']

*''u0'' looks like a node number.
*''u1'' is always 5, 10, 15, or 20.
*''count'' is only ever 6 or 12.
*''u3'' may be divided into groups of sixes.

==Command 43==
*'''Variable:''' No
*'''Arguments:''' None

==Command 44==
*'''Variable:''' No
*'''Arguments:''' None

==Command 46==
*'''Variable:''' No
*'''Arguments:''' None

==Command 100==
*'''Variable:''' Optional
*'''Arguments:''' [''u0'']

*''u0'' is always 4, 6, or omitted.

==Command 101==
*'''Variable:''' No
*'''Arguments:''' [''u0''|''u1''[6]]

*''u0'' is always 4225 or omitted.
*''u1'' is a series of 6 positive numbers.

==Command 102==
*'''Variable:''' No
*'''Arguments:''' [''u0'' ''u1'' [''u2'']]

*''u0'' looks like a node number (or 0).
*''u1'' looks like a node number.
*''u2'' looks like an (optional) bit field. (only 0x64 or 0)

==Command 103==
*'''Variable:''' Yes
*'''Arguments:''' ''bit''

This form of the command most likely negates bit ''bit'' of ''var''.

*''bit'' is a power of 2 (bit mask).

*'''Variable:''' No
*'''Arguments:''' ''u0'' [''u1'']

This form of the command is unknown.

*''u0'' is a number between 13 and 18.
*''u1'' is either 1 or omitted.

==Command 104==
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' can be 0, 1, omitted, or 13 to 20.

==Command 105==
*'''Variable:''' Optional (set to 9 at one point, but usually not)
*'''Arguments:''' [''u0'']

*''u0'' looks like a node number.

==Command 106==
*'''Variable:''' 10
*'''Arguments:''' 2287

This command is only used once.

==Command 107==
*'''Variable:''' 11
*'''Arguments:''' 2287

This command is only used once.

==Command 108==
*'''Variable:''' 12
*'''Arguments:''' 2287

This command is only used once.

==Command 109==
*'''Variable:''' Optional
*'''Arguments:''' [''u0'']

*''u0'' is ''FFFF'', 1, omitted, or 2287.

==Command 110==
*'''Variable:''' No
*'''Arguments:''' 1180 1179 12 203 78 345 167 6 10 203 166 345 306 5 10

This command is only used once.

==Command 111==
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' is 14 to 20 or omitted.

==Command 112==
*'''Variable:''' 29
*'''Arguments:''' ''u0'' ''u1'' ''u2''

This command is only used twice.

*''u0'' is 0 or 1800.
*''u1'' is 400 or 2000.
*''u2'' is 1.

==Command 113==
*'''Variable:''' No
*'''Arguments:''' 5143 10 6 339 237 423 333 0 10

This command is only used once.

==Command 114==
*'''Variable:''' No
*'''Arguments:''' 5143 10 6 339 237 423 333 1 10

This command is only used once.

==Command 115==
*'''Variable:''' Yes
*'''Arguments:''' ''u0''[3]

*The ''u0'' look like node numbers.

*'''Variable:''' No
*'''Arguments:''' 1139 1140 1140 10 6 204 64 343 279 6 50

This form of the command is only used once.

==Command 116==
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' is 0, 1, or 6006.

==Command 117==
*'''Variable:''' No
*'''Arguments:''' [''u0''|''u1'' ''u2'']

*''u0'' is 0, 1, 2, 3, or omitted.
*''u1'' and ''u2'' are 5698 and 6698 (only used once).

==Command 118==
*'''Variable:''' No
*'''Arguments:''' [4707 5707 6707 7707 4705]

This command is only used twice (once with values and once omitted).

==Command 119==
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' is 0, 1, or omitted.

==Command 120==
*'''Variable:''' No
*'''Arguments:''' [''u0'']

*''u0'' is 0, 1, 2, 3, or omitted.

==Command 121==
*'''Variable:''' Yes
*'''Arguments:''' None

*'''Variable:''' No
*'''Arguments:''' ''u0'' ''u1''

*''u0'' is 0 or a node number.
*''u1'' is a node number.

==Command 122==
*'''Variable:''' No
*'''Arguments:''' None

==Command 123==
*'''Variable:''' No
*'''Arguments:''' ''u0'' [''u1'']

*''u0'' is 0, 1, or 960.
*''u1'' is 960, 1920, or omitted.

==Command 124==
*'''Variable:''' No
*'''Arguments:''' None

==Command 125==
*'''Variable:''' No
*'''Arguments:''' None

*'''Variable:''' 21
*'''Arguments:''' ''u0''

*''u0'' is 13 or 14.

==Command 126==
*'''Variable:''' No
*'''Arguments:''' None

==Command 127==
*'''Variable:''' no
*'''Arguments:''' ''u0'' ''u1''

*''u0'' is 1, 2, or 3.
*''u1'' is 0 or 1.

==Command 129==
*'''Variable:''' No
*'''Arguments:''' ''u0''

*''u0'' looks like a node number.

==Command 133==
*'''Variable:''' No
*'''Arguments:''' 6500

This command is only used once.

==Command 164==
*'''Variable:''' No
*'''Arguments:''' None

==Command 169==
*'''Variable:''' No
*'''Arguments:''' None

==Command 198==
*'''Variable:''' No
*'''Arguments:''' 5143 10 6 339 237 423 333 1 10

This command is only used once.

==Command 199==
*'''Variable:''' No
*'''Arguments:''' None

Myst scripts

2008-09-10T06:27:12Z

Di gama: Basic outline of every command (phew!)

{{Myst}}
This page contains, or will contain, a list of all known commands in Myst, as used in record types 5, 6, 7, 8, 10, 11, and 12. Specifics on the format itself can be found at [[Myst RLST resources]].

==Command 0==
'''Variable:''' Optional
'''Arguments:''' None

==Command 1==
'''Variable:''' Optional
'''Arguments:''' ''u0''

*''u0'' takes on any number between 0 and 7 (maybe a bit field?)

==Command 2: alternative destination==
'''Variable:''' Yes
'''Arguments:''' ''dest''

This command goes to ''dest'' instead of the regular destination if ''var'' is a certain (unknown) value. (Only used for SELEN 1240 and CHANNEL 3359)

==Command 3==
'''Variable:''' Yes
'''Arguments:''' ''u0''

*''u0'' is always 800, 801, or 802. (Only 5 different cases)

==Command 4==
'''Variable:''' Optional
'''Arguments:''' None

==Command 6==
'''Variable:''' Optional
'''Arguments:''' None

==Command 7==
'''Variable:''' Optional
'''Arguments:''' None

==Command 8==
'''Variable:''' Optional
'''Arguments:''' None

==Command 9==
'''Variable:''' No
'''Arguments:''' [''u0'']

*''u0'' is always either ''FFFF'' or omitted.

==Command 12==
'''Variable:''' Optional
'''Arguments:''' ''u0''

''Related to [[#Command 13|command 13]]''.

*''u0'' appears to be a nearby node.

This may have similar function to [[#Command 2|command 2]].

==Command 13==
'''Variable:''' Optional
'''Arguments:''' ''u0''

''Related to [[#Command 12|command 12]]''.

*''u0'' appears to be a nearby node.

This may have similar function to [[#Command 2|command 2]].

==Command 14==
'''Variable:''' Optional
'''Arguments:''' ''u0''

*''u0'' is always 0, 1, or 2.

==Command 15==
'''Variable:''' Yes
'''Arguments:''' [''u0'']

*''u0'' is always 0 or omitted.

==Command 16==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1''

*''u0'' appears to be a nearby node.
*''u1'' is always 0.

==Command 17==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1''

*''u0'' appears to be a nearby node.
*''u1'' is always 4, 5, or 6.

==Command 18==
'''Variable:''' No
'''Arguments:''' ''u0''

*''u0'' is always 4, 5, or 6.

==Command 19==
'''Variable:''' No
'''Arguments:''' ''count'' ''u0''[''count'']

*All of the ''u0'' numbers are small (0-13, 21).

==Command 20==
'''Variable:''' No
'''Arguments:''' ''count'' ''u0''[''count'']

*All of the ''u0'' numbers are small (0-13, 21). These, unlike [[#Command 19|command 19]], can also be ''FFFF''.

==Command 21==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1'' ''u2'' ''u3'' ''u4'' ''u5''

There are this command is used 6 times.

*''u0'' is always 0, 74, 76, 117, or 198.
*''u1'' is always 0, 48, 213, or 226.
*''u2'' is always 327, 406, 429, 459, or 544.
*''u3'' is always 257, 332, or 333.
*''u4'' is always 0, 1, 5, 6, or 11.
*''u5'' is always 5 or 25.

==Command 22==
'''Variable:''' No
'''Arguments:''' None

==Command 23==
'''Variable:''' No
'''Arguments:''' ''count'' ''u0''[''count'']

*The ''u0'' numbers are all 0, 4, or 5.

==Command 24==
'''Variable:''' No
'''Arguments:''' ''u0''

*''u0'' appears to be a node number, but it sometimes has a different 1000's place digit (like the numbers in the VIEW resources).

==Command 26==
'''Variable:''' No
'''Arguments:''' None

==Command 27==
'''Variable:''' No
'''Arguments:''' ''u0''

*''u0'' appears to be a node number, but it sometimes has a different 1000's place digit (like the numbers in the VIEW resources).

==Command 28==
'''Variable:''' No
'''Arguments:''' (<''l t r b''>|''FFFF'')

*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.

==Command 29==
'''Variable:''' No
'''Arguments:''' ''node'' <''l t r b''> ''u0'' ''u1''

*''node'' appears to be a node number.
*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.
*''u0'' appears to be a variable number (it is sometimes 0).
*''u1'' may also be a variable number (it is sometimes 0, 1, or FFFF).

==Command 30==
'''Variable:''' No
'''Arguments:''' ''node'' ''flags''

*''node'' looks like a node number.
*''flags'' looks like a bit field.

==Command 31==
'''Variable:''' Yes (only ever 30)
'''Arguments:''' ''u0'' ''u1''

*''u0'' is always 0.
*''u1'' looks like a node number.

==Command 32==
'''Variable:''' No
'''Arguments:''' None

==Command 33==
'''Variable:''' No
'''Arguments:''' ''node'' <''l t r b''> ''u0'' ''u1''

*''node'' appears to be a node number.
*<''l t r b''> often corresponds with the intended location of one of the sub-images in the VIEW resources.
*''u0'' appears to be a variable number (it is sometimes 0).
*''u1'' may also be a variable number (it is sometimes 0).

==Command 34==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1''

*''u0'' looks like a node number.
*''u1'' is always 0, 1, 4, 5, 6, 9, 10, or 11.

==Command 35==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1'' ''u2''

*''u0'' looks like a node number.
*''u1'' looks like a node number.
*''u2'' is always 0, 6, or 10.

==Command 36==
'''Variable:''' No
'''Arguments:''' ''u0''

This command is only used twice.

*''u0'' is 900 or 903.

==Command 37==
'''Variable:''' No
'''Arguments:''' None

==Command 38==
'''Variable:''' No
'''Arguments:''' None

==Command 39==
'''Variable:''' No
'''Arguments:''' ''u0''

*''u0'' is 100, 200, 400, 500, 1000, or 1100.

==Command 40==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1'' ''u2''

*''u0'' is always 0, 1, 2, 3, 4, or 6.
*''u1'' looks like a node number.
*''u2'' looks like a node number.

==Command 41==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1'' ''u2'' ''count'' ''u3''[''count'']

*''u0'' looks like a node number.
*''u1'' looks like a node number.
*''u2'' is always 5 or 10.
*''count'' is only ever 6 or 12.
*''u3'' may be divided into groups of sixes.

==Command 42==
'''Variable:''' No
'''Arguments:''' ''u0'' ''u1'' ''count'' ''u2''[''count'']

*''u0'' looks like a node number.
*''u1'' is always 5, 10, 15, or 20.
*''count'' is only ever 6 or 12.
*''u3'' may be divided into groups of sixes.

==Command 43==
'''Variable:''' No
'''Arguments:''' None

==Command 44==
'''Variable:''' No
'''Arguments:''' None

==Command 46==
'''Variable:''' No
'''Arguments:''' None

==Command 100==
'''Variable:''' Optional
'''Arguments:''' [''u0'']

*''u0'' is always 4, 6, or omitted.

==Command 101==
'''Variable:''' No
'''Arguments:''' [''u0''|''u1''[6]]

*''u0'' is always 4225 or omitted.
*''u1'' is a series of 6 positive numbers.

==Command 102==
'''Variable:''' No
'''Arguments:''' [''u0'' ''u1'' [''u2'']]

*''u0'' looks like a node number (or 0).
*''u1'' looks like a node number.
*''u2'' looks like an (optional) bit field. (only 0x64 or 0)

==Command 103==
'''Variable:''' Yes
'''Arguments:''' ''bit''

This form of the command most likely negates bit ''bit'' of ''var''.

*''bit'' is a power of 2 (bit mask).

'''Variable:''' No
'''Arguments:''' ''u0'' [''u1'']

This form of the command is unknown.

*''u0'' is a number between 13 and 18.
*''u1'' is either 1 or omitted.

==Command 104==
'''Variable:''' No
'''Arguments:''' [''u0'']

*''u0'' can be 0, 1, omitted, or 13 to 20.

==Command 105==
'''Variable:''' Optional (set to 9 at one point, but usually not)
'''Arguments:''' [''u0'']

*''u0'' looks like a node number.

==Command 106==
'''Variable:''' 10
'''Arguments:''' 2287

This command is only used once.

==Command 107==
'''Variable:''' 11
'''Arguments:''' 2287

This command is only used once.

==Command 108==
'''Variable:''' 12
'''Arguments:''' 2287

This command is only used once.

==Command 109==
'''Variable:''' Optional
'''Arguments:''' [''u0'']

*''u0'' is FFFF, 1, omitted, or 2287.

==Command 110==
'''Variable:''' No
'''Arguments:''' 1180 1179 12 203 78 345 167 6 10 203 166 345 306 5 10

This command is only used once.

==Command 111==
'''Variable:''' No
'''Arguments:''' [''u0'']

*''u0'' is 14 to 20 or omitted.

==Command 112==
'''Variable:''' 29
'''Arguments:''' ''u0'' ''u1'' ''u2''

This command is only used twice.

*''u0'' is 0 or 1800.
*''u1'' is 400 or 2000.
*''u2'' is 1.

==Command 113==
'''Variable:''' No
'''Arguments:''' 5143 10 6 339 237 423 333 0 10

This command is only used once.

==Command 114==
'''Variable:''' No
'''Arguments:''' 5143 10 6 339 237 423 333 1 10

This command is only used once.

==Command 115==
'''Variable:''' Yes
'''Arguments:''' ''u0''[3]

*The ''u0'' look like node numbers.

'''Variable:''' No
'''Arguments:''' 1139 1140 1140 10 6 204 64 343 279 6 50

This form of the command is only used once.

==Command 116==
'''Variable:''' No
'''Arguments:''' ''u0''

*''u0'' is 0, 1, or 6006.

==Command 117==
'''Variable:''' No
'''Arguments:''' [''u0''|''u1'' ''u2'']

*''u0'' is 0, 1, 2, 3, or omitted.
*''u1'' and ''u2'' are 5698 and 6698 (only used once).

==Command 118==
'''Variable:''' No
'''Arguments:''' [4707 5707 6707 7707 4705]

This command is only used twice (once with values and once omitted).

==Command 119==
'''Variable:''' No
'''Arguments:''' [''u0'']

*''u0'' is 0, 1, or omitted.

==Command 120==
'''Variable:''' No
'''Arguments:''' [''u0'']

*''u0'' is 0, 1, 2, 3, or omitted.

==Command 121==
'''Variable:''' Yes
'''Arguments:''' None

'''Variable:''' No
'''Arguments:''' ''u0'' ''u1''

*''u0'' is 0 or a node number.
*''u1'' is a node number.

==Command 122==
'''Variable:''' No
'''Arguments:''' None

==Command 123==
'''Variable:''' No
'''Arguments:''' ''u0'' [''u1'']

*''u0'' is 0, 1, or 960.
*''u1'' is 960, 1920, or omitted.

==Command 124==
'''Variable:''' No
'''Arguments:''' None

==Command 125==
'''Variable:''' No
'''Arguments:''' None

'''Variable:''' 21
'''Arguments:''' ''u0''

*''u0'' is 13 or 14.

==Command 126==
'''Variable:''' No
'''Arguments:''' None

==Command 127==
'''Variable:''' no
'''Arguments:''' ''u0'' ''u1''

*''u0'' is 1, 2, or 3.
*''u1'' is 0 or 1.

==Command 129==
'''Variable:''' No
'''Arguments:''' ''u0''

*''u0'' looks like a node number.

==Command 133==
'''Variable:''' No
'''Arguments:''' 6500

This command is only used once.

==Command 164==
'''Variable:''' No
'''Arguments:''' None

==Command 169==
'''Variable:''' No
'''Arguments:''' None

==Command 198==
'''Variable:''' No
'''Arguments:''' 5143 10 6 339 237 423 333 1 10

This command is only used once.

==Command 199==
'''Variable:''' No
'''Arguments:''' None

Myst scripts

2008-09-09T18:35:51Z

Di gama: stub (the commands are correct though)

{{Myst}}
This page contains, or will contain, a list of all known commands in Myst, as used in record types 5, 6, 7, 8, 10, 11, and 12. Specifics on the format itself can be found at [[Myst RLST resources]].

==Command 0==

==Command 1==

==Command 2==

==Command 3==

==Command 4==

==Command 6==

==Command 7==

==Command 8==

==Command 9==

==Command 12==

==Command 13==

==Command 14==

==Command 15==

==Command 16==

==Command 17==

==Command 18==

==Command 19==

==Command 20==

==Command 21==

==Command 22==

==Command 23==

==Command 24==

==Command 26==

==Command 27==

==Command 28==

==Command 29==

==Command 30==

==Command 31==

==Command 32==

==Command 33==

==Command 34==

==Command 35==

==Command 36==

==Command 37==

==Command 38==

==Command 39==

==Command 40==

==Command 41==

==Command 42==

==Command 43==

==Command 44==

==Command 46==

==Command 100==

==Command 101==

==Command 102==

==Command 103==

==Command 104==

==Command 105==

==Command 106==

==Command 107==

==Command 108==

==Command 109==

==Command 110==

==Command 111==

==Command 112==

==Command 113==

==Command 114==

==Command 115==

==Command 116==

==Command 117==

==Command 118==

==Command 119==

==Command 120==

==Command 121==

==Command 122==

==Command 123==

==Command 124==

==Command 125==

==Command 126==

==Command 127==

==Command 129==

==Command 133==

==Command 164==

==Command 169==

==Command 198==

==Command 199==

Template:Myst

2008-09-09T17:54:44Z

Di gama: scripts

{| class="toc" align="right" border="0" cellpadding="2" style="text-align:center"
|colspan=4|'''<big>Myst</big>'''
|-
|colspan=2|[[Mohawk archive format|Mohawk]]
|colspan=2|[[Myst engine overview|Overview]]
|-
|[[Myst CLRC resources|CLRC]]
|[[Myst EXIT resources|EXIT]]
|[[Myst HINT resources|HINT]]
|[[Myst INIT resources|INIT]]
|-
|[[Myst MJMP resources|MJMP]]
|[[Myst MSND resources|MSND]]
|[[Myst PICT resources|PICT]]
|[[Myst RLST resources|RLST]]
|-
|[[Myst VIEW resources|VIEW]]
|[[Myst WDIB resources|WDIB]]
|[[Myst HELP resources|HELP]]
|[[Myst RSFL resources|RSFL]]
|-
|colspan=2|[[Myst scripts|Scripts]]
|colspan=2|[[Myst variables|Variables]]
|}

Myst RLST resources

2008-09-09T16:20:55Z

Di gama: /* Intro Case Study */ cleaned up with new info

{{Myst}}

These seem to contain Myst's hotspot data.

There are the same number of RLST and [[Myst_VIEW_resources|VIEW]] resources in all Myst packages and we suspect RLST resources are associated with their cards by sharing the ID with the corresponding VIEW, similarly to what happens in Riven with CARDs and HSPTs.

The data represents a list of records, each record describing one of the hotspots:
{| class="structure"
|short||record_count
|-
|variable||records
|}

The record content and length seems to depend on the leading fields of the record. However, there seems to be a common structure:
{| class="structure"
|unsigned short||action
|-
|unsigned short||flags
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|unsigned short||destination
|-
|variable||additional data
|}
*''action'' seems to specify the hotspot action in a wide sense. Every value between 0 and 14 except for 9 has been observed. Low values (under 5) seem associated with "simple" hotspots that usually just change card. Higher values indicate complex actions (movies, picking up pages etc.)
*''flags'' seems to be a bit field. Observed values are 0, 1, 2, 3, 5, 6 and 8. Bit 3 is suspected to flag Zip Mode hotspots.
*The following 4 fields define the hotspot rectangle. Note that "weird" rectangles are found, like (-32000, -32000, 32000, 32000).
*''destination'' contains a destination card ID for hotspots that change card, or zero.
*Additional data follows when ''action'' > 3 (complex hotspots), clearly representing lists of actions to perform. We have yet to figure out how to calculate the length of those complex records.

====Case studies====
Note: these are simply the data in little-endian shorts and line-broken where patterns are found. <l t b r> is the hotspot rect. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).

The following hotspots replace part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere):
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

Case studies from Channelwood:
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 2 [6 0 0] [24 0 1 {3494}] (the door)
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 [3004 <0 0 127 73>] [3003 <FFFF>]

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 [3006 <0 0 132 57>] [3005 <FFFF>]

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5 (1 [3 103 1 {802}]) 103 2 [3013 <0 0 113 100>] [3012 <FFFF>]
5 2 <255 193 269 208> 0 1 [117 0 1 {0}]
5 2 <268 193 282 208> 0 1 [117 0 1 {1}]
5 2 <281 193 295 208> 0 1 [117 0 1 {2}]
5 2 <294 193 308 208> 0 1 [117 0 1 {3}]
8 1 <252 190 310 210> 0 FFFF 0 17 4 [3008 <0 0 58 20>] [3009 <0 0 58 20>] [3010 <0 0 58 20>] [3011 <0 0 58 20>]
0 4 <180 31 379 305> 0
5 2 <0 0 544 332> 0 1 [34 0 2 {3005 0}]

(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 5 (1 [3 103 1 {802}]) 103 2 [FFFF <FFFF>] [4369 <0 0 70 90>]
7 2 <216 110 304 235> 0 106 5
5 (1 [115 101 3 {4741 4370 4368}])
5 (1 [115 101 3 {4741 4370 4368}])
5 (1 [115 101 3 {4741 4370 4368}])
5 (1 [115 101 3 {4741 4370 4368}])
5 (0)
0 2 <0 0 544 332> 4345

==== Intro Case Study ====
See a bit below for where the game starts, INTRO 0. Here's INTRO 1, because it's more deciphered than that.

(INTRO 1) 1
5 2 <245 202 304 253> 4 2 [37 0 0] [34 0 2 {3 11}]

INTRO 1 is the first interactive part of the game, the part where you can pick up the Myst book. The rect correctly corresponds to where the book is on screen. But, look at the "destination" -- 4. There is no VIEW/RLST 4! However, there is a WDIB 4 and it is the open book with the water. Where this ''should'' go is to card 3 and show the Myst book cover before showing image 4 and then playing the video. And, there is a 3 in this chunk, but I'm not sure if that's the purpose. I have no idea what commands 37/34 could be. There is a WDIB 11, but it's of D'ni, so I doubt it's that. ;)

(INTRO 2) 2
0 2 <-32000 -32000 32000 32000> 5
6 0 <312 70 441 159> 0 0 "\qtw\intro\intro2" 0x2848 0x2756 0 1 0 0 0

Note that this one has a string for the video (null-terminated). This obviously calls that video which is the Myst fly-by for the linking book. And, that rect perfectly matches where the video should be displayed on screen. However, this also clearly breaks the format specified above for "type 2 hotspots".

WDIB 3 is the cover of the Myst linking book. But, this doesn't match up with the video mentioned here which should be for WDIB 4 (or 10, they are identical)(the open linking book with the water image) and eventually ending at WDIB 12 (the open linking book with the dock image). The 5 after the very large numbers is the target card for the open linking book which seems correct. 0x2848 is 10,312 and 0x2756 is 10,070. The rate of the audio is 11,025. Not sure if this has any correlation.

(INTRO 0) 1
0 2 <-32000 -32000 32000 32000> 5

This is the same as the first record of INTRO 2. My guess is that this is some sort of call to an external command. INTRO 0 is supposed to be the card which shows the opening movies and then switches to card 2.

Myst RLST resources

2008-09-09T16:17:52Z

Di gama: /* Case studies */ cleaned up using new information

{{Myst}}

These seem to contain Myst's hotspot data.

There are the same number of RLST and [[Myst_VIEW_resources|VIEW]] resources in all Myst packages and we suspect RLST resources are associated with their cards by sharing the ID with the corresponding VIEW, similarly to what happens in Riven with CARDs and HSPTs.

The data represents a list of records, each record describing one of the hotspots:
{| class="structure"
|short||record_count
|-
|variable||records
|}

The record content and length seems to depend on the leading fields of the record. However, there seems to be a common structure:
{| class="structure"
|unsigned short||action
|-
|unsigned short||flags
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|unsigned short||destination
|-
|variable||additional data
|}
*''action'' seems to specify the hotspot action in a wide sense. Every value between 0 and 14 except for 9 has been observed. Low values (under 5) seem associated with "simple" hotspots that usually just change card. Higher values indicate complex actions (movies, picking up pages etc.)
*''flags'' seems to be a bit field. Observed values are 0, 1, 2, 3, 5, 6 and 8. Bit 3 is suspected to flag Zip Mode hotspots.
*The following 4 fields define the hotspot rectangle. Note that "weird" rectangles are found, like (-32000, -32000, 32000, 32000).
*''destination'' contains a destination card ID for hotspots that change card, or zero.
*Additional data follows when ''action'' > 3 (complex hotspots), clearly representing lists of actions to perform. We have yet to figure out how to calculate the length of those complex records.

====Case studies====
Note: these are simply the data in little-endian shorts and line-broken where patterns are found. <l t b r> is the hotspot rect. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).

The following hotspots replace part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere):
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

Case studies from Channelwood:
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 2 [6 0 0] [24 0 1 {3494}] (the door)
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 [3004 <0 0 127 73>] [3003 <FFFF>]

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 [3006 <0 0 132 57>] [3005 <FFFF>]

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5 (1 [3 103 1 {802}]) 103 2 [3013 <0 0 113 100>] [3012 <FFFF>]
5 2 <255 193 269 208> 0 1 [117 0 1 {0}]
5 2 <268 193 282 208> 0 1 [117 0 1 {1}]
5 2 <281 193 295 208> 0 1 [117 0 1 {2}]
5 2 <294 193 308 208> 0 1 [117 0 1 {3}]
8 1 <252 190 310 210> 0 FFFF 0 17 4 [3008 <0 0 58 20>] [3009 <0 0 58 20>] [3010 <0 0 58 20>] [3011 <0 0 58 20>]
0 4 <180 31 379 305> 0
5 2 <0 0 544 332> 0 1 [34 0 2 {3005 0}]

(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 5 (1 [3 103 1 {802}]) 103 2 [FFFF <FFFF>] [4369 <0 0 70 90>]
7 2 <216 110 304 235> 0 106 5
5 (1 [115 101 3 {4741 4370 4368}])
5 (1 [115 101 3 {4741 4370 4368}])
5 (1 [115 101 3 {4741 4370 4368}])
5 (1 [115 101 3 {4741 4370 4368}])
5 (0)
0 2 <0 0 544 332> 4345

==== Intro Case Study ====
See a bit below for where the game starts, INTRO 0. Here's INTRO 1, because it's more deciphered than that.

(INTRO 1) 1
5 2 <245 202 304 253> 4 2 37 0 0 34 0 2 3 11

INTRO 1 is the first interactive part of the game, the part where you can pick up the Myst book. The rect correctly corresponds to where the book is on screen. But, look at the "destination" -- 4. There is no VIEW/RLST 4! However, there is a WDIB 4 and it is the open book with the water. Where this ''should'' go is to card 3 and show the Myst book cover before showing image 4 and then playing the video. And, there is a 3 in this chunk, but I'm not sure if that's the purpose. I have no idea what the 37/34 could mean. There is a WDIB 11, but it's of D'ni, so I doubt it's that. ;)

(INTRO 2) 2
0 2 -32000 -32000 32000 32000 5
6 0 <312 70 441 159> 0 0 "\qtw\intro\intro2" 0x2848 0x2756 0 1 0 0 0

Note that this one has a string for the video (null-terminated). This obviously calls that video which is the Myst fly-by for the linking book. And, that rect perfectly matches where the video should be displayed on screen. However, this also clearly breaks the format specified above for "type 2 hotspots".

WDIB 3 is the cover of the Myst linking book. But, this doesn't match up with the video mentioned here which should be for WDIB 4 (or 10, they are identical)(the open linking book with the water image) and eventually ending at WDIB 12 (the open linking book with the dock image). The 5 after the very large numbers is the target card for the open linking book which seems correct. 0x2848 is 10,312 and 0x2756 is 10,070. The rate of the audio is 11,025. Not sure if this has any correlation.

(INTRO 0) 1
0 2 -32000 -32000 32000 32000 5

This is the same as the first record of INTRO 2. My guess is that this is some sort of call to an external command. INTRO 0 is supposed to be the card which shows the opening movies and then switches to card 2.

Myst RLST resources

2008-09-09T13:45:58Z

Di gama: confusion!

{{Myst}}

These seem to contain Myst's hotspot data.

There are the same number of RLST and [[Myst_VIEW_resources|VIEW]] resources in all Myst packages and we suspect RLST resources are associated with their cards by sharing the ID with the corresponding VIEW, similarly to what happens in Riven with CARDs and HSPTs.

The data represents a list of records, each record describing one of the hotspots:
{| class="structure"
|short||record_count
|-
|variable||records
|}

The record content and length seems to depend on the leading fields of the record. However, there seems to be a common structure:
{| class="structure"
|unsigned short||action
|-
|unsigned short||flags
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|unsigned short||destination
|-
|variable||additional data
|}
*''action'' seems to specify the hotspot action in a wide sense. Every value between 0 and 14 except for 9 has been observed. Low values (under 5) seem associated with "simple" hotspots that usually just change card. Higher values indicate complex actions (movies, picking up pages etc.)
*''flags'' seems to be a bit field. Observed values are 0, 1, 2, 3, 5, 6 and 8. Bit 3 is suspected to flag Zip Mode hotspots.
*The following 4 fields define the hotspot rectangle. Note that "weird" rectangles are found, like (-32000, -32000, 32000, 32000).
*''destination'' contains a destination card ID for hotspots that change card, or zero.
*Additional data follows when ''action'' > 3 (complex hotspots), clearly representing lists of actions to perform. We have yet to figure out how to calculate the length of those complex records.

====Case studies====
Note: these are simply the data in little-endian shorts and line-broken where patterns are found. <l t b r> is the hotspot rect. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).

The following hotspots replace part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere):
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

Case studies from Channelwood:
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 2 6 0 0 24 0 1 3494 (the door)
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5
1 3 <103 1 802 103> 2 3013 <0 0 113 100> 3012 FFFF
5 2 <255 193 269 208> 0 1 117 0 1 0
5 2 <268 193 282 208> 0 1 117 0 1 1
5 2 <281 193 295 208> 0 1 117 0 1 2
5 2 <294 193 308 208> 0 1 117 0 1 3
8 1 <252 190 310 210> 0 FFFF 0 17 4
[3008 <0 0 58 20>]
[3009 <0 0 58 20>]
[3010 <0 0 58 20>]
[3011 <0 0 58 20>]
0 4
<180 31 379 305> 0 5 2
<0 0 544 332> 0 1 34
0 2 3005 0

(The following is probably broken the wrong way, there should be 3 hotspots only)
(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 [5 1 3 103 1 802] 103 2 FFFF FFFF 4369 <0 0 70 90>
7 2 <216 110 304 235> 0 106 5 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5 0
0 2 <0 0 544 332> 4345

==== Intro Case Study ====
See a bit below for where the game starts, INTRO 0. Here's INTRO 1, because it's more deciphered than that.

(INTRO 1) 1
5 2 <245 202 304 253> 4 2 37 0 0 34 0 2 3 11

INTRO 1 is the first interactive part of the game, the part where you can pick up the Myst book. The rect correctly corresponds to where the book is on screen. But, look at the "destination" -- 4. There is no VIEW/RLST 4! However, there is a WDIB 4 and it is the open book with the water. Where this ''should'' go is to card 3 and show the Myst book cover before showing image 4 and then playing the video. And, there is a 3 in this chunk, but I'm not sure if that's the purpose. I have no idea what the 37/34 could mean. There is a WDIB 11, but it's of D'ni, so I doubt it's that. ;)

(INTRO 2) 2
0 2 -32000 -32000 32000 32000 5
6 0 <312 70 441 159> 0 0 "\qtw\intro\intro2" 0x2848 0x2756 0 1 0 0 0

Note that this one has a string for the video (null-terminated). This obviously calls that video which is the Myst fly-by for the linking book. And, that rect perfectly matches where the video should be displayed on screen. However, this also clearly breaks the format specified above for "type 2 hotspots".

WDIB 3 is the cover of the Myst linking book. But, this doesn't match up with the video mentioned here which should be for WDIB 4 (or 10, they are identical)(the open linking book with the water image) and eventually ending at WDIB 12 (the open linking book with the dock image). The 5 after the very large numbers is the target card for the open linking book which seems correct. 0x2848 is 10,312 and 0x2756 is 10,070. The rate of the audio is 11,025. Not sure if this has any correlation.

(INTRO 0) 1
0 2 -32000 -32000 32000 32000 5

This is the same as the first record of INTRO 2. My guess is that this is some sort of call to an external command. INTRO 0 is supposed to be the card which shows the opening movies and then switches to card 2.

Myst RLST resources

2008-09-09T12:45:40Z

Di gama: added flag info; flags and action are switched

{{Myst}}

These seem to contain Myst's hotspot data.

There are the same number of RLST and [[Myst_VIEW_resources|VIEW]] resources in all Myst packages and we suspect RLST resources are associated with their cards by sharing the ID with the corresponding VIEW, similarly to what happens in Riven with CARDs and HSPTs.

The data represents a list of records, each record describing one of the hotspots:
{| class="structure"
|short||record_count
|-
|variable||records
|}

The record content and length seems to depend on the leading fields of the record. However, there seems to be a common structure:
{| class="structure"
|unsigned short||flags
|-
|unsigned short||action
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|unsigned short||destination
|-
|variable||additional data
|}
*''flags'' seems to be a bit field. Every value between 0 and 14 except for 9 has been observed, so only 4 bits are in play. Bit 3 is suspected to flag Zip Mode hotspots.
*''action'' seems to specify the hotspot action in a wide sense. Observed values are 0, 1, 2, 3, 5, 6 and 8. Low values (under 5) seem associated with "simple" hotspots that usually just change card. Higher values indicate complex actions (movies, picking up pages etc.)
*The following 4 fields define the hotspot rectangle. Note that "weird" rectangles are found, like (-32000, -32000, 32000, 32000).
*''destination'' contains a destination card ID for hotspots that change card, or zero.
*Additional data follows when ''action'' > 3 (complex hotspots), clearly representing lists of actions to perform. We have yet to figure out how to calculare the length of those complex records.

====Case studies====
Note: these are simply the data in little-endian shorts and line-broken where patterns are found. <l t b r> is the hotspot rect. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).

The following hotspots replacee part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere):
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

Case studies from Channelwood:
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 2 6 0 0 24 0 1 3494 (the door)
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5
1 3 <103 1 802 103> 2 3013 <0 0 113 100> 3012 FFFF
5 2 <255 193 269 208> 0 1 117 0 1 0
5 2 <268 193 282 208> 0 1 117 0 1 1
5 2 <281 193 295 208> 0 1 117 0 1 2
5 2 <294 193 308 208> 0 1 117 0 1 3
8 1 <252 190 310 210> 0 FFFF 0 17 4
[3008 <0 0 58 20>]
[3009 <0 0 58 20>]
[3010 <0 0 58 20>]
[3011 <0 0 58 20>]
0 4
<180 31 379 305> 0 5 2
<0 0 544 332> 0 1 34
0 2 3005 0

(The following is probably broken the wrong way, there should be 3 hotspots only)
(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 [5 1 3 103 1 802] 103 2 FFFF FFFF 4369 <0 0 70 90>
7 2 <216 110 304 235> 0 106 5 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5 0
0 2 <0 0 544 332> 4345

==== Intro Case Study ====
See a bit below for where the game starts, INTRO 0. Here's INTRO 1, because it's more deciphered than that.

(INTRO 1) 1
5 2 <245 202 304 253> 4 2 37 0 0 34 0 2 3 11

INTRO 1 is the first interactive part of the game, the part where you can pick up the Myst book. The rect correctly corresponds to where the book is on screen. But, look at the "destination" -- 4. There is no VIEW/RLST 4! However, there is a WDIB 4 and it is the open book with the water. Where this ''should'' go is to card 3 and show the Myst book cover before showing image 4 and then playing the video. And, there is a 3 in this chunk, but I'm not sure if that's the purpose. I have no idea what the 37/34 could mean. There is a WDIB 11, but it's of D'ni, so I doubt it's that. ;)

(INTRO 2) 2
0 2 -32000 -32000 32000 32000 5
6 0 <312 70 441 159> 0 0 "\qtw\intro\intro2" 0x2848 0x2756 0 1 0 0 0

Note that this one has a string for the video (null-terminated). This obviously calls that video which is the Myst fly-by for the linking book. And, that rect perfectly matches where the video should be displayed on screen. However, this also clearly breaks the format specified above for "type 2 hotspots".

WDIB 3 is the cover of the Myst linking book. But, this doesn't match up with the video mentioned here which should be for WDIB 4 (or 10, they are identical)(the open linking book with the water image) and eventually ending at WDIB 12 (the open linking book with the dock image). The 5 after the very large numbers is the target card for the open linking book which seems correct. 0x2848 is 10,312 and 0x2756 is 10,070. The rate of the audio is 11,025. Not sure if this has any correlation.

(INTRO 0) 1
0 2 -32000 -32000 32000 32000 5

This is the same as the first record of INTRO 2. My guess is that this is some sort of call to an external command. INTRO 0 is supposed to be the card which shows the opening movies and then switches to card 2.

Myst VIEW resources

2008-09-08T15:08:53Z

Di gama: /* More Unknown */ card ID

{{Myst}}

VIEW resources are the candidate Myst card representations, as they seem to glue other resources together like WDIB and MSND. In particular they seem to describe what to show on screen and what sound to play.

Original hints by Petroff Heroj.

= Basic Format =
The data seems split into four sections with different meanings: conditional images, main section and two unknown sections.

== Conditional Images ==
The first section seems to provide lists of pictures, and the value of specified variables should define which pictures to show.
{| class="structure"
|unsigned short||u0
|-
|unsigned short||image_count
|-
|variable||conditional_images
|}
*''u0'' is unknown (always either ''0'' or ''1'').
*''image_count'' is the number of conditional image blocks (always either ''0'' or ''1'').
*''conditional_images'' are the conditional image blocks.
The image blocks have the following structure:
{| class="structure"
|unsigned short||variable
|-
|unsigned short||num_states
|-
|unsigned short||image_ids[num_states]
|}
*''variable'' is the variable to check against.
*''image_ids'' is an array of ''num_states'' unsigned shorts representing WDIB (or PICT) IDs.
The variable value is the index of what image to use in the ''image_ids'' array.

== Main Segment ==
The main section seems to provide basic info about the card:
{| class="structure"
|unsigned short||main_image
|-
|signed short||sound
|-
|unsigned short||flags
|}
*''main_image'' is the main image to show on the screen. (Kind of like the default case).
*''sound'' is the sound id to play. If it is less than 0, it acts like a flag to pause, continue sound (-1?), or stop the current sound (what means what still needs to be checked).
*''flags'' appears to be flags.

== Unknown Segment ==
TODO: I haven't completely figured this out. Petroff's guess was that it preloaded resources. However, it doesn't make sense that it is like that. It starts with an unsigned short representing the count. Then, following that is an unsigned short (which he believed to be the resource type to load). If it was 3 then there would be an array of WDIB's (an array of unsigned shorts, starting with a count and an unknown -- each unsigned shorts). A 1 would mean a single WDIB, a 2 would mean a single MSND (each represented by an unsigned short).

== More Unknown ==
Following that is four unsigned shorts. Petroff's guess was that they represented RLST, HINT, EXIT, and INIT respectively. But, that doesn't line up with the resources that exist in the files. More likely, those resources are dependent upon the card ID. Every short here is either ''0'' or the card ID. In addition, the first short in this section is always the card ID (never ''0'').

= Old Case Studies =
image name and sub-images (akin to Riven PLSTs)
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3001||-1||0/0||3001||3001||0||0
|-
| || ||name||neg.||bytes||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3002||-2||0/144||0|| ||3002||3002||0||0
|-
|0||0||3003||-2||0/144||1||[1 3004]||3003||3003||0||0
|-
| || ||name||?|| ||count||entry||colspan=4|(name name 0 0)
|}

*I think ''3004'' is the name of a sub-image (small image to be placed in another) of ''3003'' here.
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3005||3005||0/144||1||[1 3006]||3005||3005||0||0
|-
| || ||colspan=2|name twice|| || ||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3012||-2||0/50||5||[1 3013]||[1 3008]||[1 3009]||[1 3010]||[1 3011]||3012||0||0||3012
|-
| || ||name||?|| ||count||colspan=5|entries||colspan=4|(name 0 0 name)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
!14
|1||1||5||2||3030||3031||FFFC 3 2 3031 00_A0||4031||x00A0||2||2 4030||1 3030|| || ||3031||3031||0||0
|-
!44
|1||1||2||2||3095||3096||FFFC 15 2 3095 00_A0||4095||x00A0||4||2 4095||1 3562||1 3097||2 5095||3095||3095||3095||0
|-
!348
|1||1||16||2||3536||3535|| ||3535||x0060||0|| || || || ||3535||3535||0||0
|-
!359
|1||1||5||2||3550||3552||FFFC 3 2 6552 00_80||3552||x0080||4||4 3550||4 3552||2 4552||2 5552||3552||3552||0||0
|-
!47
|1||1||10||2||4140||4141|| ||5141||x0090||1||2 4141|| || || ||4141||4141||4141||4141
|-
!50
|1||1||10||2||4148||4149|| ||4149||x0090||0|| || || || ||4149||4149||4149||0
|-
!51
|1||1||10||2||4150||4151|| ||FFFE||x0070||0|| || || || ||4150||4150||0||0
|-
!94
|1||1||10||2||4243||4244|| ||4244||x0050||0|| || || || ||4244||4244||0||0
|-
!116
|1||1||40||2||4292||4294||FFFC 40 2 4292 00_50||4292||x0060||2||1 4293||2 5292|| || ||4292||4292||0||0
|-
!145
|1||1||0||2||4358||4357|| ||FFFE||x0030||0|| || || || ||4357||4357||0||0
|-
!287
|1||1||34||3||4698||4701|| ||4702||xFFFD||4||1 4699||2 4698||2 5698||2 6698||4698||4698||4698||4698
|-
!295
|1||1||10||2||4717||4719|| ||4717||x0040||1||1 4718|| || || ||4717||4717||0||0
|}

Myst VIEW resources

2008-09-08T14:19:22Z

Di gama: /* More Unknown */ another observation

{{Myst}}

VIEW resources are the candidate Myst card representations, as they seem to glue other resources together like WDIB and MSND. In particular they seem to describe what to show on screen and what sound to play.

Original hints by Petroff Heroj.

= Basic Format =
The data seems split into four sections with different meanings: conditional images, main section and two unknown sections.

== Conditional Images ==
The first section seems to provide lists of pictures, and the value of specified variables should define which pictures to show.
{| class="structure"
|unsigned short||u0
|-
|unsigned short||image_count
|-
|variable||conditional_images
|}
*''u0'' is unknown (always either ''0'' or ''1'').
*''image_count'' is the number of conditional image blocks (always either ''0'' or ''1'').
*''conditional_images'' are the conditional image blocks.
The image blocks have the following structure:
{| class="structure"
|unsigned short||variable
|-
|unsigned short||num_states
|-
|unsigned short||image_ids[num_states]
|}
*''variable'' is the variable to check against.
*''image_ids'' is an array of ''num_states'' unsigned shorts representing WDIB (or PICT) IDs.
The variable value is the index of what image to use in the ''image_ids'' array.

== Main Segment ==
The main section seems to provide basic info about the card:
{| class="structure"
|unsigned short||main_image
|-
|signed short||sound
|-
|unsigned short||flags
|}
*''main_image'' is the main image to show on the screen. (Kind of like the default case).
*''sound'' is the sound id to play. If it is less than 0, it acts like a flag to pause, continue sound (-1?), or stop the current sound (what means what still needs to be checked).
*''flags'' appears to be flags.

== Unknown Segment ==
TODO: I haven't completely figured this out. Petroff's guess was that it preloaded resources. However, it doesn't make sense that it is like that. It starts with an unsigned short representing the count. Then, following that is an unsigned short (which he believed to be the resource type to load). If it was 3 then there would be an array of WDIB's (an array of unsigned shorts, starting with a count and an unknown -- each unsigned shorts). A 1 would mean a single WDIB, a 2 would mean a single MSND (each represented by an unsigned short).

== More Unknown ==
Following that is four unsigned shorts. Petroff's guess was that they represented RLST, HINT, EXIT, and INIT respectively. But, that doesn't line up with the resources that exist in the files. More likely, those resources are dependent upon the card IC. Every short here is either ''0'' or the card ID.

= Old Case Studies =
image name and sub-images (akin to Riven PLSTs)
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3001||-1||0/0||3001||3001||0||0
|-
| || ||name||neg.||bytes||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3002||-2||0/144||0|| ||3002||3002||0||0
|-
|0||0||3003||-2||0/144||1||[1 3004]||3003||3003||0||0
|-
| || ||name||?|| ||count||entry||colspan=4|(name name 0 0)
|}

*I think ''3004'' is the name of a sub-image (small image to be placed in another) of ''3003'' here.
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3005||3005||0/144||1||[1 3006]||3005||3005||0||0
|-
| || ||colspan=2|name twice|| || ||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3012||-2||0/50||5||[1 3013]||[1 3008]||[1 3009]||[1 3010]||[1 3011]||3012||0||0||3012
|-
| || ||name||?|| ||count||colspan=5|entries||colspan=4|(name 0 0 name)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
!14
|1||1||5||2||3030||3031||FFFC 3 2 3031 00_A0||4031||x00A0||2||2 4030||1 3030|| || ||3031||3031||0||0
|-
!44
|1||1||2||2||3095||3096||FFFC 15 2 3095 00_A0||4095||x00A0||4||2 4095||1 3562||1 3097||2 5095||3095||3095||3095||0
|-
!348
|1||1||16||2||3536||3535|| ||3535||x0060||0|| || || || ||3535||3535||0||0
|-
!359
|1||1||5||2||3550||3552||FFFC 3 2 6552 00_80||3552||x0080||4||4 3550||4 3552||2 4552||2 5552||3552||3552||0||0
|-
!47
|1||1||10||2||4140||4141|| ||5141||x0090||1||2 4141|| || || ||4141||4141||4141||4141
|-
!50
|1||1||10||2||4148||4149|| ||4149||x0090||0|| || || || ||4149||4149||4149||0
|-
!51
|1||1||10||2||4150||4151|| ||FFFE||x0070||0|| || || || ||4150||4150||0||0
|-
!94
|1||1||10||2||4243||4244|| ||4244||x0050||0|| || || || ||4244||4244||0||0
|-
!116
|1||1||40||2||4292||4294||FFFC 40 2 4292 00_50||4292||x0060||2||1 4293||2 5292|| || ||4292||4292||0||0
|-
!145
|1||1||0||2||4358||4357|| ||FFFE||x0030||0|| || || || ||4357||4357||0||0
|-
!287
|1||1||34||3||4698||4701|| ||4702||xFFFD||4||1 4699||2 4698||2 5698||2 6698||4698||4698||4698||4698
|-
!295
|1||1||10||2||4717||4719|| ||4717||x0040||1||1 4718|| || || ||4717||4717||0||0
|}

Myst VIEW resources

2008-09-08T14:17:24Z

Di gama: /* Conditional Images */ observation

{{Myst}}

VIEW resources are the candidate Myst card representations, as they seem to glue other resources together like WDIB and MSND. In particular they seem to describe what to show on screen and what sound to play.

Original hints by Petroff Heroj.

= Basic Format =
The data seems split into four sections with different meanings: conditional images, main section and two unknown sections.

== Conditional Images ==
The first section seems to provide lists of pictures, and the value of specified variables should define which pictures to show.
{| class="structure"
|unsigned short||u0
|-
|unsigned short||image_count
|-
|variable||conditional_images
|}
*''u0'' is unknown (always either ''0'' or ''1'').
*''image_count'' is the number of conditional image blocks (always either ''0'' or ''1'').
*''conditional_images'' are the conditional image blocks.
The image blocks have the following structure:
{| class="structure"
|unsigned short||variable
|-
|unsigned short||num_states
|-
|unsigned short||image_ids[num_states]
|}
*''variable'' is the variable to check against.
*''image_ids'' is an array of ''num_states'' unsigned shorts representing WDIB (or PICT) IDs.
The variable value is the index of what image to use in the ''image_ids'' array.

== Main Segment ==
The main section seems to provide basic info about the card:
{| class="structure"
|unsigned short||main_image
|-
|signed short||sound
|-
|unsigned short||flags
|}
*''main_image'' is the main image to show on the screen. (Kind of like the default case).
*''sound'' is the sound id to play. If it is less than 0, it acts like a flag to pause, continue sound (-1?), or stop the current sound (what means what still needs to be checked).
*''flags'' appears to be flags.

== Unknown Segment ==
TODO: I haven't completely figured this out. Petroff's guess was that it preloaded resources. However, it doesn't make sense that it is like that. It starts with an unsigned short representing the count. Then, following that is an unsigned short (which he believed to be the resource type to load). If it was 3 then there would be an array of WDIB's (an array of unsigned shorts, starting with a count and an unknown -- each unsigned shorts). A 1 would mean a single WDIB, a 2 would mean a single MSND (each represented by an unsigned short).

== More Unknown ==
Following that is four unsigned shorts. Petroff's guess was that they represented RLST, HINT, EXIT, and INIT respectively. But, that doesn't line up with the resources that exist in the files. More likely, those resources are dependent upon the card id.

= Old Case Studies =
image name and sub-images (akin to Riven PLSTs)
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3001||-1||0/0||3001||3001||0||0
|-
| || ||name||neg.||bytes||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3002||-2||0/144||0|| ||3002||3002||0||0
|-
|0||0||3003||-2||0/144||1||[1 3004]||3003||3003||0||0
|-
| || ||name||?|| ||count||entry||colspan=4|(name name 0 0)
|}

*I think ''3004'' is the name of a sub-image (small image to be placed in another) of ''3003'' here.
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3005||3005||0/144||1||[1 3006]||3005||3005||0||0
|-
| || ||colspan=2|name twice|| || ||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3012||-2||0/50||5||[1 3013]||[1 3008]||[1 3009]||[1 3010]||[1 3011]||3012||0||0||3012
|-
| || ||name||?|| ||count||colspan=5|entries||colspan=4|(name 0 0 name)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
!14
|1||1||5||2||3030||3031||FFFC 3 2 3031 00_A0||4031||x00A0||2||2 4030||1 3030|| || ||3031||3031||0||0
|-
!44
|1||1||2||2||3095||3096||FFFC 15 2 3095 00_A0||4095||x00A0||4||2 4095||1 3562||1 3097||2 5095||3095||3095||3095||0
|-
!348
|1||1||16||2||3536||3535|| ||3535||x0060||0|| || || || ||3535||3535||0||0
|-
!359
|1||1||5||2||3550||3552||FFFC 3 2 6552 00_80||3552||x0080||4||4 3550||4 3552||2 4552||2 5552||3552||3552||0||0
|-
!47
|1||1||10||2||4140||4141|| ||5141||x0090||1||2 4141|| || || ||4141||4141||4141||4141
|-
!50
|1||1||10||2||4148||4149|| ||4149||x0090||0|| || || || ||4149||4149||4149||0
|-
!51
|1||1||10||2||4150||4151|| ||FFFE||x0070||0|| || || || ||4150||4150||0||0
|-
!94
|1||1||10||2||4243||4244|| ||4244||x0050||0|| || || || ||4244||4244||0||0
|-
!116
|1||1||40||2||4292||4294||FFFC 40 2 4292 00_50||4292||x0060||2||1 4293||2 5292|| || ||4292||4292||0||0
|-
!145
|1||1||0||2||4358||4357|| ||FFFE||x0030||0|| || || || ||4357||4357||0||0
|-
!287
|1||1||34||3||4698||4701|| ||4702||xFFFD||4||1 4699||2 4698||2 5698||2 6698||4698||4698||4698||4698
|-
!295
|1||1||10||2||4717||4719|| ||4717||x0040||1||1 4718|| || || ||4717||4717||0||0
|}

Myst RLST resources

2008-09-04T03:53:21Z

Di gama: /* Intro Case Study */ Be careful about the indeces. They are zero-based, not one-based (for simplicity when reading the data)

{{Myst}}

These seem to contain Myst's hotspot data.

There are the same number of RLST and VIEW resources in all Myst packages: thus they may be locked together by index like HSPT and CARD resources in Riven.

{| class="structure"
|short||count_of_records
|}
====record type 1====
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF
*this replaces part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere)
====record type 2: (simple hotspot)====
''clone2727 says: This does not seem to match everything. I don't think the second short represents type.''

{| class="structure"
|short||dir 1=left, 2=right, 5=forward
|-
|short||type=2
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|short||destination
|}

====Case studies====
(Note: these are simply the data in (little-endian) shorts and line-broken where I saw patterns. <l t b r> are (I think) areas on-screen. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).)
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 (the door)
2 6 0 0 24 0 1 3494
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5
1 3 <103 1 802 103> 2 3013 <0 0 113 100> 3012 FFFF
5 2 <255 193 269 208> 0 1 117 0 1 0
5 2 <268 193 282 208> 0 1 117 0 1 1
5 2 <281 193 295 208> 0 1 117 0 1 2
5 2 <294 193 308 208> 0 1 117 0 1 3
8 1 <252 190 310 210> 0 FFFF 0 17 4
[3008 <0 0 58 20>]
[3009 <0 0 58 20>]
[3010 <0 0 58 20>]
[3011 <0 0 58 20>]
0 4
<180 31 379 305> 0 5 2
<0 0 544 332> 0 1 34
0 2 3005 0

(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 [5 1 3 103 1 802] 103 2 FFFF FFFF 4369 <0 0 70 90>
7 2 <216 110 304 235> 0 106 5 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5 0
0 2 <0 0 544 332> 4345

==== Intro Case Study ====
See a bit below for where the game starts, INTRO 0. Here's INTRO 1, because it's more deciphered than that.

(INTRO 1) 1
5 2 <245 202 304 253> 4 2 37 0 0 34 0 2 3 11

INTRO 1 is the first interactive part of the game, the part where you can pick up the Myst book. The rect correctly corresponds to where the book is on screen. But, look at the "destination" -- 4. There is no VIEW/RLST 4! However, there is a WDIB 4 and it is the open book with the water. Where this ''should'' go is to card 3 and show the Myst book cover before showing image 4 and then playing the video. And, there is a 3 in this chunk, but I'm not sure if that's the purpose. I have no idea what the 37/34 could mean. There is a WDIB 11, but it's of D'ni, so I doubt it's that. ;)

(INTRO 2) 2
0 2 -32000 -32000 32000 32000 5
6 0 <312 70 441 159> "\qtw\intro\intro2" 0x2848 0x2756 0 1 0 0 0

Note that this one has a string for the video (null-terminated). This obviously calls that video which is the Myst fly-by for the linking book. And, that rect perfectly matches where the video should be displayed on screen. However, this also clearly breaks the format specified above for "type 2 hotspots".

WDIB 3 is the cover of the Myst linking book. But, this doesn't match up with the video mentioned here which should be for WDIB 4 (or 10, they are identical)(the open linking book with the water image) and eventually ending at WDIB 12 (the open linking book with the dock image). The 5 after the very large numbers is the target card for the open linking book which seems correct. 0x2848 is 10,312 and 0x2756 is 10,070. The rate of the audio is 11,025. Not sure if this has any correlation.

(INTRO 0) 1
0 2 -32000 -32000 32000 32000 5

This is the same as the first record of INTRO 2. My guess is that this is some sort of call to an external command. INTRO 0 is supposed to be the card which shows the opening movies and then switches to card 2.

Myst resources

2008-02-18T15:42:01Z

Di gama: /* VIEW */ fixes

{{Myst}}
This page contains or will contain a comprehensive analysis of the 8 resources in Myst (and the two added in Myst ME).

Both Myst and Myst ME use little-endian byte order in the files (by contrast to the big-endian byte order used in Riven and the Mohawk format), although the data itself is stored in properly formatted Mohawk format (don't let the .dni or .dat file extension fool you). The packages in Myst ME are:
*CHANNEL
*CREDITS
*DUNNY
*INTRO
*MECHAN
*MYST
*SELEN
*STONE
*SYSTEM
The resources are on the left (MJMP and PICT are new in ME). None of the resources are named except for the MSND/MJMP resources.

==CLRC==
All CLRC resources follow the pattern:
{| class="structure"
|short||u1
|-
|short||u2
|}
*''u1'' and ''u2'' are both 1, 6, 7, 8, 9, or 14 for all files

==EXIT==
I think these are variables, although that seems unlikely because SELEN has no EXIT resources.
<noinclude>===Case studies (all of them)===
Note: these are presented as ''resource_index''.''length short...'' where the data is broken into shorts and displayed in decimal.
====CHANNEL====
*0.12 1 0 300 0 0 1
====DUNNY====
*0.22 2 0 300 0 0 1 0 100 0 0 1
====INTRO====
*0.22 2 0 300 0 0 1 0 38 0 0 1
*1.12 1 0 38 0 0 1
====MECHAN====
*0.24 2 0 27 0 1 7044 1 0 4 0 0 1
*1.12 1 0 300 0 0 1
*2.12 1 0 32 0 0 1
====MYST====
*0.12 1 0 301 0 0 1
*1.12 1 0 301 0 0 1
*2.12 1 0 301 0 0 1
*3.12 1 0 301 0 0 1
*4.12 1 0 301 0 0 1
*5.12 1 1 306 0 0 1
*6.12 1 1 306 0 0 1
*7.12 1 0 302 0 0 1
*8.12 1 0 303 0 0 1
*9.12 1 0 303 0 0 1
*10.36 3 [0 1 302 1 1 1] [0 309 0 0 1 0] [1 309 1 0 1]
*11.12 1 0 307 0 0 1
*12.24 2 [0 300 100 0 2 0] [1 309 1 0 1]
*13.24 2 [0 300 101 0 2 0] [1 309 1 0 1]
*14.12 1 [0 303 0 0 1]
*15.14 1 0 308 0 0 1 0
*16.12 1 [0 304 0 0 1]
*17.12 1 [0 304 0 0 1]
*18.22 2 [0 304 0 0 1] [0 305 0 0 1]
*19.12 1 [1 304 0 0 1]
*20.22 2 [0 304 0 0 1] [0 305 0 0 1]
*21.12 1 [0 304 0 0 1]
*22.22 2 [0 304 0 0 1] [0 305 0 0 1]
*23.12 1 [0 304 0 0 1]
*24.12 1 [0 312 0 0 1]
*25.66
3 0 29 0 7 8708 0 0 152 165 198 107
1 0 42 0 9 8707 10 6 216 129 368 294
5 50 1 0 24 0 1 9707 1
====STONE====
*0.14 1 0 125 21 1 14 1
*1.14 1 0 125 21 1 13 1
*2.12 1 0 300 0 0 1

==INIT==
These are more likely variables. They do not have names like in Riven.
===Case studies===
====CHANNEL====
*0.12 1 0 1 30 1 0
*1.10 1 6 201 0 0
====DUNNY====
*1.18 2 0 26 0 0 0 200 0 0
====MYST====
*2.30 2 1 209 0 0 0 206 0 6 6044 7044 8044 9044 10044 11044
*4.18 1 0 205 0 4 6156 7156 8156 9156
*5.16 1 0 201 0 3 0 4 5
*6.12 1 0 204 0 1 6180

==HINT==
{| class="structure"
|short||rc||class="comment|record count
|}
*rc is wrong in:
**CHANNEL 78 231
**MECHAN 109
**MYST 2 28 38 43 45 49 106 109 149 150 173 175 206 231
**SELEN 172
**STONE 10 12 18 59 89 91 106
records are
{| class="structure"
|short||rid||class="comment|record index
|-
|short||u1||
|}
*the ''rid'''s start at zero and go up, but there are exceptions.
**CHANNEL 78 144 231
**DUNNY all minus 1 5 7 18 19
**MECHAN 109
**Myst 2 28 43 45 49 78 111 171 173 175 184 206 229 235
**STONE 10 12 18 59 89 91 106
*the ''u1'''s all appear to be one of 0, 2, 3, 200, 300, 400, 500, 600, 904, 905, 999, or FFFF (-1)

==MSND==
It is interesting to note that all MSND resources in the whole game are named except for INTRO 1 (the linking sound). In all the other packages, this sound is labeled "transprt7" (in MYST) or "transprt1" and "transprt2" (which all appear to be the same, although transprt1 and transprt2 are separate resources in the package).

==RLST and VIEW==
There are the same number of RLST and VIEW resources in all packages, which leads me to believe that they are locked together by index like HSPT and CARD resources in Riven.

===RLST===
I think these contain hotspot data (i.e. HSPT).

{| class="structure"
|short||count_of_records
|}
====record type 1====
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF
*this replaces part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere)
====record type 2: (simple hotspot)====
{| class="structure"
|short||dir 1=left, 2=right, 5=forward
|-
|short||type=2
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|short||destination
|}

====Case studies====
(Note: these are simply the data in (little-endian) shorts and line-broken where I saw patterns. <l t b r> are (I think) areas on-screen. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).)
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 (the door)
2 6 0 0 24 0 1 3494
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5
1 3 <103 1 802 103> 2 3013 <0 0 113 100> 3012 FFFF
5 2 <255 193 269 208> 0 1 117 0 1 0
5 2 <268 193 282 208> 0 1 117 0 1 1
5 2 <281 193 295 208> 0 1 117 0 1 2
5 2 <294 193 308 208> 0 1 117 0 1 3
8 1 <252 190 310 210> 0 FFFF 0 17 4
[3008 <0 0 58 20>]
[3009 <0 0 58 20>]
[3010 <0 0 58 20>]
[3011 <0 0 58 20>]
0 4
<180 31 379 305> 0 5 2
<0 0 544 332> 0 1 34
0 2 3005 0

(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 [5 1 3 103 1 802] 103 2 FFFF FFFF 4369 <0 0 70 90>
7 2 <216 110 304 235> 0 106 5 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
0 0 2 0 0 544 332 4345

===VIEW===
image name and sub-images (akin to Riven PLSTs)
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3001||-1||0/0||3001||3001||0||0
|-
| || ||name||neg.||bytes||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3002||-2||0/144||0|| ||3002||3002||0||0
|-
|0||0||3003||-2||0/144||1||[1 3004]||3003||3003||0||0
|-
| || ||name||?|| ||count||entry||colspan=4|(name name 0 0)
|}

*I think ''3004'' is the name of a sub-image (small image to be placed in another) of ''3003'' here.
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3005||3005||0/144||1||[1 3006]||3005||3005||0||0
|-
| || ||colspan=2|name twice|| || ||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
|0||0||3012||-2||0/50||5||[1 3013]||[1 3008]||[1 3009]||[1 3010]||[1 3011]||3012||0||0||3012
|-
| || ||name||?|| ||count||colspan=5|entries||colspan=4|(name 0 0 name)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse;text-align:center;"
!14
|1||1||5||2||3030||3031||FFFC 3 2 3031 00_A0||4031||x00A0||2||2 4030||1 3030|| || ||3031||3031||0||0
|-
!44
|1||1||2||2||3095||3096||FFFC 15 2 3095 00_A0||4095||x00A0||4||2 4095||1 3562||1 3097||2 5095||3095||3095||3095||0
|-
!348
|1||1||16||2||3536||3535|| ||3535||x0060||0|| || || || ||3535||3535||0||0
|-
!359
|1||1||5||2||3550||3552||FFFC 3 2 6552 00_80||3552||x0080||4||4 3550||4 3552||2 4552||2 5552||3552||3552||0||0
|-
!47
|1||1||10||2||4140||4141|| ||5141||x0090||1||2 4141|| || || ||4141||4141||4141||4141
|-
!50
|1||1||10||2||4148||4149|| ||4149||x0090||0|| || || || ||4149||4149||4149||0
|-
!51
|1||1||10||2||4150||4151|| ||FFFE||x0070||0|| || || || ||4150||4150||0||0
|-
!94
|1||1||10||2||4243||4244|| ||4244||x0050||0|| || || || ||4244||4244||0||0
|-
!116
|1||1||40||2||4292||4294||FFFC 40 2 4292 00_50||4292||x0060||2||1 4293||2 5292|| || ||4292||4292||0||0
|-
!145
|1||1||0||2||4358||4357|| ||FFFE||x0030||0|| || || || ||4357||4357||0||0
|-
!287
|1||1||34||3||4698||4701|| ||4702||xFFFD||4||1 4699||2 4698||2 5698||2 6698||4698||4698||4698||4698
|-
!295
|1||1||10||2||4717||4719|| ||4717||x0040||1||1 4718|| || || ||4717||4717||0||0
|}

Riven scripts

2008-02-18T15:12:45Z

Di gama: a bunch of little things

{{Riven}}
This document talks about the Riven scripting protocol.

==Overview and main data structures==
The Riven engine is programmed using ''scripts'' attached to objects. The architecture resembles the HyperCard philosophy. A script is subdivided in ''handlers''; each handler is associated to an event which may happen to the script's object and it contains the actions to be executed when that event happens. The actions are described by a list of ''commands''. Cards and hotspots are the only entities with attached scripts.

A script is represented by this data block:

{| class="structure"
|unsigned short||handler_count
|-
|variable size||handler list
|}

Each handler is made of this block:

{| class="structure"
|unsigned short||event_type
|-
|unsigned short||cmd_count
|-
|variable size||command list
|}

The following table gives event types identified until now. Types 0 ... 5 are reserved to hotspots, 6 ... 10 are reserved to cards.

<span id="Handlers"></span>
{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! event_type !! What happened
|-
|0||Mouse button pressed inside the hotspot rect
|-
|1||Mouse button pressed inside the hotspot rect (never seen in the game)
|-
|2||Mouse button released inside the hotspot rect
|-
|3||Mouse moved, pressed or released inside the hotspot rect (never seen in the game)
|-
|4||Mouse held inside the hotspot rect (the event is sent repeatedly)
|-
|5||Mouse moved inside the hotspot rect (not sure)
|-
|6||Card "loaded". This is the first event sent to a card. Usually cards enable things here. Screen updates are disabled during the execution of this handler, and the display is updated at the end.
|-
|7||Leaving card.
|-
|9||Card opened. This is sent at the end, when the card has been loaded and the display has been updated. Usually cards start movies and ambient sounds here.
|-
|10||Display being updated; for example this event is triggered when the handler for event 6 completes, or by [[#Command 21: enable screen update|command 21]]. The handler is executed before actually updating the display.
|}

In general, each command is an opcode followed by a number of arguments. The same command can be passed a variable number of arguments, though only a few commands actually behave like that. The general structure is:

{| class="structure"
|unsigned short||cmd
|-
|unsigned short||arg_count
|-
|unsigned short||args[arg_count]
|}

The following subsections explain what has been discovered about each command. Unlisted opcodes have never been observed in Riven.
==Command 1: draw tBMP resource==
*'''Argument count:''' 9
*'''Arguments:''' ''tbmp_id left top right bottom u0 u1 u2 u3''

Draw bitmap from tBMP resource ''tbmp_id'' inside the rectangle described by ''left'', ''top'', ''right'', ''bottom''. If the rectangle dimensions do not match the bitmap size, the bitmap will be attached to the top-left corner and clipped to the rectangle. Other arguments are always zero and seem ignored by the engine.

The command will automatically update the display unless [[#Command 20: disable screen update|command 20]] was used before.

==Command 2: go to card==
*'''Argument count:''' 1
*'''Arguments:''' ''id''

Go to card ''id''. In most cases this command is used in very short hotspot scripts containing just a transition command followed by the "go to card" one. In these cases, the following event chain takes place:
*the old card receives [[#Handlers|event 7]];
*the new card receives event 6;
*the new card receives event 10 (because the display is begin updated);
*the transition effect is played and the new card image is displayed;
*the new card receives event 9.

However, it is also used in card event handlers, like 9 or 10. Sometimes it appears multiple times in the same script. The event sequence for these complicated cases is not yet fully understood.

==Command 3: play tWAV resource mix==
*'''Argument count:''' variable
*'''Arguments:''' ''N ids[N] fade_flags loop volume u0 u1 volumes[N] balances[N] u2[N]''

Play a mix of ''N'' tWAV sounds from the associated sounds Mohawk archive. The argument list is structured like an [[Riven SLST resources|SLST]] resource record. This command stops previously active ambient sounds.

==Command 4: play local tWAV resource==
*'''Argument count:''' 3
*'''Arguments:''' ''id volume u1''

Play tWAV resource ''id'' from the Mohawk archive containing the script. ''volume'' seems always 256, ''u1'' always 0. Ambient sounds are not touched; the sound is mixed over them.

==Command 7: set variable value==
*'''Argument count:''' 2
*'''Arguments:''' ''var value''

Set variable ''var'' to value ''value''.

==Command 8: conditional branch==
This doesn't follow the ''command arg_count'' args scheme. It's similar to a C "switch" statement: given a variable, there is a list of possible variable values and a corresponding command list to be executed. The structure of command 8 is:

{| class="structure"
|unsigned short||8
|-
|unsigned short||2
|-
|unsigned short||var
|-
|unsigned short||value_count
|}

Then ''value_count'' blocks follow, each with this structure:

{| class="structure"
|unsigned short||value
|-
|unsigned short||command_count
|-
|colspan="2" style="color:#000"|commands to execute if var contains value
|}

If ''value'' is 0xffff, the block is the "default" block exactly like in the C statement. As an example, let's compare the script syntax with a C-like switch statement:
{| align="center" valign="center"
|
0008 0002 beef 3
0001 0001
a
0002 0001
b
ffff 0002
c
d
|
switch (variable 0xbeef) {
case 1:
a;
break;
case 2:
b;
break;
default:
c;
d;
break;
}
|}

The conditional branch command is used on levers, switches and every place where a variable value makes the difference. It's often used as a simple if-then-else mechanism.

==Command 9: enable hotspot==
*'''Argument count:''' 1
*'''Arguments:''' ''hotspot_id''

Enable card hotspot with the specified ''hotspot_id''.

==Command 10: disable hotspot==
*'''Argument count:''' 1
*'''Arguments:''' ''hotspot_id''

Disable card hotspot with the specified ''hotspot_id''. A disabled hotspot will not respond to events.

==Command 12==
*'''Argument count:''' 1
*'''Arguments:''' ''u0''

Unknown. ''u0'' is 0, 1 or 2. This command is used only a few times, for example near "go to stack" commands like in the "play riven" button. It doesn't seem related to anything special (e.g. movies or sounds). Setting ''u0'' to some other value or replacing the command with others doesn't produce readily observable effects. I suspect it has something to do with variables, but I have yet to realize how to check this.
==Command 13: set mouse cursor==
[[Image:Cursors.png|right|frame|Riven cursor icons and their IDs]]
*'''Argument count:''' 1
*'''Arguments:''' ''cursor''

Set mouse cursor icon to ''cursor'', whose meaning is given on the right.

==Command 14: pause script execution==
*'''Argument count:''' 2
*'''Arguments:''' ms ''u0''

Pause script execution for ''ms'' milliseconds. ''ms'' is signed and the pause is effective only if ''ms'' > 0. ''u0'' is always 0 and its value seems ignored by the engine.

==Command 17: call external command==
*'''Argument count:''' variable, at least 2
*'''Arguments:''' ''cmd count arg1 arg2 ...''

Call an external piece of custom code ("external command"), which is probably hardcoded inside the Riven executable. ''cmd'' tells which external command to call, and ''count'' tells how many arguments to pass to it. Then ''count'' arguments follow. [[Riven NAME resources|NAME]] resource 3 contains the name of each external command: ''cmd'' is the corresponding NAME record index. See the [[Riven external commands|external command list]] for more info on external commands.

==Command 18: transition==
*'''Argument count:''' 1 or 5
*'''Arguments:''' ''code [left top right bottom]''

Schedule a transition effect described by ''code'' (see below for what code means). The transition will actually play when a display update occurs, for example with [[#Command 21: enable screen update|command 21]], [[#Command 39: activate PLST record|39]] or after going to another card (it doesn't seem to work for [[#Command 1: draw tBMP resource|command 1]], however). The optional 4 args ''left'', ''top'', ''right'', and ''bottom'' specify a clip rectangle in pixels, but are never really used in the game.

{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! code !! Effect
|-
|style="font-family:monospace"|0...15
|Scroll. Bits 0 and 1 control the direction (0=left, 1=right, 2=top, 3=bottom); bit 2 tells if the new image should move (1) or stay fixed (0); bit 3 tells if the old image should move or stay fixed.
|-
|style="font-family:monospace"|16||Dissolve.
|-
|style="font-family:monospace"|17||Seems to behave like 16, rare (t_Data, CARD 155).
|}

Note that Riven uses only transitions from 12 to 17; other effects were discovered by hacking scripts. Maybe there are more.

==Command 19: reload card==
*'''Argument count:''' 0

It's something like "refresh card": it acts like a "go to this card" command. Often used to update the card display after an hotspot script has altered a variable.

==Command 20: disable screen update==
*'''Argument count:''' 0

This seems to disable the automatic display update for commands [[#Command 1: draw tBMP resource|1]] and [[#Command 39: activate PLST record|39]]. It doesn't work like a "toggle" command: using it multiple times won't re-enable the automatic update (it is re-enabled by command 21 instead). Its effect persists even after the script ends (extending to any successive script, e.g. hotspot ones) but is reset on card switches. Command 20 often precedes [[#Command 18: transition|command 18]].

==Command 21: enable screen update==
*'''Argument count:''' 0

This seems the opposite of [[#Command 20: disable screen update|command 20]]: it re-enables the automatic display update for commands [[#Command 1: draw tBMP resource|1]] and [[#Command 39: activate PLST record|39]], triggers [[#Handlers|event 10]], updates the display and plays the transition effect if one was scheduled before.

Command 21 shows inconsistent behavior if used alone (sometimes it updates the display, sometimes it doesn't, sometimes it skips the transition, etc.); the correct way of using commands 20 and 21 seems to be the following construct, which is also what is usually found in scripts:
#disable screen update
#schedule transition
#activate [[PLST]] records / draw [[tBMP]] resources
#enable screen update

This construct will compose a final picture (by overlaying the specified PLST records and tBMP bitmaps, in the same order as they appear in the script) and then play the specified transition effect from the previously displayed picture to the new one. Note that such a complex effect wouldn't be possible without commands 20/21.

==Command 24: increment variable==
*'''Argument count:''' 2
*'''Arguments:''' ''var value''

Add ''value'' to variable ''var''.

==Command 27: go to stack==
*'''Argument count:''' 3
*'''Arguments:''' ''stack_name code_hi code_lo''

Go to another stack. The destination stack is specified by ''stack_name''; you get the actual stack name string by looking up record ''stack_name'' in [[Riven NAME resources|NAME]] resource 5. The destination card is specified through ''code_hi'' (higher 16 bytes) and ''code_lo'' (lower 16 bytes) which together form an unsigned long [[Riven RMAP resources|RMAP]] card code.

==Command 28==
*'''Argument count:''' 1
*'''Arguments:''' ''code''

Unknown. It should have something to do with movies: it comes almost always after [[#Command 32: play foreground movie|command 32]] with the same argument. However, changing code or even removing the command itself seem to have no effect neither on the movie nor on anything else. Maybe it purges the memory used by the movie or something like that.

==Command 29==
*'''Argument count:''' 0

Unknown. Seems related to movies since in most cases it comes after [[#Command 32: play foreground movie|command 32]]. Used quite rarely.
==Command 31==
*'''Argument count:''' 1
*'''Arguments:''' ''code''

Unknown. Should have something to do with movies, it comes often before [[#Command 33: play background movie|command 33]] with the same argument. Changing code seems to have no effect.

==Command 32: play foreground movie==
*'''Argument count:''' 1
*'''Arguments:''' ''code''

Play a movie listed in the [[Riven MLST resources|MLST]] resource, blocking the script execution until movie ends. code matches the code field of the MLST record that should be played. The MLST record must be first enabled with [[#Command 46: activate MLST record|command 46]], otherwise some other random movie will play instead (or nothing will happen at all). If multiple records have that code value, one will be chosen randomly, I guess. Sometimes this command follows [[#Command 33: play background movie|command 33]] with the same parameter: probably it just means "wait until the movie ends" in that case.

==Command 33: play background movie==
*'''Argument count:''' 1
*'''Arguments:''' ''code''

Start a "background" movie from [[Riven MLST resources|MLST]] record with specified code. Script execution will go on (and eventually terminate) while the movie is playing. Often this command follows [[#Command 31|command 31]]. The MLST record must be first enabled with [[#Command 46: activate MLST record|command 46]], otherwise some other random movie will play instead.

==Command 34==
*'''Argument count:''' 1
*'''Arguments:''' ''u0''

Unknown. ''u0'' is always 1.

==Command 36==
*'''Argument count:''' 0

Unknown.

==Command 37==
*'''Argument count:''' 0

Unknown.

==Command 38==
*'''Argument count:''' 5
*'''Arguments:''' ''u1 u2 u3 u4 u5''

Unknown, but should have something to do with movies. ''u1'' seems to refer to a [[Riven MLST resources|MLST]] record code, ''u5'' seems to be a [[Riven SLST resources|SLST]] record index and ''u4'' seems always 40. ''u2'' and ''u3'' seem to form a 32-bit value set to large numbers (4000, 9000...), which I suspect are milliseconds.

This command seems to perform complex actions: if ''u4'' is changed to 0, ''u5'' is interpreted instead as a [[Riven tBMP resources|tBMP]] resource ID and that bitmap is drawn right after the movie.

==Command 39: activate PLST record==
*'''Argument count:''' 1
*'''Arguments:''' ''record''

Activate the specified record in the [[Riven PLST resources|PLST]] resource, making one of the card bitmaps visible. The actual screen update takes place immediately (with a transition effect, if one was scheduled before) unless [[#Command 20: disable screen update|command 20]] was used before or the command is called from [[#Handlers|handlers 6 or 10]].

==Command 40: activate SLST record==
*'''Argument count:''' 1
*'''Arguments:''' ''record''

Activate the specified [[Riven SLST resources|SLST]] record, so start ambient sounds. This command seems to have effect just once: it won't restart the same sound if it is already playing (even if the SLST tells not to repeat it). Activating another SLST record works always: the current sound is then stopped and replaced with the new one.

==Command 41==
*'''Argument count:''' 1
*'''Arguments:''' ''u0''

Unknown. Should have something to do with movies because it comes often before [[#Command 32: play foreground movie|command 32]] with the same argument. A hypothesis is that it activates a [[Riven MLST resources|MLST]] record like [[#Command 46: activate MLST record|46]], but using its code field rather than the MLST record index.
==Command 43: activate BLST record==
*'''Argument count:''' 1
*'''Arguments:''' ''record''

Activate the specified record in the [[Riven BLST resources|BLST]] resource, so enable or disable one of the card hotspots (depending on the record info).

==Command 44: activate FLST record==
*'''Argument count:''' 1
*'''Arguments:''' ''record''

Activate the specified record in the [[Riven FLST resources|FLST]] resource, so enable a realtime [[Riven SFXE resources|SFXE]] effect.

==Command 45: do zip mode==
*'''Argument count:''' 0

Find the correct [[Riven ZIPS resources|ZIPS]] record using the hotspot name, get the destination card from the found record and go to that card. Though likely, this behavior has not been confirmed yet.

==Command 46: activate MLST record==
*'''Argument count:''' 2
*'''Arguments:''' ''record u0''

Activate the specified record in the [[Riven MLST resources|MLST]] resource. This command won't actually start the movie; it will only "enable" it for later playing. ''u0'' seems 0 or 1 if the movie is to be played once or looped forever, respectively. This is redundant, since the same info can be found in the MLST record; moreover, ''u0'' seems to be ignored by the engine.

Riven HSPT resources

2008-02-18T01:36:33Z

Di gama: adjustments

<noinclude>{{Riven}}</noinclude>
These contain hotspots, sort of invisible buttons within cards that respond to mouse clicks (and other events) by performing actions described by attached scripts.

Each HSPT resource is a list of records and starts with an unsigned short equal to the number of records. Due to the attached scripts, HSPT records can have different size and there is no way to know it without fully decoding the record. Each record has the following structure:

{| class="structure"
|unsigned short||blst_id||class="comment"|Links the hotspot to a BLST resource record
|-
|short||name_rec||class="comment"|If ≥ 0, record index in [[Riven NAME resources|NAME]] resource 2 to provide a name for the hotspot
|-
|short||left||class="comment" rowspan=4|Hotspot rectangle within the game window, in pixels
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|unsigned short||u0||
|-
|unsigned short||mouse_cursor||class="comment"|Cursor icon to set when the mouse rolls over this hotspot
|-
|unsigned short||index||class="comment"|Record index starting from 1
|-
|short||u1||
|-
|unsigned short||u2||
|-
|variable size||script||
|}

[[Image:Cursors.png|right|frame|Riven cursor icons and their IDs]]

Hotspot rectangles can fall outside the game window (in any direction) and often two or more hotspots overlap. There are even cases with ''left'' > ''right'' (card 371, t_Data). When more hotspots overlap, the hotspot "on top" is the one with the largest ''index'' value.

Cursor icon values are listed on the right.

''u0'' seems always zero and changing it seems to leave Riven indifferent. ''u1'' is very very often -1 but not always. ''u2'' is 0 for ordinary hotspots, 1 for Zip Mode ones: the engine disables all Zip Mode hotspots when Zip Mode is off.

For info on the attached script see the [[Riven scripts|scripts section]].

Template:Myst

2008-02-12T23:04:29Z

Di gama: same here

{| class="toc" align="right" border="0" cellpadding="2" style="text-align:center"
|colspan=4|'''<big>Myst</big>'''
|-
|colspan=2|[[Mohawk archive format|Mohawk]]
|colspan=2|[[Myst resources|Other]]
|-
|[[Myst CLRC resources|CLRC]]
|[[Myst EXIT resources|EXIT]]
|[[Myst HINT resources|HINT]]
|[[Myst INIT resources|INIT]]
|-
|[[Myst MJMP resources|MJMP]]
|[[Myst MSND resources|MSND]]
|[[Myst PICT resources|PICT]]
|[[Myst RLST resources|RLST]]
|-
|[[Myst VIEW resources|VIEW]]
|[[Myst WDIB resources|WDIB]]
|colspan=2|[[Myst variables|Variables]]
|}

Template:Riven

2008-02-12T23:03:54Z

Di gama: turns out the reason the tocToggle was broken was there was another element with id="toc". fixing.

{| class="toc" align="right" border="0" cellpadding="2" style="text-align:center"
|colspan=4|'''<big>Riven</big>'''
|-
|colspan=2|[[Mohawk archive format|Mohawk]]
|colspan=2|[[Riven engine overview|Overview]]
|-
|[[Riven BLST resources|BLST]]
|[[Riven CARD resources|CARD]]
|[[Riven FLST resources|FLST]]
|[[Riven HSPT resources|HSPT]]
|-
|[[Riven MLST resources|MLST]]
|[[Riven NAME resources|NAME]]
|[[Riven PLST resources|PLST]]
|[[Riven RMAP resources|RMAP]]
|-
|[[Riven SFXE resources|SFXE]]
|[[Riven SLST resources|SLST]]
|[[Riven tBMP resources|tBMP]]
|[[Riven tMOV resources|tMOV]]
|-
|[[Riven tWAV resources|tWAV]]
|[[Riven VARS resources|VARS]]
|[[Riven VERS resources|VERS]]
|[[Riven ZIPS resources|ZIPS]]
|-
|colspan=2|[[Riven scripts|Scripts]]
|colspan=2|[[Riven variables|Variables]]
|-
|colspan=4|[[Riven external commands|External commands]]
|}

MediaWiki:Sidebar

2008-02-12T22:25:39Z

Di gama: customized sidebar (Note: I have removed the comm. portal; we may need it in the future, but not at the moment)

Riven engine overview

2008-02-12T22:06:21Z

Di gama: the stack switching notes have to go somewhere, if not the 'other' page

A Riven scenario is made of virtual objects called ''stacks'' and each stack is a list of virtual objects called ''cards''. This may remember HyperCard: it's the same approach. Each card has an associated ''script'', a sequence of commands to be executed in response of events happening to the card (for example, card creation). The player interacts with the game by means of invisible buttons, placed within cards and called ''hotspots''. Hotspots have associated scripts too, responding to events different than cards (for example, mouse clicks). Within cards can also be placed bitmaps and movies. Finally, sounds can be played.

Riven stacks are named
*aspit (main menu, books, setup screens)
**a_Data.mhk
**a_Sounds.mhk
*ospit (Gehn's office)
**o_Data.mhk
**o_Sounds.mhk
*pspit (prison island)
**p_Data.mhk
**p_Sounds.mhk
*gspit (garden island)
**g_Data.mhk
**g_Sounds.mhk
*rspit (rebel age)
**r_Data.mhk
**r_Sounds.mhk
*tspit (temple island).
**t_Data.mhk (Riven 5CD)
**t_Data1.mhk, t_Data2.mhk (Riven DVD)
**t_Sounds.mhk
*jspit (jungle island)
**j_Data1.mhk
**j_Data2.mhk
**j_Sounds.mhk
*bspit (boiler island)
**b_Data.mhk
**b_Sounds.mhk

Physically, a stack is described by a set of data blocks called ''resources''. Resources are identified by a 4-char ''type'' and an integer ''ID''. Optionally they can also have a name, but it seems completely ignored by the engine. The resource type tells what kind of data is stored in the resource; see the [[Riven_resources|resource type list]] for types used in Riven.

Resources belonging to a certain stack are archived inside an arbitrary number of [[Mohawk_archive_format|Mohawk files]] (listed above under their respective stacks). The file "riven.cfg" tells which files compose each stack by associating stack and file names.

Saved games are Mohawk archives too, and they contain additional resource types as described in the [[Riven_resources|resource type list]].

==Notes on stack switching==
The current stack can be changed from scripts using [[Riven scripts#Command 27: go to stack|script command 27]]. For example, when the player activates a MagLev, first the car movie is played, and then command 27 is called to change the current stack to the new island. This command is also used in the "Play Riven" button. However, most linking books actually change stack simply by moving to another card which has no buttons and no scripts. Apparently, there is some hardcoded mechanism inside the engine which triggers the stack change when one of these "special" cards is entered. These cards are listed here.
{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Stack !! Card ID !! Target stack !! Target card
|-
|bspit||447||ospit||1
|-
|gspit||178||ospit||1
|-
|jspit||228||rspit||3
|-
|jspit||344||ospit||1
|-
|ospit||58||pspit||43
|-
|ospit||62||jspit||341
|-
|ospit||67||gspit||175
|-
|ospit||72||bspit||444
|-
|ospit||76||tspit||387
|-
|pspit||46||ospit||1
|-
|rspit||13||jspit||215
|-
|tspit||392||ospit||1
|}

A look inside The Link @ wiki:About

2008-02-12T21:44:08Z

Di gama: /* Who contributed? */ we can't have unattributed work! :-)

Some info is needed about the project itself. This page reports a bit of history and lists people who contributed to make the project possible.

== Why such an effort? ==
''For fun''. The so-called ''reverse engineering'' can turn huge amounts of brain work into huge amounts of satisfaction (in a way similar to science, if you like). You start with just a big file, knowing almost nothing about it, and eventually you have an almost complete description of its structure, coming just from observation and reasoning. Like science, it's a challenge: a way of proving the power of our mind. When I completely decoded SFXE resources, which were originally unknown in both ''format'' and ''purpose'', people thought I had gone mad. I was running everywhere and telling everyone "Hey, I've decoded SFXEs!".

Another reason is allowing people to extend the Riven experience to other platforms and operating systems. At the beginning I was far from seeing this as a serious reason, it was more like a dream; but as fields and structures were decoded, I started wondering if someone had noticed my efforts and exploited them for porting Riven to other platforms. Eventually, it happened with two projects: Fissure and Riven X.

== How was it performed? ==
Hmm, quite a difficult question. First of all, you have to be extremely ''calm'' and ''relaxed''...

Seriously, I first made some guesses and hypoteses based on the type of game and what I already knew about Myst: the data files were probably some sort of archives containing game pieces, so the goal was un-archiving them. I first directed my efforts toward understanding [[Mohawk archive format|Mohawk archives]]. I did hex dumps of the smaller data files, printed pages and pages and carefully searched the numbers for any possible pattern. I finally managed to write a small program to "unroll" Mohawk archives and reveal their content, which was a bunch of "resources". Each resource was identified by a 4-char type, an integer ID and optionally a name. An approach very similar to old MacOS resources. These resources were the pieces of the game: pictures, movies, sounds, unknown data. They were mostly encoded in proprietary formats, so I had to start again with the research: make hex dumps, print, analyze and search for patterns, for every resource type. For example, in pictures I first looked for values matching the bitmap dimensions, while in sounds I looked for common sample rate values like 44100. Decoding resources like SFXE and RMAP also involved understanding what the resource contained; I guessed this by observing the context in which these resources were invoked. With new info constantly coming in and so many resource types to handle, at some point I decided to make some order in my head, pause the research and write a big Mohawk archive browser, a program with a nice graphical interface to explore Mohawk files "by click" and, more important, test whether hypotetic data structures really matched all of the available data. It was a good idea and greatly speeded up further research.

More or less, the decoding process can always be viewed as an initial observation of the numbers, formulation of hypotetic data structures and creation of test programs to match the data structures to all available data. If even a single mismatch is found, the data structure has to be reviewed. Clearly, some of the steps can be skipped when you already have enough information. Another useful approach is brutally altering the data and then running the original game engine to see what happens. However this is like bruteforcing and is only useful to provide hints when you are really desperate about a single unknown field. If you alter something you know nothing about, you'll mostly get a hard, spectacular crash filling the screen with random pixels.

As for the tools, the whole thing has been performed on Linux, using mainly hexdump, hexedit and the good compiler gcc. I used MPlayer to watch tMOV resources and Baudline to check decoded tWAV audio signals.

== Who contributed? ==
I didn't decode everything [[User:TitoDalCanton|myself]], and I want to thank people who contributed. Gabriel Bauman figured out most of the Mohawk archive format when I was still enjoying the game, and then founded the Fissure port; his work was my initial inspiration. Arthur Muller provided an immense help by understanding tBMP compression after my vain efforts. Ron Hayter provided details on the DVD version of tWAV resources. [[User:BahamutZERO|Jean-Francois Roy]], author of Riven X, constantly keeps my interest active and provides reasons to go on. [[User:Di_gama|Mario Carneiro]] was the one that definitely convinced me to port the original documentation to this wiki, and he is contributing to the Myst research. Many thanks to all!

Riven ZIPS resources

2008-02-12T21:40:01Z

Di gama: it is helpful to put at least one link to the CARD resource here

Found only in saved games, this resource contains a list of visited locations to support the "Zip Mode". It starts with an unsigned short telling how many records will follow. Then, each record contains the following data:

{| class="structure"
|unsigned short||name_len
|-
|char||name[name_len]
|-
|unsigned short||card_id
|}

Each record is linked to a [[CARD|card]]: ''card_id'' tells its ID, and ''name'' is equal to the card name. Zip Mode hotspots share the same name, so when they are clicked the target card ID can be known by looking up in the ZIPS. If the user already visited that card, the record will be there and the hotspot will be able to go to that card.

Riven FLST resources

2008-02-12T20:18:11Z

Di gama: confirmed behavior

<noinclude>{{Riven}}</noinclude>
They seem to specify which [[SFXE]] resource each card must use.

Each FLST resource is a list of records; it starts with an unsigned short record count, followed by that many records. The record size is 6 bytes:

{| class="structure"
|unsigned short||index||class="comment"|Record index, starting from 1
|-
|unsigned short||sfxe_id||class="comment"|Resource ID of the corresponding [[SFXE]]
|-
|unsigned short||u0||
|}

''u0'' is always zero. Changing it seems to have no effect.

FLST resources are very often empty (meaning no SFXE for that card) or with just one record.

ZIPS

2008-02-11T20:14:56Z

Di gama: redir

#REDIRECT [[Riven ZIPS resources]]

VERS

2008-02-11T20:14:34Z

Di gama: redir

#REDIRECT [[Riven VERS resources]]

VARS

2008-02-11T20:14:08Z

Di gama: redir

#REDIRECT [[Riven VARS resources]]

TWAV

2008-02-11T20:13:41Z

Di gama: redir

#REDIRECT [[Riven tWAV resources]]

TMOV

2008-02-11T20:13:15Z

Di gama: redir

#REDIRECT [[Riven tMOV resources]]

TBMP

2008-02-11T20:12:44Z

Di gama: redir

#REDIRECT [[Riven tBMP resources]]

SLST

2008-02-11T20:12:18Z

Di gama: redir

#REDIRECT [[Riven SLST resources]]

SFXE

2008-02-11T20:11:56Z

Di gama: redir

#REDIRECT [[Riven SFXE resources]]

RMAP

2008-02-11T20:11:38Z

Di gama: redir

#REDIRECT [[Riven RMAP resources]]

PLST

2008-02-11T20:11:10Z

Di gama: redir

#REDIRECT [[Riven PLST resources]]

NAME

2008-02-11T20:10:48Z

Di gama: redir

#REDIRECT [[Riven NAME resources]]

MLST

2008-02-11T20:10:26Z

Di gama: redir

#REDIRECT [[Riven MLST resources]]

HSPT

2008-02-11T20:10:01Z

Di gama: redir

#REDIRECT [[Riven HSPT resources]]

FLST

2008-02-11T20:09:29Z

Di gama: redir

#REDIRECT [[Riven FLST resources]]

CARD

2008-02-11T20:07:37Z

Di gama: redir

#REDIRECT [[Riven CARD resources]]

BLST

2008-02-11T20:07:11Z

Di gama: redir

#REDIRECT [[Riven BLST resources]]

Riven tMOV resources

2008-02-11T20:06:18Z

Di gama: stubbed

<noinclude>{{Riven}}</noinclude>
This resource seems to be just an Apple QuickTime MOV format movie, so it is in their proprietary format.

Myst resources

2008-02-06T12:45:09Z

Di gama: /* VIEW */ I'LL FIX IT LATER

{{Myst}}
This page contains or will contain a comprehensive analysis of the 8 resources in Myst (and the two added in Myst ME).

Both Myst and Myst ME use little-endian byte order in the files (by contrast to the big-endian byte order used in Riven and the Mohawk format), although the data itself is stored in properly formatted Mohawk format (don't let the .dni or .dat file extension fool you). The packages in Myst ME are:
*CHANNEL
*CREDITS
*DUNNY
*INTRO
*MECHAN
*MYST
*SELEN
*STONE
*SYSTEM
The resources are on the left (MJMP and PICT are new in ME). None of the resources are named except for the MSND/MJMP resources.

==CLRC==
All CLRC resources follow the pattern:
{| class="structure"
|short||u1
|-
|short||u2
|}
*''u1'' and ''u2'' are both 1, 6, 7, 8, 9, or 14 for all files

==EXIT==
I think these are variables, although that seems unlikely because SELEN has no EXIT resources.
<noinclude>===Case studies (all of them)===
Note: these are presented as ''resource_index''.''length short...'' where the data is broken into shorts and displayed in decimal.
====CHANNEL====
*0.12 1 0 300 0 0 1
====DUNNY====
*0.22 2 0 300 0 0 1 0 100 0 0 1
====INTRO====
*0.22 2 0 300 0 0 1 0 38 0 0 1
*1.12 1 0 38 0 0 1
====MECHAN====
*0.24 2 0 27 0 1 7044 1 0 4 0 0 1
*1.12 1 0 300 0 0 1
*2.12 1 0 32 0 0 1
====MYST====
*0.12 1 0 301 0 0 1
*1.12 1 0 301 0 0 1
*2.12 1 0 301 0 0 1
*3.12 1 0 301 0 0 1
*4.12 1 0 301 0 0 1
*5.12 1 1 306 0 0 1
*6.12 1 1 306 0 0 1
*7.12 1 0 302 0 0 1
*8.12 1 0 303 0 0 1
*9.12 1 0 303 0 0 1
*10.36 3 [0 1 302 1 1 1] [0 309 0 0 1 0] [1 309 1 0 1]
*11.12 1 0 307 0 0 1
*12.24 2 [0 300 100 0 2 0] [1 309 1 0 1]
*13.24 2 [0 300 101 0 2 0] [1 309 1 0 1]
*14.12 1 [0 303 0 0 1]
*15.14 1 0 308 0 0 1 0
*16.12 1 [0 304 0 0 1]
*17.12 1 [0 304 0 0 1]
*18.22 2 [0 304 0 0 1] [0 305 0 0 1]
*19.12 1 [1 304 0 0 1]
*20.22 2 [0 304 0 0 1] [0 305 0 0 1]
*21.12 1 [0 304 0 0 1]
*22.22 2 [0 304 0 0 1] [0 305 0 0 1]
*23.12 1 [0 304 0 0 1]
*24.12 1 [0 312 0 0 1]
*25.66
3 0 29 0 7 8708 0 0 152 165 198 107
1 0 42 0 9 8707 10 6 216 129 368 294
5 50 1 0 24 0 1 9707 1
====STONE====
*0.14 1 0 125 21 1 14 1
*1.14 1 0 125 21 1 13 1
*2.12 1 0 300 0 0 1

==INIT==
These are more likely variables. They do not have names like in Riven.
===Case studies===
====CHANNEL====
*0.12 1 0 1 30 1 0
*1.10 1 6 201 0 0
====DUNNY====
*1.18 2 0 26 0 0 0 200 0 0
====MYST====
*2.30 2 1 209 0 0 0 206 0 6 6044 7044 8044 9044 10044 11044
*4.18 1 0 205 0 4 6156 7156 8156 9156
*5.16 1 0 201 0 3 0 4 5
*6.12 1 0 204 0 1 6180

==HINT==
{| class="structure"
|short||rc||class="comment|record count
|}
*rc is wrong in:
**CHANNEL 78 231
**MECHAN 109
**MYST 2 28 38 43 45 49 106 109 149 150 173 175 206 231
**SELEN 172
**STONE 10 12 18 59 89 91 106
records are
{| class="structure"
|short||rid||class="comment|record index
|-
|short||u1||
|}
*the ''rid'''s start at zero and go up, but there are exceptions.
**CHANNEL 78 144 231
**DUNNY all minus 1 5 7 18 19
**MECHAN 109
**Myst 2 28 43 45 49 78 111 171 173 175 184 206 229 235
**STONE 10 12 18 59 89 91 106
*the ''u1'''s all appear to be one of 0, 2, 3, 200, 300, 400, 500, 600, 904, 905, 999, or FFFF (-1)

==MSND==
It is interesting to note that all MSND resources in the whole game are named except for INTRO 1 (the linking sound). In all the other packages, this sound is labeled "transprt7" (in MYST) or "transprt1" and "transprt2" (which all appear to be the same, although transprt1 and transprt2 are separate resources in the package).

==RLST and VIEW==
There are the same number of RLST and VIEW resources in all packages, which leads me to believe that they are locked together by index like HSPT and CARD resources in Riven.

===RLST===
I think these contain hotspot data (i.e. HSPT).

{| class="structure"
|short||count_of_records
|}
====record type 1====
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF
*this replaces part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere)
====record type 2: (simple hotspot)====
{| class="structure"
|short||dir 1=left, 2=right, 5=forward
|-
|short||type=2
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|short||destination
|}

====Case studies====
(Note: these are simply the data in (little-endian) shorts and line-broken where I saw patterns. <l t b r> are (I think) areas on-screen. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).)
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 (the door)
2 6 0 0 24 0 1 3494
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5
1 3 <103 1 802 103> 2 3013 <0 0 113 100> 3012 FFFF
5 2 <255 193 269 208> 0 1 117 0 1 0
5 2 <268 193 282 208> 0 1 117 0 1 1
5 2 <281 193 295 208> 0 1 117 0 1 2
5 2 <294 193 308 208> 0 1 117 0 1 3
8 1 <252 190 310 210> 0 FFFF 0 17 4
[3008 <0 0 58 20>]
[3009 <0 0 58 20>]
[3010 <0 0 58 20>]
[3011 <0 0 58 20>]
0 4
<180 31 379 305> 0 5 2
<0 0 544 332> 0 1 34
0 2 3005 0

(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 [5 1 3 103 1 802] 103 2 FFFF FFFF 4369 <0 0 70 90>
7 2 <216 110 304 235> 0 106 5 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
0 0 2 0 0 544 332 4345

===VIEW===
image name and sub-images (akin to Riven PLSTs)
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse"
|0||0||3001||-1||0/0||3001||3001||0||0
|-
| || ||name||neg.||bytes||colspan=4|(name name 0 0)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse"
|0||0||3002||-2||0/144||0|| ||3002||3002||0||0
|-
|0||0||3003||-2||0/144||1||[1 3004]||3003||3003||0||0
|-
| || ||name||?|| ||count||entry||colspan=4|(name name 0 0)
|}
*I think ''3004'' is the name of a sub-image (small image to be placed in another) of ''3003'' here.
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse"
|0||0||3005||3005||0/144||1||[1 3006]||3005||3005||0||0
|-
| || ||colspan=2|name twice|| || ||colspan=4|(name name 0 0)
|}
{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse"
|0||0||3012||-2||0/50||5||[1 3013]||[1 3008]||[1 3009]||[1 3010]||[1 3011]||3012||0||0||3012
|-
| || ||name||?|| ||count||colspan=5|entries||colspan=4|(name 0 0 name)
|}

{| cellpadding=2 style="border:1px #000 solid;border-collapse:collapse"
! 14||1||1||5||2||3030||3031||FFFC 3 2 3031 00_A0||4031||x00A0||2||2||4030||1 3030|| || ||3031||3031||0||0
! 44||1||1||2||2||3095||3096||FFFC 15 2 3095 00_A0||4095||x00A0||4||2 4095||1 3562||1 3097||2 5095||3095||3095||3095||0
*348||1||1||16||2||3536||3535|| ||3535||x0060||0|| || || || ||3535||3535||0||0
*359||1||1||5||2||3550||3552||FFFC 3 2 6552 00_80 3552||x0080||4||4 3550||4 3552||2 4552||2 5552||3552||3552||0||0
*47||1||1||10||2||4140||4141|| ||5141||x0090||1||2 4141|| || || ||4141||4141||4141||4141
*50||1||1||10||2||4148||4149|| ||4149||x0090||0|| || || || ||4149||4149||4149||0
*51||1||1||10||2||4150||4151|| ||FFFE||x0070||0|| || || || ||4150||4150||0||0
*94||1||1||10||2||4243||4244|| ||4244||x0050||0|| || || || ||4244||4244||0||0
*116||1||1||40||2||4292||4294||FFFC 40 2 4292 00_50 4292||x0060||2||1 4293||2 5292|| || ||4292||4292||0||0
*145||1||1||0||2||4358||4357|| ||FFFE||x0030||0|| || || || ||4357||4357||0||0
*287||1||1||34||3||4698||4701|| ||4702||xFFFD||4||1 4699||2 4698||2 5698||2 6698||4698||4698||4698||4698
*295||1||1||10||2||4717||4719|| ||4717||x0040||1||1 4718|| || || ||4717||4717||0||0

Myst resources

2008-02-06T11:48:38Z

Di gama: touching up (not done)

{{Myst}}
This page contains or will contain a comprehensive analysis of the 8 resources in Myst (and the two added in Myst ME).

Both Myst and Myst ME use little-endian byte order in the files (by contrast to the big-endian byte order used in Riven and the Mohawk format), although the data itself is stored in properly formatted Mohawk format (don't let the .dni or .dat file extension fool you). The packages in Myst ME are:
*CHANNEL
*CREDITS
*DUNNY
*INTRO
*MECHAN
*MYST
*SELEN
*STONE
*SYSTEM
The resources are on the left (MJMP and PICT are new in ME). None of the resources are named except for the MSND/MJMP resources.

==CLRC==
All CLRC resources follow the pattern:
{| class="structure"
|short||u1
|-
|short||u2
|}
*''u1'' and ''u2'' are both 1, 6, 7, 8, 9, or 14 for all files

==EXIT==
I think these are variables, although that seems unlikely because SELEN has no EXIT resources.
<noinclude>===Case studies (all of them)===
Note: these are presented as ''resource_index''.''length short...'' where the data is broken into shorts and displayed in decimal.
====CHANNEL====
*0.12 1 0 300 0 0 1
====DUNNY====
*0.22 2 0 300 0 0 1 0 100 0 0 1
====INTRO====
*0.22 2 0 300 0 0 1 0 38 0 0 1
*1.12 1 0 38 0 0 1
====MECHAN====
*0.24 2 0 27 0 1 7044 1 0 4 0 0 1
*1.12 1 0 300 0 0 1
*2.12 1 0 32 0 0 1
====MYST====
*0.12 1 0 301 0 0 1
*1.12 1 0 301 0 0 1
*2.12 1 0 301 0 0 1
*3.12 1 0 301 0 0 1
*4.12 1 0 301 0 0 1
*5.12 1 1 306 0 0 1
*6.12 1 1 306 0 0 1
*7.12 1 0 302 0 0 1
*8.12 1 0 303 0 0 1
*9.12 1 0 303 0 0 1
*10.36 3 [0 1 302 1 1 1] [0 309 0 0 1 0] [1 309 1 0 1]
*11.12 1 0 307 0 0 1
*12.24 2 [0 300 100 0 2 0] [1 309 1 0 1]
*13.24 2 [0 300 101 0 2 0] [1 309 1 0 1]
*14.12 1 [0 303 0 0 1]
*15.14 1 0 308 0 0 1 0
*16.12 1 [0 304 0 0 1]
*17.12 1 [0 304 0 0 1]
*18.22 2 [0 304 0 0 1] [0 305 0 0 1]
*19.12 1 [1 304 0 0 1]
*20.22 2 [0 304 0 0 1] [0 305 0 0 1]
*21.12 1 [0 304 0 0 1]
*22.22 2 [0 304 0 0 1] [0 305 0 0 1]
*23.12 1 [0 304 0 0 1]
*24.12 1 [0 312 0 0 1]
*25.66
3 0 29 0 7 8708 0 0 152 165 198 107
1 0 42 0 9 8707 10 6 216 129 368 294
5 50 1 0 24 0 1 9707 1
====STONE====
*0.14 1 0 125 21 1 14 1
*1.14 1 0 125 21 1 13 1
*2.12 1 0 300 0 0 1

==INIT==
These are more likely variables. They do not have names like in Riven.
===Case studies===
====CHANNEL====
*0.12 1 0 1 30 1 0
*1.10 1 6 201 0 0
====DUNNY====
*1.18 2 0 26 0 0 0 200 0 0
====MYST====
*2.30 2 1 209 0 0 0 206 0 6 6044 7044 8044 9044 10044 11044
*4.18 1 0 205 0 4 6156 7156 8156 9156
*5.16 1 0 201 0 3 0 4 5
*6.12 1 0 204 0 1 6180

==HINT==
{| class="structure"
|short||rc||class="comment|record count
|}
*rc is wrong in:
**CHANNEL 78 231
**MECHAN 109
**MYST 2 28 38 43 45 49 106 109 149 150 173 175 206 231
**SELEN 172
**STONE 10 12 18 59 89 91 106
records are
{| class="structure"
|short||rid||class="comment|record index
|-
|short||u1||
|}
*the ''rid'''s start at zero and go up, but there are exceptions.
**CHANNEL 78 144 231
**DUNNY all minus 1 5 7 18 19
**MECHAN 109
**Myst 2 28 43 45 49 78 111 171 173 175 184 206 229 235
**STONE 10 12 18 59 89 91 106
*the ''u1'''s all appear to be one of 0, 2, 3, 200, 300, 400, 500, 600, 904, 905, 999, or FFFF (-1)

==MSND==
It is interesting to note that all MSND resources in the whole game are named except for INTRO 1 (the linking sound). In all the other packages, this sound is labeled "transprt7" (in MYST) or "transprt1" and "transprt2" (which all appear to be the same, although transprt1 and transprt2 are separate resources in the package).

==RLST and VIEW==
There are the same number of RLST and VIEW resources in all packages, which leads me to believe that they are locked together by index like HSPT and CARD resources in Riven.

===RLST===
I think these contain hotspot data (i.e. HSPT).

{| class="structure"
|short||count_of_records
|}
====record type 1====
8 1 < 31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF
*this replaces part of the image (in this case <417 260 544 333>) with part of another image (in this case 3004 <0 0 127 73>) based on a variable (103 2 plays in here somewhere)
====record type 2: (simple hotspot)====
{| class="structure"
|short||dir 1=left, 2=right, 5=forward
|-
|short||type=2
|-
|short||left
|-
|short||top
|-
|short||right
|-
|short||bottom
|-
|short||destination
|}

====Case studies====
(Note: these are simply the data in (little-endian) shorts and line-broken where I saw patterns. <l t b r> are (I think) areas on-screen. count [entry]... are guesses at when there are lists of entries. The number in parentheses before the data is the card number (not the resource number).)
(CHANNEL 3001) 2
1 2 <1 0 110 332> 3002
2 2 <455 2 544 332> 3003

(CHANNEL 3002) 2
1 2 <0 1 100 332> 3005
2 2 <431 0 544 332> 3001

(CHANNEL 3003) 4
5 2 <213 90 343 290> 3494 (the door)
2 6 0 0 24 0 1 3494
1 2 <0 0 81 332> 3001 (left)
2 2 <463 0 544 332> 3005 (right)
8 1 <417 260 544 333> 0 FFFF 0 103 2 3004 <0 0 127 73> 3003 FFFF

(CHANNEL 3005) 4
0 2 <76 152 196 330> 3012
1 2 <0 0 106 332> 3003
2 2 <438 0 544 332> 3002
8 1 <31 276 163 333> 0 FFFF 0 103 2 3006 <0 0 132 57> 3005 FFFF

(CHANNEL 3012) 8
8 3 <101 243 214 343> 0 FFFF 1 5
1 3 <103 1 802 103> 2 3013 <0 0 113 100> 3012 FFFF
5 2 <255 193 269 208> 0 1 117 0 1 0
5 2 <268 193 282 208> 0 1 117 0 1 1
5 2 <281 193 295 208> 0 1 117 0 1 2
5 2 <294 193 308 208> 0 1 117 0 1 3
8 1 <252 190 310 210> 0 FFFF 0 17 4
[3008 <0 0 58 20>]
[3009 <0 0 58 20>]
[3010 <0 0 58 20>]
[3011 <0 0 58 20>]
0 4
<180 31 379 305> 0 5 2
<0 0 544 332> 0 1 34
0 2 3005 0

(MYST 4368) 3
8 3 <305 148 375 238> 0 FFFF 1 [5 1 3 103 1 802] 103 2 FFFF FFFF 4369 <0 0 70 90>
7 2 <216 110 304 235> 0 106 5 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
1 115 101 3 4741 4370 4368 5
0 0 2 0 0 544 332 4345

===VIEW===
image name and sub-images (akin to Riven PLSTs)
{| border=1 style="border-collapse:collapse"
|0||0||3001||-1||0/0||3001||3001||0||0
|-
| || ||name||neg.||bytes||colspan=4|(name name 0 0)
|}

{| border=1 style="border-collapse:collapse"
|0||0||3002||-2||0/144||0|| ||3002||3002||0||0
|-
|0||0||3003||-2||0/144||1||[1 3004]||3003||3003||0||0
|-
| || ||name||?|| ||count||entry||colspan=4|(name name 0 0)
|}
*I think ''3004'' is the name of a sub-image (small image to be placed in another) of ''3003'' here.
{| border=1 style="border-collapse:collapse"
|0||0||3005||3005||0/144||1||[1 3006]||3005||3005||0||0
|-
| || ||colspan=2|name twice|| || ||colspan=4|(name name 0 0)
|}
0 0 3012 -2 0/50 5 [1 3013] [1 3008] [1 3009] [1 3010] [1 3011] 3012 0 0 3012
name ? | ------ ------ ------ ------ ------(name 0 0 name)
count entries

*14 1 1 5 2 3030 3031 FFFC 3 2 3031 00_A0 4031 x00A0 2 2 4030 1 3030 3031 3031 0 0
*44 1 1 2 2 3095 3096 FFFC 15 2 3095 00_A0 4095 x00A0 4 2 4095 1 3562 1 3097 2 5095 3095 3095 3095 0
*348 1 1 16 2 3536 3535 3535 x0060 0 3535 3535 0 0
*359 1 1 5 2 3550 3552 FFFC 3 2 6552 00_80 3552 x0080 4 4 3550 4 3552 2 4552 2 5552 3552 3552 0 0
*47 1 1 10 2 4140 4141 5141 x0090 1 2 4141 4141 4141 4141 4141
*50 1 1 10 2 4148 4149 4149 x0090 0 4149 4149 4149 0
*51 1 1 10 2 4150 4151 FFFE x0070 0 4150 4150 0 0
*94 1 1 10 2 4243 4244 4244 x0050 0 4244 4244 0 0
*116 1 1 40 2 4292 4294 FFFC 40 2 4292 00_50 4292 x0060 2 1 4293 2 5292 4292 4292 0 0
*145 1 1 0 2 4358 4357 FFFE x0030 0 4357 4357 0 0
*287 1 1 34 3 4698 4701 4702 xFFFD 4 1 4699 2 4698 2 5698 2 6698 4698 4698 4698 4698
*295 1 1 10 2 4717 4719 4717 x0040 1 1 4718 4717 4717 0 0

Template:Myst

2008-02-06T04:00:33Z

Di gama: oops

{| id="toc" align="right" border="0" cellpadding="2" style="text-align:center"
|colspan=4|'''<big>Myst</big>'''
|-
|colspan=2|[[Mohawk archive format|Mohawk]]
|colspan=2|[[Myst resources|Other]]
|-
|[[Myst CLRC resources|CLRC]]
|[[Myst EXIT resources|EXIT]]
|[[Myst HINT resources|HINT]]
|[[Myst INIT resources|INIT]]
|-
|[[Myst MJMP resources|MJMP]]
|[[Myst MSND resources|MSND]]
|[[Myst PICT resources|PICT]]
|[[Myst RLST resources|RLST]]
|-
|[[Myst VIEW resources|VIEW]]
|[[Myst WDIB resources|WDIB]]
|colspan=2|[[Myst variables|Variables]]
|}

Mohawk archive format

2008-02-06T04:00:05Z

Di gama: TOC

{{Riven}}
{{Myst}}
==General layout==
Mohawk archives are organized in chunks, and this is the chunk layout:
* IFF chunk
** IFF header
** RSRC header
** Resource dir
*** Type table
*** Name tables (one for each resource type)
*** Resource tables (one for each resource type)
*** Resource name list
*** File table
** Actual data (resource contents)
Note that the chunks may be found in a different order: never trust on them being at fixed locations, and use the offsets to reach them.

Every integer is in big-endian (Motorola) byte order.

==IFF header==
This is always at the beginning of the file.
{| class="structure"
|4 bytes||chunk signature (MHWK), identifies Mohawk archive format
|-
|unsigned long||file size in bytes, '''not''' counting this IFF header (that is, file size - 8)
|}

==RSRC header==
I think this is actually the "Resource Dir header". Note that the Dir can be anywhere in file, but this header always follows the IFF Header.
{| class="structure"
|4 bytes||chunk signature (RSRC)
|-
|unsigned long||should be length of RSRC chunk (never bothered to check)
|-
|unsigned long||total file size in bytes
|-
|unsigned long||absolute offset of the Resource Dir
|-
|unsigned short||offset in Resource Dir of the File Table
|-
|unsigned short||File Table size in bytes
|}

==Type table==
It lists resource types in the Mohawk file. This table is always at the beginning of the Resource Dir.

Header:
{| class="structure"
|unsigned short||offset in Resource Dir of the Resource Name List (maybe this should go with the RSRC Header)
|-
|unsigned short||number of resource types in this file
|}

Entry (one for each type):
{| class="structure"
|4 bytes||resource type (tWAV, tBMP, NAME etc.)
|-
|unsigned short||offset in Resource Dir of the Resource Table for this type
|-
|unsigned short||offset in Resource Dir of the Name Table for this type
|}

==Name table==
There is one name table for each resource type. Many types don't have resource names; usually only tBMP, tWAV and tMOV do. Each entry holds the name offset in the name list for a resource.

Header:
{| class="structure"
|unsigned short||number of name entries (can be zero)
|}

Entry:
{| class="structure"
|unsigned short||offset of the name string in Name List
|-
|unsigned short||resource index (equal to the resource's index in File Table)
|}

==Resource table==
Again, there is one resource table for each resource type. The resource table holds crucial information about each resource of this type.

Header:
{| class="structure"
|unsigned short||number of resources for this type (number of table entries)
|}

Entry:
{| class="structure"
|unsigned short||resource ID
|-
|unsigned short||index in file table (starting from 1). Also used to find the matching name table entry
|}

==Resource name list==
This is a simple list of null-terminated strings (C strings), where each string is a resource name. Given a resource, you can get the offset to its name by looking in the name table entry for that resource.

==File table==
This table holds other important data about each resource, notably the location and size of the resource content within the whole Mohawk file. I wonder why this information couldn't go directly inside the resource table entry.

Header:
{| class="structure"
|unsigned long||number of file table entries
|}

Entry:
{| class="structure"
|unsigned long||absolute offset of resource data block
|-
|unsigned short||resource data size, bits 15-0
|-
|byte||resource data size, bits 23-16
|-
|byte||resource flags (unknown)
|-
|unsigned short||unknown (usually zero in Riven files)
|}

It should be noted that the resource data size information is incorrect for all [[Riven tMOV resources|tMOV]]s in the Riven archives. One can compensate for this by computing file lengths using the resource offsets.

Template:Myst

2008-02-06T03:59:33Z

Di gama: myst resources

Riven resources

2008-02-06T03:35:22Z

Di gama: this page just borrows the other pages and puts them together into a single page

{{Riven}}
This document talks about Riven resources controlling the game path and world; actually, it tries to document every resource other than [[Riven SFXE resources|SFXE]], [[Riven tBMP resources|tBMP]], [[Riven tWAV resources|tWAV]] and [[Riven tMOV resources|tMOV]].

==Notes on stack switching==
The current stack can be changed from scripts using a special script command (27). For example, when the player activates a MagLev first the car movie is played, and then command 27 is called to change the current stack to the new island. This command is also used in the "Play Riven" button. However, most linking books actually change stack simply by moving to another card which has no buttons and no scripts. Apparently, there is some hardcoded mechanism inside the engine which triggers the stack change when one of these "special" cards is entered. These cards are listed here.
{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Stack !! Card ID !! Target stack !! Target card
|-
|bspit||447||ospit||1
|-
|gspit||178||ospit||1
|-
|jspit||228||rspit||3
|-
|jspit||344||ospit||1
|-
|ospit||58||pspit||43
|-
|ospit||62||jspit||341
|-
|ospit||67||gspit||175
|-
|ospit||72||bspit||444
|-
|ospit||76||tspit||387
|-
|pspit||46||ospit||1
|-
|rspit||13||jspit||215
|-
|tspit||392||ospit||1
|}

==BLST, FLST, MLST, PLST, SLST==
These resources are lists and begin with an unsigned short telling the number of records. Then the records follow, and their structure depends on the resource type. There is one of these resources for each card; their ID matches the corresponding CARD resource ID.

===[[Riven BLST resources|BLST]]===
{{:Riven BLST resources}}
===[[Riven FLST resources|FLST]]===
{{:Riven FLST resources}}
===[[Riven MLST resources|MLST]]===
{{:Riven MLST resources}}
===[[Riven PLST resources|PLST]]===
{{:Riven PLST resources}}
===[[Riven SLST resources|SLST]]===
{{:Riven SLST resources}}
==[[Riven HSPT resources|HSPT]]==
{{:Riven HSPT resources}}
==[[Riven CARD resources|CARD]]==
{{:Riven CARD resources}}
==[[Riven NAME resources|NAME]]==
{{:Riven NAME resources}}
==[[Riven RMAP resources|RMAP]]==
{{:Riven RMAP resources}}
==[[Riven VARS resources|VARS]]==
{{:Riven VARS resources}}
==[[Riven VERS resources|VERS]]==
{{:Riven VERS resources}}
==[[Riven ZIPS resources|ZIPS]]==
{{:Riven ZIPS resources}}

Riven NAME resources

2008-02-06T03:30:56Z

Di gama: oops

<noinclude>{{Riven}}</noinclude>
They contain a list of strings with an associated value, and their purpose is to store names for variables, cards, hotspots and other entities. They have the following structure:

{| class="structure"
|unsigned short||field_count
|-
|unsigned short||string_offsets[field_count]
|-
|unsigned short||values[field_count]
|-
|char*||strings
|}

''strings'' is a list of zero-terminated strings. You can access string ''n'' by looking at ''string_offsets[n]'', which is the offset starting from strings (not from the beginning of resource data). The meaning of ''values[]'' is not yet known, but it seem to go from 0 to ''field_count''-1 (not in sequential order). This field apparently has no function (the record index is important, instead).

In saved games there's only one NAME resource; it stores the name of each variable in the VARS (the record index in the NAME matches the one in the VARS).

In data files there are more NAMEs: ID 1 stores card names, ID 2 hotspot names, ID 3 external command names and ID 4 variable names. In this case, the record index is equal to the number used in script commands to access the variable. Finally, ID 5 stores stack names and it's used by command 27 to change island.

Riven ZIPS resources

2008-02-06T03:29:07Z

Di gama: import

Found again only in saved games, this contains a list of visited locations to support the "Zip Mode". It starts with an unsigned short telling how many records will follow. Then, each record contains the following data:

{| class="structure"
|unsigned short||name_len
|-
|char||name[name_len]
|-
|unsigned short||card_id
|}

As one can easily imagine, each record is linked to a card: ''card_id'' tells its ID, and name is equal to the [[Riven CARD resources|CARD]] name. Zip Mode hotspots have the same name too, so when they are clicked, the target card ID can be known by looking up in the ZIPS. If the user already visited that card, the record will be there.

Riven VERS resources

2008-02-06T03:24:18Z

Di gama: import

This is found, again, only in saved game files, and should just contain version information. In my saved games files, it contains the following 4 bytes:
<div align="center" style="color:#008; font-family:monospace; margin:1em">00 01 00 00</div>
which probably means "version 1.0". I think Riven updates didn't change these values.