MediaWiki API result

This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.

Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.

See the complete documentation, or the API help for more information.

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Release_Process",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "32": {
                "pageid": 32,
                "ns": 0,
                "title": "Record Store",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "__NOTOC__\nThe world model is split in two parts: An immutable part and a mutable part. The record store represents the immutable part.\n\nThe esm/esp file format contains a list of records, where each record is composed of a type ID and additional data. Our world model does mirror this structure.\n\nIndividual records can by identified by a string ID, a numeric ID, a coordinate-pair or not at all (depending on the type).\n\nFor each type of record we have a struct in the ESM namespace: http://zinnschlag.github.com/openmw/namespaceESM.html\n\nFor each type of record we also have a list of these records, instantiating the MWWorld::Store template. There are some variations depending on the record type.\n\nThe class implementing the record store is named ESMStore (in the MWWorld namespace). The ESMStore merges records from multiple ESM/ESP files into a single store. The merging implementation can vary depending on the record type.\n\nA const reference to the current ESMStore can be obtained from the MWBase::World class instance.\n\n==Dynamic Records==\n\nSome types of records can be generated dynamically during gameplay and then accessed via the record store like any other record.\n\nExamples:\n* custom classes\n* custom enchantments\n* potions created by alchemy\n* modifications to levelled lists via the console\n\n==Cell==\n\nA [[Cells|cell]] record consists of some header-type data fields and a collection of references. Of these only the header data is stored in the record store. The collection of references is mutable and as such needs to be treated separately.\n\n==Info==\n\nFor every practical purpose each info record is a sub-records of a dialogue record. The OpenMW info storage implementation reflects this structure. The esm/esp format does not."
                    }
                ]
            },
            "226": {
                "pageid": 226,
                "ns": 0,
                "title": "Release Cycles",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "= Release cycles =\n\nThe time for a new version of OpenMW to be released may vary depending on the progress made since the last release. This document explains the workflow used to manage OpenMW versions. The word &quot;issue&quot; refers to an item in the [https://bugs.openmw.org/projects/openmw/issues issue tracker]. These items include tasks, features and bugs. Generally speaking, an issue is something that must be done to improve OpenMW's functionality. You can see which issues are planned for which OpenMW versions on the [https://bugs.openmw.org/projects/openmw/roadmap roadmap].\n\n== Normal development ==\n\nThe tasks on the roadmap are grouped by OpenMW versions. During normal development, they are two versions on the roadmap:\n\n* '''openmw-VERSION''' ''(VERSION is the version number of the upcoming release)''\n\n: This version contains short term issues planned for the next version of OpenMW.\n\n* '''openmw-future'''\n\n: This version contains long-term issues. An issue is considered long-term if it depends on other major issues or otherwise involves big changes in the engine architecture. They are moved to a specific version when they become feasible.\n\nDuring normal development, developers make pull requests on [https://github.com/zinnschlag/openmw/tree/master the <code>master</code> branch of the main repository] (if you are not familiar with pull requests, see [https://help.github.com/articles/using-pull-requests the help at GitHub]).\n\n== Pre-release period ==\n\nWhen the number of resolved features added and bugs fixed is considered sufficient for a new release, the next OpenMW version enters the Release Candidate (RC) phase. On the roadmap, unresolved issues are moved to a new OpenMW version.\n\nAt this point the roadmap shows issues for three versions:\n\n* '''openmw-VERSION''' ''(VERSION is the version number of the upcoming release)''\n\n: During pre-release period, this category contains mostly closed issues, plus those in progress that are projected to be finished by release. No new issues are added unless they fix a major bug or a regression.\n\n* '''openmw-NEXT_VERSION''' ''(NEXT_VERSION is the version number of the release following the upcoming release)''\n\n: The remaining issues that belonged to openmw-VERSION but have lesser priority are moved here. Some issues may be moved from openmw-future too.\n\n* '''openmw-future'''\n\n: Just as in normal development, this version contains issues that are considered long-term.\n\nDuring pre-release period, the branch that developers make pull requests to depends on the roadmap. Changes for issues under openmw-VERSION deserve a pull-request targeting the branch named openmw-VERSION. Other changes are merged to the <code>master</code> branch as usual.\n\n== Post-release period ==\n\nThe new version is released after all its issues on the roadmap are closed.\n\nAfter the release, the corresponding version is removed from the roadmap."
                    }
                ]
            }
        }
    }
}