imported>Dinoguy1000 |
imported>Ikskoks |
| (15 intermediate revisions by 5 users not shown) |
| Line 4: |
Line 4: |
|
| |
|
| == PAK == | | == PAK == |
| {{GRAFPageMisc|date_posted=20:45, 26 Apr 2006 (EDT)}}<!-- | | {{GRAFPageMisc}} |
| | |
| If your format is non-archive, add the parameter format_type= to it. You then choose from one of the following: {{FormatAudio}}, {{FormatMiscellaneous}}, or {{FormatVideo}}. For example, if my format is a picture format (video), I would place on the format page:
| |
| {{GRAFPageMisc|format_type={{FormatVideo}}|date_posted=XXX}}.
| |
| If your format is not Little Endian (and thus Big Endian), add the text endian_order={{EndianBig}} to it. For example, this would be placed on the format page:
| |
| {{GRAFPageMisc|endian_order={{EndianBig}}|date_posted=XXX}}.
| |
| You can also use these together. For example, if my above examples were for the same format:
| |
| {{GRAFPageMisc|format_type={{FormatVideo}}|endian_order={{EndianBig}}|date_posted=XXX}}
| |
| Lastly, note that the exact order of the parameters isn't important. For example,
| |
| {{GRAFPageMisc|date_posted=XXX|endian_order={{EndianBig}}|format_type={{FormatVideo}}}}
| |
| will display just the same as
| |
| {{GRAFPageMisc|format_type={{FormatVideo}}|date_posted=XXX|endian_order={{EndianBig}}}}
| |
| or
| |
| {{GRAFPageMisc|format_type={{FormatVideo}}|endian_order={{EndianBig}}|date_posted=XXX}}.
| |
| -->
| |
|
| |
|
| === Format Specifications === | | === Format Specifications === |
| Line 27: |
Line 13: |
| :char {16} - File name {{InlineComment|(null padded)}} | | :char {16} - File name {{InlineComment|(null padded)}} |
| :uint32 {4} - File size | | :uint32 {4} - File size |
| :byte {x} - File data}}<!-- | | :byte {x} - File data}} |
| | |
| Note that when you use the {{GRAFPageFormat}} template, if you use any other templates within it, such as {{InlineComment}} or {{Unknown}}, you need to place a 1= right after the pipe character (|). For instance, {{GRAFPageFormat|{{BlockDescription|This is a block description}}}} will display as '''None written yet'''. However, {{GRAFPageFormat|1={{BlockDescription|This is a block description}}}} will display as '''This is a block description''', in blue text. If no other templates are used, the 1= is completely optional, but it should still be left in.
| |
| | |
| Block section descriptions should use the {{BlockDescription}} template, like in the example above.
| |
|
| |
|
| Field tags can be one of the following:
| | ==== [[wikipedia:Microformat|Microformat]] sandbox ==== |
| uint16 {2} for 2-byte-long unsigned integers
| |
| uint32 {4} for 4-byte-long unsigned integers
| |
| char {x} for x-byte-long character data
| |
| byte {x} for x-byte-long hexadecimal data
| |
| int16 {2} for 2-byte-long signed integers
| |
| int32 {4} for 4-byte-long signed integers
| |
| float {x} for x-byte-long floats
| |
|
| |
|
| char {1} or byte {1} should be used for any 1-byte-long fields, and if you need a tag for fields 3 bytes long, or 5 bytes or longer, you can use
| | <div class="file-format"> |
| char {x} or something like uint48 {6}. If you use | | <div class="header-block"> |
| uintx {x} or intx {x}, note that the first number in the tag (the first x) is equal to the field's length * 8, so if a field is 4 bytes long, the first number would be 32. The second number (the second x) should be the field's actual length in bytes. Field tags themselves should be thirteen characters long from the beginning of the tag to the dash, inclusive, with multiple spaces using , as seen in the above example.
| | <div class="field"><!-- |
| | | --><span class="data-type">char</span> {<span class="field-size">15</span>} - <span class="field-description">Header</span> (<span class="field-value">Sample Game PAK</span>) |
| Unknown values should use the {{Unknown}} template. If you have an educated guess for what an unknown value might be, you should use
| | </div> |
| {{Unknown| '' Educated guess '' }}, where Educated guess is, of course, your educated guess.
| | <div class="field"><!-- |
| | | --><span class="data-type">byte</span> {<span class="field-size">1</span>} - <span class="field-description">null Padding</span> |
| Literal strings, such as "Hello world" or "Wuzup?" should be purple and enclosed within parenthesis following the field description. E.g.
| | </div> |
| {{Constant|("Hello world")}} Non-printable characters (NPC's), such as nulls, should be written as just the character's ASCII code in hexadecimal, e.g. 00 for a null. Nulls themselves can also be represented by the word "null". Multiple NPC's should be seperated from each other and any literal strings with spaces. For instance, | | </div> |
| {{Constant|("Hello world" 00 21)}} or | | <div class="data-block"> |
| {{Constant|("Hello world" null 21)}}
| | <div class="block-description">For each file</div> |
| | | <div class="field"><!-- |
| Any short notes should be enclosed in parenthesis and use the InlineComment template after the field description, e.g.
| | --><span class="data-type">char</span> {<span class="field-size">16</span>} - <span class="field-description">File name</span> (<span class="field-note">null padded</span>) |
| {{InlineComment|(This is a comment)}}. Longer notes should go in the "Notes and Comments" section. | | </div> |
| -->
| | <div class="field"><!-- |
| | --><span class="data-type">uint32</span> {<span class="field-size">4</span>} - <span class="field-description">File size</span> |
| | </div> |
| | <div class="field"><!-- |
| | --><span class="data-type">byte</span> {<span class="field-size">x</span>} - <span class="field-description">File data</span> |
| | </div> |
| | </div> |
| | </div> |
|
| |
|
| === Notes and Comments === | | === Notes and Comments === |
| None | | None |
| <!--
| |
|
| |
| You can create new section headings in this section, if necessary. If you do this, you should start with level four headings, e.g.
| |
| ==== This is a level four heading ====
| |
| and working farther in (with level five, etc. headings) if necessary. You can name these section headings whatever way suits you best, so long as they are somewhat descriptive of the notes in that section.
| |
| -->
| |
|
| |
|
| === MultiEx BMS Script === | | === MultiEx BMS Script === |
| {{NoBMSScript}}<!-- | | {{NoBMSScript}} |
| | |
| IMPORTANT: DO NOT USE TEMPLATES WITH THE BMS SCRIPT TAG!!!
| |
| The current BMS plugin doesn't work with templates, and as a result, it cannot be put on a page partially contained in a template. Therefore, assuming an oversimplified version of the BMS plugin, using something like
| |
| | |
| {{Script|author=someguy|ext=abc|script=foobar}}
| |
| | |
| with Template:Script containing
| |
| | |
| <bms author="{{{author}}}" ext="{{{ext}}}">
| |
| {{{script}}}
| |
| </bms>
| |
| | |
| the plugin returns an error, and you see lots of brackets. Templates can still be used outside of the <bms> tag with no consequense, though. Therefore,
| |
| | |
| {{template1}} <bms tag here> {{template2}}
| |
| | |
| will work perfectly fine.
| |
| -->
| |
|
| |
|
| === Supported by Programs === | | === Supported by Programs === |
| {{NoProgramSupport}}<!-- | | {{NoProgramSupport}} |
| | |
| If your format is supported by any programs, you should list each program on its own line, and each line should start with an asterisk (*). This will automatically make a list.
| |
| If your format is supported by MultiEx Commander, replace the line {{NoProgramSupport}} with {{ProgramSupportMexcom}}. Note that if MexCom supports a given format, its tag should always be the first program on the list.
| |
| If your format is supported by Game Extracter, replace the line {{NoProgramSupport}} with {{ProgramSupportGameExtracter}}. Note that if Game Extracter supports a given format, its tag should always be either directly below MexCom's tag (it should be second on the list), if MexCom also supports that format, or it should be at the top of the list.
| |
| If your format is supported by any other programs, list them in alphabetical order, and if they have pages on the WIKI, link the name to the corresponding page (otherwise, you can link to the program's official website). For example, if my format is supported by a program called FooBar3000, and there is a page on the WIKI for that program, the link would look like [[FooBar3000]] (if the page name was the same as the name of the program).
| |
| | |
| For example:
| |
| * {{ProgramSupportMexcom}}
| |
| * {{ProgramSupportGameExtracter}}
| |
| * AnotherGenericFileExtracter
| |
| * [[FooBar3000]]
| |
| * [http://www.someotherprogram.com SomeOtherProgram]
| |
| | |
| Without MexCom support:
| |
| * {{ProgramSupportGameExtracter}}
| |
| * [[FooBar3000]]
| |
| | |
| Without Game Extracter support:
| |
| * {{ProgramSupportMexcom}}
| |
| * [[FooBar3000]]
| |
| | |
| Without either:
| |
| * [[FooBar3000]]
| |
| -->
| |
|
| |
|
| === Links === | | === Links === |
| Line 120: |
Line 54: |
| === Games === | | === Games === |
| * [[Sample Game 1]] [[PAK|*.pak]] [[ZIP|*.zip]] | | * [[Sample Game 1]] [[PAK|*.pak]] [[ZIP|*.zip]] |
| <!--
| |
|
| |
| Each game listed here should link to its own page. If a game is for a non-PC platform, it should have the platform it's for in parenthesis following the game name, e.g. [[Sample Game 1 (PS2)]] or [[Sample Game 1 (Gamecube)]]. Before you do this, be absolutely sure that the game title is spelled correctly, etc. Also, each extension used by the given game for that format should link to its own page, as seen above.
| |
| -->
| |
|
| |
|
| {{GRAFPageFooter}} | | {{GRAFPageFooter}} |
|
| |
|
| [[Category:Complete Complete| ]] [[Category:Platform PC| ]] | | [[Category:Complete Complete| ]] [[Category:Platform PC| ]] |
| <!--
| | [[Category:File Format]] |
| | |
| Categories are used for... what do you know... categorizing WIKI pages. There are a number of categories used on the WIKI (somewhere around 50, IIRC), but by the time your page is finished, it will only have between 7 to 10 categories listed in most cases, and you will have to manually list even fewer. The categories you should worry about are those concerning how complete the Format Specifications are, those concerning a BMS script, those concerning what platform the game(s) using the format are for, those concerning how widely used a format is, and those concerning whether the format uses compression/encryption.
| |
| | |
| Keep in mind that all category tags should include the line {{subst:PAGENAME}} after the pipe character (|), e.g.
| |
| [[Category:Cat Name Here|{{subst:PAGENAME}}]]. After a page is saved, the WIKI automatically replaces this line with the page's name. In general, category tags should take the form | |
| [[Category:Cat Name Here|{{subst:PAGENAME}}]]
| |
| | |
| The specification completion categories are fairly straightforward to use. If most of a file's format is unknown (and chances are therefore good that it can't be supported by MexCom yet), one should use the category Complete WIP, indicating that the format is a work in progress. If the format is reasonably complete (few unknown values), you should use the category Complete Almost Done, and if the format is completely known (no unknowns), you should use Complete Complete.
| |
| | |
| As for BMS scripts, there are only three things you should worry about: if there's no BMS script for a given format, you should have used the template {{NoBMSScript}}, and the appropriate category is added automatically. Similarly, if a BMS script can't be used for a given format, because it's too complex, uses compression/encryption, wrong format type, etc., you should have used the template {{BMSNotApplicable}}, which also automatically adds the appropriate category. If you added a new script for a given format, you should add the category BMS New to the end of the page. Otherwise, don't worry about adjusting this category tag.
| |
| | |
| Moving on to platforms a given format is used on, in general, category names take the form of Platform *platform name*, e.g. Platform PC or Platform PS2. A full list of appropriate categories follows:
| |
| Platform 3DO
| |
| Platform PC
| |
| Platform XBox
| |
| Platform XBox 360
| |
| Platform Gamecube
| |
| Platform Dreamcast
| |
| Platform PS1
| |
| Platform PS2
| |
| Platform PS3
| |
| Platform PSP
| |
| More categories will be added as needed.
| |
| When adding platform categories, just use all of them that apply. For instance, if a format I was working on was used on the PC and the Gamecube, I would use the categories Platform PC and Platform Gamecube.
| |
| | |
| Next to last, these categories depend on the number of games known to use a given format. If a format is used by between four and twenty games, you should use the category Format Common. However, if a format is used by more than twenty games, or if it enjoys widespread use outside of the game development community, you should use the category Format Standard. Formats used by fewer than four games shouldn't be worried about.
| |
| | |
| Finally, the categories for compression and encryption are quite simple. Most of the time, the format you're working on won't use compression or encryption, so you should use the category CE None. If it uses unknown compression/encryption, you'll want to use the category CE Unknown. If you know for sure that a given format uses compression, use the category CE Compressed, and similarly, CE Encrypted for encryption. If a format uses both compression and encryption, skip the individual CE Compressed/CE Encrypted categories and just use CE Both.
| |
| | |
| After all of this, if you really want to dig deeper into the category system on the WIKI, start your explorations at Category:Categories.
| |
| -->
| |