{
  "_args": [
    [
      {
        "raw": "github:meishuu/tera-data",
        "scope": null,
        "escapedName": null,
        "name": null,
        "rawSpec": "github:meishuu/tera-data",
        "spec": "github:meishuu/tera-data",
        "type": "hosted",
        "hosted": {
          "type": "github",
          "ssh": "git@github.com:meishuu/tera-data.git",
          "sshUrl": "git+ssh://git@github.com/meishuu/tera-data.git",
          "httpsUrl": "git+https://github.com/meishuu/tera-data.git",
          "gitUrl": "git://github.com/meishuu/tera-data.git",
          "shortcut": "github:meishuu/tera-data",
          "directUrl": "https://raw.githubusercontent.com/meishuu/tera-data/master/package.json"
        }
      },
      "C:\\Users\\YarNova\\Local Apps\\tera-proxy"
    ]
  ],
  "_from": "meishuu/tera-data",
  "_id": "tera-data@1.0.0",
  "_inCache": true,
  "_location": "/tera-data",
  "_phantomChildren": {},
  "_requested": {
    "raw": "github:meishuu/tera-data",
    "scope": null,
    "escapedName": null,
    "name": null,
    "rawSpec": "github:meishuu/tera-data",
    "spec": "github:meishuu/tera-data",
    "type": "hosted",
    "hosted": {
      "type": "github",
      "ssh": "git@github.com:meishuu/tera-data.git",
      "sshUrl": "git+ssh://git@github.com/meishuu/tera-data.git",
      "httpsUrl": "git+https://github.com/meishuu/tera-data.git",
      "gitUrl": "git://github.com/meishuu/tera-data.git",
      "shortcut": "github:meishuu/tera-data",
      "directUrl": "https://raw.githubusercontent.com/meishuu/tera-data/master/package.json"
    }
  },
  "_requiredBy": [
    "#USER",
    "/"
  ],
  "_resolved": "git://github.com/meishuu/tera-data.git#6694f6337ddf18cbcf0f1fd5374cd5b69752ceba",
  "_shasum": "f80aa184e7108e42f00db58f9e0f357ed2dd1748",
  "_shrinkwrap": null,
  "_spec": "github:meishuu/tera-data",
  "_where": "C:\\Users\\YarNova\\Local Apps\\tera-proxy",
  "author": {
    "name": "meishu"
  },
  "bugs": {
    "url": "https://github.com/meishuu/tera-data/issues"
  },
  "dependencies": {},
  "description": "Platform agnostic repository for information about TERA packets and system messages.",
  "devDependencies": {},
  "gitHead": "6694f6337ddf18cbcf0f1fd5374cd5b69752ceba",
  "homepage": "https://github.com/meishuu/tera-data#readme",
  "main": "package.json",
  "name": "tera-data",
  "optionalDependencies": {},
  "readme": "# tera-data\n\nThis repository is intended to house packet and system message information for\nTERA. It is intended to be platform agnostic, with details on the file formats\nexplained below.\n\nThe currently known open source parsers are:\n- JavaScript (Node): [tera-data-parser](https://github.com/meishuu/tera-data-parser-js)\n\n## Mappings\n\nThe `map` directory contains files which map unique identifiers (names) to their\nnumeric values. Currently, this includes:\n\n- `protocol.map`, which links opcodes to \"packet\" names\n- `sysmsg.map`, which links system message IDs to readable names\n\nThese generally come from the client binary and should not be built or modified\nby hand unless you know what you're doing.\n\nMethods and instructions on dumping opcodes and sysmsgs can be found from:\n- [Meishu](https://github.com/meishuu/TeraScanners)\n- [Mir](https://github.com/Mirrawrs/Tera/tree/master/GameClientAnalyzer)\n- [Gl0](https://github.com/neowutran/TeraDpsMeterData/blob/master/copypaste-tuto/Gl0-opcodes.txt)\n- [GoneUp](https://github.com/GoneUp/Tera_PacketViewer/tree/master/Opcode%20DLL#readme)\n\n## Protocol\n\nTERA's network data follows a custom protocol. It is convenient to describe the\norder and meaning of each element in a \"packet\", which is done through a `.def`\nfile under the `protocol` directory, and named after the opcode it belongs to.\n\nEach line in the `.def` must consist of the following, in order:\n- An optional series of `-` for array definitions. These may be separated by\n  spaces. To nest arrays, just add another `-` to the front.\n- A field type. Valid types listed below.\n- At least one space.\n- The name of the field.\n\nA `#` and anything after it on the line are treated as comments and will be\nignored when parsing.\n\nThe following basic field types are supported:\n- `byte`: A single byte. Also used for booleans.\n- `float`: A four-byte floating-point number.\n- `int16`\n- `int32`\n- `int64`\n- `uint16`\n- `uint32`\n- `uint64`\n\nThe protocol also supports variable-length fields, along with accompanying\nmetadata. These are described with the following field types:\n- `count`: Acts as `uint16`. Dictates the length of an `array` or `bytes` field\n  of the same name.\n- `offset`: Acts as `uint16`. Indicates the byte offset from the beginning of\n  the message for an `array`, `bytes`, or `string` field of the same name.\n\nThe names of `count` and `offset` fields should correspond to another field with\none of these variable-length types:\n- `array`: Requires both `count` and `offset`.\n- `bytes`: A series of `byte` data. Requires both `count` and `offset`.\n- `string`: String data, encoded as null-terminated UTF-16LE (in other words, a\n  series of `uint16` where the final value is 0). Requires only `offset`.\n\nMore details on the original message format are below, while details on your\nlanguage's or library's implementation of these types should be described in\nyour library's documentation.\n\n### Message Format\n\nTERA's networking encodes all data in little-endian.\n\nThere are a few fields which are implied because they are never omitted. Every\npacket begins with two fields:\n- `uint16 length`, which describes the byte length of the message, including\n  this header.\n- `uint16 opcode`, which describes which kind of message this is. By looking up\n  which name has this number in the mapping, you will know what the message is\n  called.\n\nAdditionally, all array elements begin with two fields:\n- `offset here`, which can be used to verify correctness. If this is the first\n  element, the `offset` for the array should match this; otherwise, it should\n  match the `next` for the previous element.\n- `offset next`, which points to the byte offset of the next element in the\n  array, or zero if this is the final element.\n\nIn general, you will find `count` and `offset` fields at the beginning of a\nmessage or array definition, and their corresponding fields at the end.\n\n## Versioning\n\nProtocol definitions contain version information in the filename:\n`<NAME>.<VERSION>.def` where `<NAME>` is an opcode name and `<VERSION>` is an\ninteger starting from 1 and incrementing with each change.\n\n**When submitting changes, contributors _must_ leave older versions untouched\nand instead submit the changed definition as a new file with the version number\nincremented.**\n\nWhenever TERA receives a major patch, a tag will be added to the repository,\nand then the mappings will be updated and all outdated definition files will be\ndeleted.\n\n## Contributing\n\nFeel free to submit pull requests! Please read the above notice in bold.\n\nThere is also a Discord for discussion and updates on `tera-data` and all\n`tera-proxy`-related repositories: <https://discord.gg/D2BCbgq>\n",
  "readmeFilename": "README.md",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/meishuu/tera-data.git"
  },
  "version": "1.0.0"
}
