General dat notes: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(→File) |
||
Line 35: | Line 35: | ||
|- | |- | ||
|Date | |Date | ||
|Generally, this shouldn't be used, as it is put into the datfile, and ROM managers may change the local file | |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 | |File version | ||
Line 43: | Line 43: | ||
|This is a WIP alternative to making "Trusted Modification" sources, and shouldn't be used for now. | |This is a WIP alternative to making "Trusted Modification" sources, and shouldn't be used for now. | ||
|} | |} | ||
==Tags== | ==Tags== |
Revision as of 08:47, 23 December 2020
- 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
- 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 |
---|---|
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. |
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 encomases 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 |
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) |