Readme update #1514
Readme update #1514
Conversation
WIP documentation NOT FINISHED YET
Including broad breakdown into all general details and then Maintenance / Technical Usage admin ops. WIP research into each sub-database.
Key Field CRC vs Serial
WIP per dat descriptions (non-exhaustive).
WIP updates
Contributions draft etc
New explicit note about how thumbnail names (and therefore thumbnail assignment) aren't synced to database name changes. I'm partly mentioning for people investigating database/thumbnail troubles, but also to maybe get the interest of a volunteer someday.
Adding brief troubleshooting section
Moved out tentative "Troubleshooting" to new draft Docs site databases.md
|
Wow, that's quite complete :) |
README.md
Outdated
| ## Contents | ||
| - __Game information database files__. | ||
| - __`.dat`__ files in the clrmamepro DAT format, from many [sources](#sources) and across many categories of metadata. The system of dats is multifaceted: alternative or additional sources can be easily added and maintained in a self-contained constituent, some dats may overlap in the games they cover (see [precedence](#precedence)), and some dats cover an exclusive niche of games or attributes. | ||
| - __`.rdb`__ files used by RetroArch, compiled and amalgamated from the `.dat` files. [RetroArch Database format](https://github.com/libretro/RetroArch/tree/68b3e5d8e02aff753e01a1f6f8969891910b2e0b/libretro-db#readme) (_no relation to Redis .RDB files_) accommodates RetroArch's [wide range of hardware/OS platforms](https://www.retroarch.com/index.php?page=platforms). |
There was a problem hiding this comment.
A more generic link would be better (unless there is something in that particular revision):
https://github.com/libretro/RetroArch/blob/master/libretro-db/README.md
There was a problem hiding this comment.
Good catch, I didn't realize I copied a history/commit (tree?) link there, meant to have master. Fixing now.
README.md
Outdated
|
|
||
| The `description " "` and `comment " "` fields within a libretro dat's `clrmamepro ( )` header should be used to clarify the origin and source of the data and file. For example, if a .dat includes 3rd party upstream data processed through a github author's build/scrape script(s), the comment and description (or other appropriate header fields) should contain information about _both_ those aspects of the dat's origin. The description and comment header fields are intended for documentation purposes, are ignored by RetroArch, and can be freely changed without issue. | ||
|
|
||
| Only the `name` field of a `.dat` file header must match a uniform system name recognized by RetroArch, not the `description` field. |
There was a problem hiding this comment.
"Uniform" is maybe a bit too strong for what it is. Usually formulated in a "manufacturer - systemname" format, but there are exceptions where e.g. there is no manufacturer, or it is not a typical emulator core, etc... The main thing is that it should match the name that is specified by the core in the .info file: https://github.com/libretro/libretro-super/tree/master/dist/info
There was a problem hiding this comment.
Great point, I forgot to second-guess my statement for exceptions, mind focused on the contrast with [mis-use] of the description field. I'm fixing it like you said, header name should database field in .info files and with link to that repo.
Fixed link to master, was wrongly linked to a specific history/commit
Changed wording about header `name` to fix the wrong statement/generalization pointed out by reviewer. Name isn't always `manufacturer - system`, and core info files (now linked) detail what it should be.
Extra clear about the `database` field in .info files now
Thank you to @RobLoach, @zoltanvb, @hunterk, @zach-morris, i30817, for helpful information, answers, and discussions.
Database readme update.
Goals
descriptionheader in particular, in the hopes of addressing sourcing mysteries for future or current dats.List of Additions / Expansions
.datand.rdbfilesdescriptionfield and the current or systematic lack of sourcing/documentation for several dats. Intended to address the situation where, I believe, many people see a typical headerdescription "Manufacturer - Console"and mistakenly think that's required for functionality/by-spec. Specification now given about better documentation of origins, sourcing, including both upstream credit and contributor/scraper/builder/datversus in/metadat, partly covers questions of whether a dat is ad hoc / contribute-able Versus whether it's bulk-overwritten by imports, in order to assist/encourage contributions.