rush patch

docu/dataTypes.txt

@@ -99,6 +99,20 @@ Universal Time Coordinated Date/Time
 Date
 counts milliseconds since January 1, 1970
 
+GUID
+Globally Unique Identifier
+UUID, Universally Unique Identifier
+16 bytes representing a unique id for an object or codebase
+Shockwave/Director makes use of these in XTRAs
+{
+	// for more info: https://en.wikipedia.org/wiki/Universally_unique_identifier#Format
+	Uint32 time_low
+	Uint16 time_mid
+	Uint16 time_hi_and_version
+	Uint16 clock_seq_hi_and_res clock_seq_low
+	Uint48 node //6 bytes
+}
+
 Block
 Block
 Struct //specifically in languages like C
@@ -143,6 +157,7 @@ Byte-Aligned
 {
 	Something has been forced to always be divisible by certain length in bytes
 }
+
 ==RIFF/RIFX==
 RIFF: http://www.johnloomis.org/cpe102/asgn/asgn1/riff.html
 basically, 

docu/misc/XTRA/FormatNotes_PFR.txt

@@ -2,7 +2,12 @@ PFR (Portable Font Resource) aka "TrueDoc" format:
 adapted from existing .pdf's detailing specs, but in a nicer format
 
 Struct header {
-	String(4) signature // "pfr0" , but shockwave has "PFR1"
+	String(4) signature // "PFR0" , but shockwave has "PFR1"
 	Uint16 [big] version // constant 4
 
+}
+
+Struct trailer {
+	Uint24 [big] size // of entire file
+	String(5) trailerSig // "$PFR$"
 }

docu/structure/FormatNotes_Sections_VWXX.txt

@@ -1,6 +1,6 @@
 SHOCKWAVE FORMAT (timeline???):
 All sections here seem to pertain to the timeline
-Their FourCC ID's All begin with "VW" (meaning yet unknown)
+Their FourCC ID's All begin with "VW" (Most likely means "VideoWorks", the original name of Director)
 
 Section VWLB {
 	// "L[a]B[el]"

docu/structure/castlib/FormatNotes_CASt_specificData.txt

@@ -0,0 +1,23 @@
+CASt specificDatas:
+
+Struct bitmapProperties {
+	//still trying to understand this one...
+	2 bytes unknown
+	Uint16 posY
+	Uint16 posX
+	Uint16 height // subtract posY for correct value
+	Uint16 width // subtract posX for correct value
+	Uint32 constant1 (1) //1 is so far, only observed value...
+	4 bytes unknown
+	Uint16 regPointY // subtract posY for correct value
+	Uint16 regPointX // subtract posX for correct value
+	1 byte unknown //possibly a bitfield
+	1 byte bitsPerPixel //8,16,24,32
+	Uint16 [big] palette ID //still needs research, but seems to be based on the cast member number of a given palette
+}
+
+Uint16 [big] scriptType (
+	00 01 : behavior
+	00 03 : movie
+	00 07 : parent
+)

docu/structure/castlib/FormatNotes_CastLib.txt

@@ -0,0 +1,76 @@
+SHOCKWAVE FORMAT (cast library):
+
+Section MCsL
+{
+	// cast list, includes name and settings of all casts
+	Uint32 [big] unknown (0x0c)
+	Uint32 [big] castCount
+	Uint16 [small?] unknown (0x400)
+	Uint32 [big] arraySize
+	Uint32Array(arraySize) offsetTable (one entry per cast) {
+		Struct castDataOffsetEntry // four indices in the table make one entry
+		{
+			// all offsets are relative to the start of the data table
+			Uint32 [big] nameOffset
+			Uint32 [big] filePathOffset
+			Uint32 [big] preloadSettingsOffset
+			Uint32 [big] attributesOffset
+		}
+		/*
+			This is practically identical to the offset tables found in CASt sections...
+			excluding that the first U32 is either junk data, or a pointer to the
+			data table, presumably relative to the end of this table. At this time,
+			no MCsL have been discovered where this value is of any use.
+		*/
+	}
+	Uint32 [big] castEntriesLength
+	Array dataTable(castCount)
+	{
+		Struct castEntry {
+			Null-terminated* Length(byte)-prefixed ASCII String name
+			Null-terminated* Length(byte)-prefixed ASCII String filePath
+			Uint16 [big] preloadSettings (0:when needed, 1: before frame one, 2: after frame one)
+			Struct castAttributes {
+				Uint16 [big] storageType? (0:external,1:internal) // purpose recently brought into question
+				Uint16 [big] membersCount
+				Uint16 [big] numID
+				Uint16 [big] realCastID (starts at 0x400 , or 1024)
+			}
+		}
+		/*
+			This might still be slightly innaccurate...
+			It's also somehow missing a value for preload settings
+
+			*
+			Some older versions appear not to use null-terminated strings, according to MrBrax
+		*/
+	}
+	/*
+		External cast files (CST,CCT,CXT) seem to not have these. It makes sense, because external casts only contain ONE
+		cast: themselves.
+	*/
+	/*
+	tomysshadow said:
+	Also, haven't had a chance to document this but I should add: the IDs in MCsL refer to the CAS* chunks, 
+	based on their index in mmap. The CAS* are a table of the IDs of CASt chunks in the mmap table, iirc, 
+	and the chunks those CASt rely on are found using KEY*. So it goes MCsL > CAS* > mmap > CASt >KEY* > Data 
+	(such as BITD, snd , etc.) note that multiple chunks can be linked to one CASt in KEY*, for example the 
+	sound headers can be seperate of the sound itself using sndH and sndS
+
+	This is one of my more recent realizations and it is with this that I finally begin to understand the 
+	structure somewhat.
+
+	Also, note that LCsM isn't present in older Director movies as not all versions of Director have cast libraries.
+
+	src: https://github.com/Brian151/OpenShockwave/issues/9#issuecomment-313375248
+	*/
+}
+
+Section CAS* {
+	// cast section association table, points to CASt chunks via their MMAP ID
+	// external casts seem to lack these
+	Uint32Array(length / 4) CAStIDs // length, as in the section length
+	{
+		Uint32 [big] CAStID
+	}
+}

docu/structure/castlib/FormatNotes_CastMember.txt

@@ -0,0 +1,193 @@
+SHOCKWAVE FORMAT (Cast Members):
+
+Section CASt
+{
+	/* 
+		cast member header, contains settings and various properties, such as name
+		this chunk is proving particularly difficult to fully decypher, and recent efforts have 
+		shown the available fields vary quite largely depending on any number of factors.
+		This can be attributed to both the type of cast member, and even if a file has been
+		Dir-Opened vs. being the genuine DIR source movie/document
+	*/
+	Struct header
+	{
+		Uint32 [big-end] castMemberType
+		(
+			// do each of these correspond to one type of chunk or group of chunks? (BITD, whatever the chunk for a film loop is, CLUT, snd , whatever the chunk for a button is, whatever the chunk for a vector shape is, Lscr, and XMED?)
+			0x01 : bitmap
+			0x02 : film loop
+			0x04 : palette
+			0x06 : audio
+			0X07 : button
+			0x08 : vector shape
+			0x0B : script
+			0x0F : flash,font,text,W3D,QuickTime MOV //The common link between all is the requirement of Xtras to use these
+		)
+		Uint32 [big end] length2 //from 0x14 to specificData
+		Uint32 [big-end] specificDataLen
+		0x14 bytes skipThis {
+			Uint32 [big-end] skipSize? (always 0x14)
+			0x10 bytes unknownData (does vary, but purpose unknown)
+		}
+		Uint16 [big-end] offsetTableLen
+			Uint32Array(offsetTableLen) offsetTable {
+			Uint32 [big-end] offsetX //see formatNotes_CASt_properties
+		}
+		Uint32 [big end] finalDataLen
+		ByteArray(finalDataLen) properties
+		{
+			//comprised of various fields...
+			//see formatNotes_CASt_properties
+		}
+	}
+	ByteArray(specificDataLength)  specificData
+	{
+		/*
+			These vary a lot, but they do seem to have an absolute structure and order
+			// see FormatNotes_CASt_specificData.txt
+		*/
+	}
+}
+
+Section Thum
+{
+	// thumnails?
+	// these two appear to be constantly 36
+	Uint32 [big] width // ?
+	Uint32 [big] height //?
+	length - 8 bytes data {
+		currently assumed to be RLE,
+		but no success yet. Might be at bit depth 16 or lower
+	}
+}
+
+Section BITD
+{
+	length
+	data
+	/*
+		format varies...
+		the format is a length followed by a value, across the width of the image one channel at a time
+		however, the length has an odd quirk: you need to do 257 minus the length to get the actual length to use
+		however, if 257 minus the length is less than 127, it is a literal run for that length plus one and specifies all the colours in a row like a raw image
+	*/
+	@4BPP {
+		unknown, no examples analyzed yet
+	}
+	@8BPP {
+		ByteArray(length * width), or some form of compression
+	}
+	@16BPP {
+		unknown, no examples encountered yet
+	}
+	@24BPP {
+		RLE {
+			encodes all red, all green, all blue across entire width of image,
+			then starts over until all rows have been encoded	
+		}
+	}
+	@32BPP {
+		RLE {
+			encodes all alpha, all red, all green, all blue across entire width of image,
+			then starts over until all rows have been encoded
+			sometimes all alpha values are reversed, and 0 means 255, which only seems to occur if every value is 0
+		}
+	}
+}
+
+Section CLUT
+{
+	// length is ALWAYS divisible by 6
+	/*
+		color palettes,
+		each CLUT actually contains 2, and they're combined in a somewhat odd manner...
+		Or, each color value has some extra data attached.
+		Regardless, the reasons for the three extra bytes per entry is a mystery for the time being.
+		Other than that, the data is an array of RGB24 colors
+		The name of an Xtra seems to suggest this is lifted from Photoshop
+	*/
+	Array entries/data(length/6) {
+		byte red
+		byte red2
+		byte green
+		byte green2
+		byte blue
+		byte blue2
+	}
+}
+
+Section STXT
+{
+	Uint32[big] headerLength (constant 0xC)
+	Uint32[big] textLength
+	Uint32[big] styleLength
+	String(textLength) text
+	// this could be something to do with color
+	ByteArray(footerLength) styles {
+		Uint16 [big] stylesArrayLength
+		Array(arrayLength) stylesArray{
+			Struct style {
+				Uint32 [big] offset?
+				Uint32 [big] constant? (0)
+				Uint32 [little] unknown3 (seems constant)
+				Uint16 [big] unknown4 // identify what attribute of text is affected?
+				String(6) colorCode // RRGGBB format
+			}
+		}
+	}
+	// seems to be associated with scriptable cast members, like buttons and text fields
+	// possible meaning : "S[tyled]T[e]XT" - updated with information from Tomysshadow
+	// purpose : partially unknown
+}
+
+Section snd 
+{
+	/* 
+		sometimes the length is 0 and it trails SWA audio.
+		in that scenario the XMED and snd are linked to the same CASt in the KEY* section so the cast member is classed as a sound even though it requires an Xtra to play
+		other times it contains raw PCM streams which GoldWave can import, and probably Audacity as well.
+		observed: Raw PCM unsigned 8 bit, 11025 Hz, 88 kbps, mono (for the door opening sound in MYLK)
+	*/
+}
+
+Section ediM
+{
+	data
+	/*
+		contains SWA audio-
+		further analysis shows this contains other data/file types as well...further research required
+	*/
+	//known formats : JPEG Image file, SWA Audio file
+}
+
+Section XMED
+{
+	/* 
+		XTRA Media, completely arbitrary format, often consists of optional header and an embedded file
+		Probably most common cause of XTRA dependency (no surprise there), anything in an XMED requires
+		an XTRA to be displayed/processed.
+	*/
+	// text (RTF) , Flash SWF , W3D Model/Scene, PFR/TrueDoc font
+	data {
+		//format varies depending on the type of media
+		@ Flash {
+			Uint32 [big] length1
+			Uint32 [big] version?
+			Uint32 [big] length2 //seems to be the real length of the file
+			data //embedded Flash SWF file
+		}
+		@ Text {
+			data //some weird way of storing formatted text...
+		}
+		@ W3D {
+			subHeader {
+				String/FourCC? "3DEM"
+				Uint32 [big] length1 //same as the section length
+				Uint32 [big] version?
+				Uint32 [big] length2 //seems to be the real length of the file
+			}
+			data //embedded W3D Model/Scene file
+		}
+	}
+}
+

docu/structure/castlib/formatNotes_CASt_properties.txt

@@ -16,14 +16,12 @@ String scriptSrcText
 Length(Byte)-prefixed ASCII String name
 ??? cProp02
 ??? cProp03
-comment {
-	String comment
-}
+String comment // pure character data
 ??? cProp05
 ??? cProp06
 ??? cProp07
 ??? cProp08
-??? cProp09
+GUID xtraGUID
 Struct cProp10 {
 	String type (
 		"Flash Movie" : SWF