diff --git a/docu/dataTypes.txt b/docu/dataTypes.txt index 70f53ac..c43ac89 100644 --- a/docu/dataTypes.txt +++ b/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, diff --git a/docu/misc/XTRA/FormatNotes_PFR.txt b/docu/misc/XTRA/FormatNotes_PFR.txt index 7a10f08..700a347 100644 --- a/docu/misc/XTRA/FormatNotes_PFR.txt +++ b/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$" } \ No newline at end of file diff --git a/docu/structure/FormatNotes_Sections_VWXX.txt b/docu/structure/FormatNotes_Sections_VWXX.txt index 3c7f614..0f3c7cd 100644 --- a/docu/structure/FormatNotes_Sections_VWXX.txt +++ b/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]" diff --git a/docu/structure/castlib/FormatNotes_CASt_specificData.txt b/docu/structure/castlib/FormatNotes_CASt_specificData.txt new file mode 100644 index 0000000..637f2c1 --- /dev/null +++ b/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 +) \ No newline at end of file diff --git a/docu/structure/castlib/FormatNotes_CastLib.txt b/docu/structure/castlib/FormatNotes_CastLib.txt new file mode 100644 index 0000000..125b64d --- /dev/null +++ b/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 + } +} \ No newline at end of file diff --git a/docu/structure/castlib/FormatNotes_CastMember.txt b/docu/structure/castlib/FormatNotes_CastMember.txt new file mode 100644 index 0000000..d7dbccf --- /dev/null +++ b/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 + } + } +} + diff --git a/docu/structure/castlib/formatNotes_CASt_properties.txt b/docu/structure/castlib/formatNotes_CASt_properties.txt index 6be2347..c597d76 100644 --- a/docu/structure/castlib/formatNotes_CASt_properties.txt +++ b/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 diff --git a/docu/structure/core/FormatNotes.txt b/docu/structure/core/FormatNotes.txt index 5ac14ce..00ce89d 100644 --- a/docu/structure/core/FormatNotes.txt +++ b/docu/structure/core/FormatNotes.txt @@ -89,33 +89,6 @@ Section [ghost] free // or they may have something else to do with memory allocation { -Section XMED -{ - 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 - } - } - // contains [certain] Xtra Media (any media requiring an Xtra to play) - // observed so far : text [field] , Flash SWF , W3D Model/Scene -} - Section Fmap { // font mapping table (one per cast) // exact purpose not yet known @@ -165,276 +138,6 @@ Section Fmap { } } -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 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 Thum -{ - //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 - } - //thumnails? (only appears in a DIR that's been saved in Director) -} - -Section CASt -{ - 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 - */ - paletteData { - //nothing yet found, every palette observed thus far hasn't had any - } - bitmapData { - //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 - } - scriptData { - Uint16 [big-end] scriptType - ( - 00 01 : behavior - 00 03 : movie - 00 07 : parent - ) - } - } - /* - cast member metadata - 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 - */ -} - -Section CAS* -{ - Uint32Array(length) CAStIDs - { - /* - a Unit32 array, each value is an indice according to the mapping table... - The indeces should all point to CASt sections - */ - } - /* - This is a cast, or rather, a cast association table. This contains the neccesarry data to group - CASt sections into a complete cast. It does not contain the name, however. The cast name would be found - in the MCsl section. External casts do not have a CAS* table, probaby because they do not need one with - their data being stored in separate files. - */ -} - -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 MCsL -{ - /* - cast list - */ - 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 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 XTRl { Uint32 length @@ -447,23 +150,7 @@ Section XTRl //needs more research ByteArray(0x22) unknown { Uint16 GUIDLen // constant 16 - Struct GUID { - // Globally Unique Identifier for a given XTRA - // In some cases, it will be {00000000-0000-00-00-00-00-00-00-00-00} - // unsure what allows this, as identical GUIDs should typically case errors - Uint32 [big] id1 - Uint16 [big] id2 - Byte id3 - Byte id4 - Byte id5 - Byte id6 - Byte id7 - Byte id8 - Byte id9 - Byte id10 - // 664C4541-1AD8-11d3-8635-00104B27A1A1 - } - + GUID xtraGUID // In some cases, it will be {00000000-0000-00-00-00-00-00-00-00-00} } Uint32 [big-end] length2 Block(length2) data diff --git a/examples/studies/CASt_offsets.txt b/examples/studies/CASt_offsets.txt index b9b51f6..cb2849e 100644 --- a/examples/studies/CASt_offsets.txt +++ b/examples/studies/CASt_offsets.txt @@ -284,4 +284,33 @@ fileFormatID,...,...,... //data 13 42 69 74 20 4C 69 67 68 74 31 30 20 28 73 52 42 29 20 2A //name B7 5C 0A 03 B2 A7 11 D1 8C A6 44 45 53 54 00 00 //? -46 6F 6E 74 2E 2E 2E 00 //format \ No newline at end of file +46 6F 6E 74 2E 2E 2E 00 //format + +// spybotics fonts +// 1 +00 00 00 00 00 00 00 00 00 00 00 14 00 00 00 14 +00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14 +00 00 00 14 00 00 00 14 00 00 00 24 +0100 +0000 +011 +00 00 00 2C + +13 42 69 74 20 4C 69 67 68 74 31 30 20 28 73 52 42 29 20 2A +B7 5C 0A 03 B2 A7 11 D1 8C A6 44 45 53 54 00 00 +46 6F 6E 74 2E 2E 2E 00 + +// 2 +00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 09 +00 00 00 09 00 00 00 09 00 00 00 09 00 00 00 09 +00 00 00 09 00 00 00 09 00 00 00 19 +0100 +0000 +011 +00 00 00 21 + +08 30 34 62 5F 32 35 20 2A +B7 5C 0A 03 B2 A7 11 D1 8C A6 44 45 53 54 00 00 +46 6F 6E 74 2E 2E 2E 00 + + diff --git a/tools/Lists/shockList.js b/tools/Lists/shockList.js index 5630808..cd14236 100644 --- a/tools/Lists/shockList.js +++ b/tools/Lists/shockList.js @@ -1,8 +1,9 @@ -//input, output : textareas +// input, output : textareas /* TODO: Nothing, for now... + detailed comments actually explaining how it works... */ var ShockwaveListParser = function() {} @@ -107,7 +108,6 @@ ShockwaveListParser.prototype.detectProperty = function(s) { } return out; } -//needs an update... won't work as-is ShockwaveListParser.prototype.appendChildren = function(obj,children,isPropList) { for (var i=0; i < children.length; i++) { var curr = children[i]; @@ -122,7 +122,6 @@ ShockwaveListParser.prototype.appendChildren = function(obj,children,isPropList) } } } -//needs to be updated, won't work as-is... ShockwaveListParser.prototype.trimOuterBrackets = function(dat,checkComplex) { var d = dat; var out = d;