Skip to content

Instantly share code, notes, and snippets.

@jmickle66666666
Last active February 8, 2017 17:56
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jmickle66666666/df81f82adc91df406dafc7ff24dd7a83 to your computer and use it in GitHub Desktop.
Save jmickle66666666/df81f82adc91df406dafc7ff24dd7a83 to your computer and use it in GitHub Desktop.
METADATA lump specification concept
* Not final, this is an example implementation *
Lump spec:
The METADATA lump will be a text lump containing JSON information
about all of the lumps contained in the wad.
The lump will always be named METADATA, and the user should never
be editing the information contained inside by hand.
Editors will generate the METADATA lump themselves, using data from
specific lump editors contained in the editor. (For instance, GZDoombuilder
would write METADATA information about the map lumps for the map being
edited itself. Any user-defined information will have an interface in the
application.)
Duplicate lump names:
The case of two or more lumps existing in a wad file with the same name is
handled with the Position, MD5 and SHA-1 fields of the lump's required fields.
Two lumps cannot occupy the same position in a wad, and two lumps can be
checked against each other with the checksums defined.
METADATA should be *ignored* by source-ports by default. The goals of
the METADATA lump are specifically for modders and editor utilities, and
thereby it should be avoided to have any ports rely on interacting with
the data, if only to proof the METADATA lumps against future specification
changes.
There are three kinds of fields in the METADATA structure:
1. Required fields. Required fields must be able to be generated with
no user input, to prevent any errors. This should be for only the most
important information that METADATA would be used for.
2. Standard fields. These would be a set of standard fields that can apply
to common lump types, with a standard specification for the data included
in them.
3. Custom fields. These cannot share the name of any standard or required
fields, and would be used for extra information that is not required but
can aide development/information for users and editor applications.
Structure:
{
"Information" : {
"Version" : string, // The version of the METADATA specification used.
"Lumps" : integer // The number of lumps defined in the METADATA.
// This can be used to verify the integrity of a METADATA lump
},
"Lumps" : [
"LUMPNAME" : {
// Required fields
"Index" : integer // The position of the lump in the wad file.
"MD5" : string, // MD5 hash of the lump data, for integrity/validity checks.
"SHA-1" : string, // SHA-1 hash of the lump data, for integrity/validity checks.
"Source" : string, // The filename of the WAD file this lump originated from.
// Default: the wad file the lump currently exists in.
"Created" : int, // Date integer describing when the lump was first created
// Default: the creation date of the wad file
"Modified" : int, // Date integer describing when the lump was last modified
// Default: the creation date of the wad file
// Standard fields
"Authors" : [ ...string ], // An array of strings listing the authors of the LUMP.
// When a lump is edited, the application should append the
// name of the user automatically, if it doesn't exist.
// Default username is "anonymous".
"Alias" : string, // A string defining a human-readable alias for the lump.
// Editors should show this name as a priority over the name
// of the lump. Supporting a virtual folder structure is possible
// if forward slashes "/" are used.
"Editors" : [ ...string ], // An array of strings listing the editors (with version number)
// that were involved in the modification of this lump.
},
...
]
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment