General dat notes: Difference between revisions

From No-Intro ~ Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
(36 intermediate revisions by the same user not shown)
Line 1: Line 1:
* Do not add dump to DoM unless you are going to add it properly+fully and have got as much info off the dumper as you reasonably can.
* Serials should be separated with a comma and no space
* Serials should be separated with a comma and no space
* Box barcodes should be added on their own line in Comment+ like<br><code>Box barcode: X XXXXX XXXXX X<tab>XXXXX</code><br>(preserving spaces if there are any and putting an actual tab to represent gaps between different "barcode boxes"). Put a comma (no space) if the two barcodes are completely separate.
* HTTP response headers should be attached to the file as a unique attachment.
* Publisher/developer serials on carts should be recorded in their own line in Comment+ like<br><code>[Company name] serial on [box/cart] [front/back]: XXXXXXXX</code>
* anonomous dumper names like <code>!anon-YYYY-MM-DD-########</code> can be used to uniquely identify an anonymous dumper, where YYYY-MM-DD is the GMT date the id was generated and ######## is a randomly generated lowercase alphanumeric 8-character string. The same id should be used across multiple dumps by the same anonymous person.
** For consistency, list Company names used in DoM for this purpose here:
* If the ROM was dumped as trimmed (dumping tool guesses or checks when the "real" data ends), but then restored from the header field, you can add: <code>[Dumped as trimmed, restored from header]</code> to the comment1 field
*** Activision
* If the dump date is from the http response header(s) date field, put <code>[Date from HTTP headers]</code> in the comment2 field.
** If you don't know what code company (if any) they are for, just put them down as for example <code>Additional cart front serial</code> in the Comment+
* If the file sizes are from the http response header(s) length field, put <code>[Sizes from HTTP headers]</code> in the comment2 field.
* If the language hasn't been checked, make a discussion called <code>!langs-not-checked</code>. The body of the discussion doesn't have to the same.
 
* HTTP response headers should be added in the Comment+, ma starting with <code>!http-response-header-start</code> and then a newline and ending with a newline and <code>!http-response-header-end</code>. To specify what file the header is for, use <code>!http-response-header-define: filename</code>
==Fields==
===Archive===
{| class="wikitable"
!Field
!Explaination
|-
|Special
|Comma+space seperated values. Use "Aftermarket" if the game wasn't released within the console's lifespan.
|-
|Game ID
|Generally, this shouldn't be used - use the source or file serial fields instead.
|}
 
===Source===
{| class="wikitable"
!Field
!Explaination
|-
|Session
|Generally, this shouldn't be used.
|-
|Title on media
|Generally, this shouldn't be used.
|-
|Origin
|This should only be used if the origin is non-standard for that system. E.g. just leave it blank instead of putting "Retail cart".
|}
 
===File===
{| class="wikitable"
!Field
!Explaination
|-
|Date
|Generally, this shouldn't be used, as it is put into the datfile, and ROM managers may change the local file date to match this, which may be undesirable.
|-
|File version
|This should only be used if an archive encompases multiple game versions (e.g. Nintendo CDN stuff).
|-
|Origin
|This is a WIP alternative to making "Trusted Modification" sources, and shouldn't be used for now.
|}
 
==Tags==
Documentation for common "tags" that are used in comment fields.
===Sticky Note===
{| class="wikitable"
!Tag
!Explaination
|-
|!pc-platform-[platform]
|For IBM PC digital. Values: windows, mac, linux. e.g. !pc-platform-windows
|-
|[Original title: x]
|Where x is the original title. To be used if the Media fields aren't enabled for that dat yet.
|}
 
===Comment 1===
{| class="wikitable"
!Tag
!Explaination
|-
|[Untrimmed]
|For Trusted Modification sources.
|-
|[Modification of file: size-sha256]
|For Trusted Modification sources. [size] = Size in bytes, [sha256] = sha256 of file, all caps
|-
|[Dev cart]
|Used when dump status is set to "other" to prevent dev cart from counting towards verified status.
|-
|[Internal checksum mismatch]
|Internal checksum doesn't match data.
|-
|[Standalone fix]
|For Satellaview Trusted Modification sources that contain fixed standalone ROMs for games in a Memory Pack.
|-
|[Marked as deleted]
|For satellaview ROMs that were marked as deleted (blanked header)
|}
 
===Comment 2===
{| class="wikitable"
!Tag
!Explaination
|-
|[Asked dumper for more info]
|To be used when the dumper hasn't provide pictures, etc, you've asked them for this extra info/data and are waiting.
|}
 
[[Category:Datting guides]]
[[Category:Datting guides]]
* PC game platforms should be added like <code>!platforms: Windows, Mac, Linux</code> a line on the sticky note (in that order)

Revision as of 13:23, 5 March 2021

  • Serials should be separated with a comma and no space
  • HTTP response headers should be attached to the file as a unique attachment.
  • anonomous dumper names like !anon-YYYY-MM-DD-######## can be used to uniquely identify an anonymous dumper, where YYYY-MM-DD is the GMT date the id was generated and ######## is a randomly generated lowercase alphanumeric 8-character string. The same id should be used across multiple dumps by the same anonymous person.
  • If the ROM was dumped as trimmed (dumping tool guesses or checks when the "real" data ends), but then restored from the header field, you can add: [Dumped as trimmed, restored from header] to the comment1 field
  • If the dump date is from the http response header(s) date field, put [Date from HTTP headers] in the comment2 field.
  • If the file sizes are from the http response header(s) length field, put [Sizes from HTTP headers] in the comment2 field.

Fields

Archive

Field Explaination
Special Comma+space seperated values. Use "Aftermarket" if the game wasn't released within the console's lifespan.
Game ID Generally, this shouldn't be used - use the source or file serial fields instead.

Source

Field Explaination
Session Generally, this shouldn't be used.
Title on media Generally, this shouldn't be used.
Origin This should only be used if the origin is non-standard for that system. E.g. just leave it blank instead of putting "Retail cart".

File

Field Explaination
Date Generally, this shouldn't be used, as it is put into the datfile, and ROM managers may change the local file date to match this, which may be undesirable.
File version This should only be used if an archive encompases multiple game versions (e.g. Nintendo CDN stuff).
Origin This is a WIP alternative to making "Trusted Modification" sources, and shouldn't be used for now.

Tags

Documentation for common "tags" that are used in comment fields.

Sticky Note

Tag Explaination
!pc-platform-[platform] For IBM PC digital. Values: windows, mac, linux. e.g. !pc-platform-windows
[Original title: x] Where x is the original title. To be used if the Media fields aren't enabled for that dat yet.

Comment 1

Tag Explaination
[Untrimmed] For Trusted Modification sources.
[Modification of file: size-sha256] For Trusted Modification sources. [size] = Size in bytes, [sha256] = sha256 of file, all caps
[Dev cart] Used when dump status is set to "other" to prevent dev cart from counting towards verified status.
[Internal checksum mismatch] Internal checksum doesn't match data.
[Standalone fix] For Satellaview Trusted Modification sources that contain fixed standalone ROMs for games in a Memory Pack.
[Marked as deleted] For satellaview ROMs that were marked as deleted (blanked header)

Comment 2

Tag Explaination
[Asked dumper for more info] To be used when the dumper hasn't provide pictures, etc, you've asked them for this extra info/data and are waiting.