Difference between revisions of "AddonsWML"
(How directory structure fills the role of an [addon] tag) |
m (→Creating add-ons in WML: Fixed some links) |
||
Line 4: | Line 4: | ||
An add-on is defined by a directory structure, there is no tag called '''[addon]'''. The directory must contain a '''_main.cfg''', and the name of the directory is treated as its '''id'''. There are different rules for add-ons that define a custom core, which are described in [[CoreWML]] and ignored for the purposes of this page. | An add-on is defined by a directory structure, there is no tag called '''[addon]'''. The directory must contain a '''_main.cfg''', and the name of the directory is treated as its '''id'''. There are different rules for add-ons that define a custom core, which are described in [[CoreWML]] and ignored for the purposes of this page. | ||
− | An add-on typically contains other files, see for example AddonStructure or BuildingCampaignsTheCampaignFile. | + | An add-on typically contains other files, see for example [[AddonStructure]] or [[BuildingCampaignsTheCampaignFile]]. |
The description of a downloaded add-on is found in '''_info.cfg''', the data for a locally authored add-on is in '''_server.cfg''' (see [[PblWML]]). | The description of a downloaded add-on is found in '''_info.cfg''', the data for a locally authored add-on is in '''_server.cfg''' (see [[PblWML]]). |
Revision as of 12:15, 23 January 2024
Contents
Creating add-ons in WML
An add-on is defined by a directory structure, there is no tag called [addon]. The directory must contain a _main.cfg, and the name of the directory is treated as its id. There are different rules for add-ons that define a custom core, which are described in CoreWML and ignored for the purposes of this page.
An add-on typically contains other files, see for example AddonStructure or BuildingCampaignsTheCampaignFile.
The description of a downloaded add-on is found in _info.cfg, the data for a locally authored add-on is in _server.cfg (see PblWML).
Which add-ons are active during gameplay
To help prevent clashes between add-ons, when starting a scenario the engine only loads the active add-ons. An add-on is active if one or more "add-on modules" is used by the game. If a game does not use any add-on module from your add-on, then your add-on won't be parsed at all. On the other hand, if the game uses any add-on module from your add-on, then your entire add-on will be parsed, relying on preprocessor defines to exclude parts that aren't relevant to the add-on module that is to be loaded.
Several toplevel tags are used to define an "add-on module":
- [era] - A multiplayer era
- [campaign] - A campaign, either single-player or multiplayer
- [scenario] - A campaign scenario
- [multiplayer] - A multiplayer scenario
- [test] - A test or demo scenario
- [modification] - A modification that can be selected in the campaign or multiplayer menu
- [resource] - A resource that can be requested by any other addon module
Common Tags and Keys
The following tags and keys are supported in most types of addon modules:
- id: The addon module's unique ID. It must be unique across all addon module types, so for example there cannot be a [scenario] and a [multiplayer] with the same ID.
- addon_min_version: The minimum version of your add-on with which this content is backwards compatible. Compared with the version string given in PblWML. If addon_min_version is not explicitly specified, it means compatible only with the same version. Clients in multiplayer must have add-on versions agreeing with the addon_min_versions of each others' content in order to play, and will be prompted to update otherwise.
- name: (translatable) The visible name for the addon module, shown in the campaign selection or multiplayer game creation menu. (Not supported for [resource] since it is never visible anywhere.)
- description: (translatable) The detailed description for the addon module, shown in the campaign selection or multiplayer game creation menu. (Also not supported for [resource], nor for [scenario] or [test].)
- define=SYMBOL When this addon module is active, the preprocessor symbol SYMBOL will be defined. See ifdef for how this can be used to isolate parts of the file from other addon modules. Besides the addon module tag, only the tags [textdomain] and [binary_path] (see BinaryPathWML) should go outside of #ifdef SYMBOL. This symbol will be defined before any .cfg is preprocessed. Note: If for some reason you don't want to place your [binary_path] outside your #ifdef SYMBOL (perhaps it's causing conflicts with other addon modules), you can use binary-path-independent paths for the textdomain and any assets that are used in the addon module tag. This looks like icon=data/add-ons/whatever/something.png – essentially, any path beginning with data/.
- [event] - An event handler that will be registered when the addon module is active. See EventWML.
- [lua] - Lua code that will be run when the addon module is loaded, before the preload event is fired. See LuaWML.
- [ai]: Defines an AI algorithm that can be selected by players at the join game screen. See here for details. This is not used in single-player.
- Note: This is not the place to define faction-specific AI parameters in an era. For that, place the [ai] tag in [multiplayer_side].
- Note: This tag may not be supported in [resource], [scenario], or [test].
- [options]: Custom options. See OptionWML for details. Note: This may not be supported in [resource], [scenario], or [test].
- [load_resource]: Indicates a resource to load when this addon module is loaded.
- id: The ID of the resource.
- [modify_unit_type] (Version 1.15.2 and later only): Changes a unit type while this modification is active. The supported attributes are:
- type : the id of the unit type to change.
- set_experience : changes the unit type's max experience.
- set_cost : changes the unit type's recruit cost.
- set_advances_to : changes the unit type's advancements.
- add_advancement : adds a (list of comma separated) unit type(s) to the possible advancements of this unit type.
- remove_advancement : removes a (list of comma separated) unit type(s) from the possible advancements of this unit type.
See Also
- BinaryPathWML - Toplevel tag to define search paths for assets.
- UnitsWML - Toplevel tag to define units and unit-related data.
- TerrainWML - Toplevel tag to define terrain types.
- TerrainGraphicsWML - Toplevel tag to define how terrain is drawn.