ModificationWML - Revision history

Shiki: spelling

2024-07-26T22:40:58Z

spelling

← Older revision		Revision as of 22:40, 26 July 2024
Line 16:		Line 16:
	* '''ignore_incompatible_era''': same as ignore_incompatible_scenario, but for eras.		* '''ignore_incompatible_era''': same as ignore_incompatible_scenario, but for eras.
	* '''ignore_incompatible_modification''': same as ignore_incompatible_scenario, but for modifications.		* '''ignore_incompatible_modification''': same as ignore_incompatible_scenario, but for modifications.
	* '''require_modification''': a boolean value; if set to yes, all players have to have this modification installed to join the game. Default no in older ~~version~~ and yes since 1.18.		* '''require_modification''': a boolean value; if set to yes, all players have to have this modification installed to join the game. Default no in older versions and yes since 1.18.

	== The [resource] toplevel tag ==		== The [resource] toplevel tag ==

Shiki: document require_resource and default change in require_modification

2024-07-26T22:40:22Z

document require_resource and default change in require_modification

← Older revision		Revision as of 22:40, 26 July 2024
Line 16:		Line 16:
	* '''ignore_incompatible_era''': same as ignore_incompatible_scenario, but for eras.		* '''ignore_incompatible_era''': same as ignore_incompatible_scenario, but for eras.
	* '''ignore_incompatible_modification''': same as ignore_incompatible_scenario, but for modifications.		* '''ignore_incompatible_modification''': same as ignore_incompatible_scenario, but for modifications.
	* '''require_modification''': a boolean value; if set to yes, all players have to have this modification installed to join the game. Default no.		* '''require_modification''': a boolean value; if set to yes, all players have to have this modification installed to join the game. Default no in older version and yes since 1.18.

	== The [resource] toplevel tag ==		== The [resource] toplevel tag ==
Line 22:		Line 22:
	{{DevFeature1.13\|2}}		{{DevFeature1.13\|2}}

	The '''[resource]''' toplevel tag is another type of [[AddonsWML\|addon module tag]] which is similar to '''[modification]''' but is invisible to the player. It can only be loaded on developer request, by the '''[load_resource]''' tag. It supports most of the common [[AddonsWML\|addon module keys and tags]]. Besides that, there ~~are no additional keys or tags supported in~~ '''~~[resource]~~'''.		The '''[resource]''' toplevel tag is another type of [[AddonsWML\|addon module tag]] which is similar to '''[modification]''' but is invisible to the player. It can only be loaded on developer request, by the '''[load_resource]''' tag. It supports most of the common [[AddonsWML\|addon module keys and tags]]. Besides that, there is the '''require_resource''' key which defaults to yes.

Atreides: /* The [modification] toplevel tag */

2024-01-18T19:17:48Z

The [modification] toplevel tag

← Older revision		Revision as of 19:17, 18 January 2024
Line 6:		Line 6:
	The following keys/tags are recognized for '''[modification]''', in addition to all the common [[AddonsWML\|addon module keys and tags]]:		The following keys/tags are recognized for '''[modification]''', in addition to all the common [[AddonsWML\|addon module keys and tags]]:

	* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''.		* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''. hybrid equals mp + sp. N.B. If omitted it defaults to hybrid. Availability in SP also depends on whether or not modification tag is inside a multiplayer define. There is a bug where one can use modifications (not having type=mp) inside such a define by loading multiplayer and returning and then selecting campaign from the main screen.
	* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.		* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.
	* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.		* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.

Celtic Minstrel: Delete common keys and tags documented in AddonsWML

2023-03-26T18:00:04Z

Delete common keys and tags documented in AddonsWML

← Older revision		Revision as of 18:00, 26 March 2023
Line 2:		Line 2:
	== The [modification] toplevel tag ==		== The [modification] toplevel tag ==

	This tag describes an SP or MP modification. A modification is, practically speaking, a bunch of events which get included into the scenario if the modification is enabled.		This [[AddonsWML\|addon module]] tag describes an SP or MP modification. A modification is, practically speaking, a bunch of events which get included into the scenario if the modification is enabled.

	The following keys/tags are recognized for '''[modification]''':		The following keys/tags are recognized for '''[modification]''', in addition to all the common [[AddonsWML\|addon module keys and tags]]:

	* '''id''': identifier for the modification. Must be unique.
	* '''name''': the name of the modification, as displayed to the user.
	* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''.		* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''.
	* '''description''': a brief description for the modification.
	* '''define'''='''''MODIFICATION_SYMBOL''''' when this addon is active, the preprocessor symbol '''''MODIFICATION_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the modification file from other modifications or campaigns. Only the tags '''[modification]''', '''[textdomain]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''MODIFICATION_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''MODIFICATION_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.
	* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.		* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.
	* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.		* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.
Line 21:		Line 17:
	* '''ignore_incompatible_modification''': same as ignore_incompatible_scenario, but for modifications.		* '''ignore_incompatible_modification''': same as ignore_incompatible_scenario, but for modifications.
	* '''require_modification''': a boolean value; if set to yes, all players have to have this modification installed to join the game. Default no.		* '''require_modification''': a boolean value; if set to yes, all players have to have this modification installed to join the game. Default no.
	* '''addon_min_version''': {{DevFeature1.13\|0}} the minimum version of your add-on with which this content is backwards compatible. Compare with the version string given in [[PblWML]]. Clients in multiplayer must have add-on versions agreeing with the ''addon_min_versions'' of eachothers content in order to play, and will be prompted to update otherwise.
	* '''[event]''': any [event] children written inside the [modification] tag will get included into scenarios that are played with this modification enabled. See [[EventWML]].
	* '''[lua]''': any [lua] children written inside the [modification] tag will get included into scenarios that are played with this modification enabled.
	* '''[options]''': custom options. See [[OptionWML]] for details.
	* '''[ai]''': Defines an AI algorithm that can be selected by players at the join game screen. See [[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Top-level_Elements\|here]] for details.
	* '''[modify_unit_type]''' {{DevFeature1.15\|2}}: Changes a unit type while this modification is active. This tag is also supported in [campaign] and [era]. 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.

	== The [resource] toplevel tag ==		== The [resource] toplevel tag ==
Line 38:		Line 22:
	{{DevFeature1.13\|2}}		{{DevFeature1.13\|2}}

	The '''[resource]''' toplevel tag is ~~similar to~~ [~~modification] in that it contains~~ [~~event~~] ~~and [lua~~] ~~tags~~ which ~~are then copied into the scenario. However, unlike~~ [modification]~~, resources defined this way are completely hidden from~~ the ~~user~~. ~~To load a resource~~, ~~use~~ '''[load_resource] ~~id=<i><resource id></i>~~''' in [~~scenario],~~ [~~multiplayer~~]~~, [era], [campaign], [modification~~], or [resource].		The '''[resource]''' toplevel tag is another type of [[AddonsWML\|addon module tag]] which is similar to '''[modification]''' but is invisible to the player. It can only be loaded on developer request, by the '''[load_resource]''' tag. It supports most of the common [[AddonsWML\|addon module keys and tags]]. Besides that, there are no additional keys or tags supported in '''[resource]'''.

Celtic Minstrel: /* The [modification] top level tag */ The documentation for [ai] was misleading

2023-02-18T17:04:44Z

The [modification] top level tag: The documentation for [ai] was misleading

← Older revision		Revision as of 17:04, 18 February 2023
Line 25:		Line 25:
	* '''[lua]''': any [lua] children written inside the [modification] tag will get included into scenarios that are played with this modification enabled.		* '''[lua]''': any [lua] children written inside the [modification] tag will get included into scenarios that are played with this modification enabled.
	* '''[options]''': custom options. See [[OptionWML]] for details.		* '''[options]''': custom options. See [[OptionWML]] for details.
	* '''[ai]''': See [[~~AiWML~~]] for details.		* '''[ai]''': Defines an AI algorithm that can be selected by players at the join game screen. See [[Wesnoth_AI_Framework#The_.5Bai.5D_Tag_.E2.80.94_Top-level_Elements\|here]] for details.
	* '''[modify_unit_type]''' {{DevFeature1.15\|2}}: Changes a unit type while this modification is active. This tag is also supported in [campaign] and [era]. The supported attributes are:		* '''[modify_unit_type]''' {{DevFeature1.15\|2}}: Changes a unit type while this modification is active. This tag is also supported in [campaign] and [era]. The supported attributes are:
	** '''type''' : the id of the unit type to change.		** '''type''' : the id of the unit type to change.

Toranks at 20:20, 3 February 2023

2023-02-03T20:20:16Z

← Older revision		Revision as of 20:20, 3 February 2023
Line 10:		Line 10:
	* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''.		* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''.
	* '''description''': a brief description for the modification.		* '''description''': a brief description for the modification.
	* '''define'''='''''MODIFICATION_SYMBOL''''' when this addon is active, the preprocessor symbol '''''MODIFICATION_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the modification file from other modifications or campaigns. Only the tags '''[modification]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''MODIFICATION_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''MODIFICATION_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.		* '''define'''='''''MODIFICATION_SYMBOL''''' when this addon is active, the preprocessor symbol '''''MODIFICATION_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the modification file from other modifications or campaigns. Only the tags '''[modification]''', '''[textdomain]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''MODIFICATION_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''MODIFICATION_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.
	* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.		* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.
	* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.		* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.

Toranks: [modification] supports define key

2023-01-29T17:45:18Z

[modification] supports define key

← Older revision		Revision as of 17:45, 29 January 2023
Line 10:		Line 10:
	* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''.		* '''type''': where the modification will be available for playing. Possible values are ''sp'', ''mp'', and ''hybrid''.
	* '''description''': a brief description for the modification.		* '''description''': a brief description for the modification.
			* '''define'''='''''MODIFICATION_SYMBOL''''' when this addon is active, the preprocessor symbol '''''MODIFICATION_SYMBOL''''' will be defined. See '''#ifdef''' in [[PreprocessorRef]] for how this can be used to isolate parts of the modification file from other modifications or campaigns. Only the tags '''[modification]''' and '''[binary_path]''' (see [[BinaryPathWML]]) should go outside of '''#ifdef ''MODIFICATION_SYMBOL'''''. This symbol will be defined ''before'' any .cfg is preprocessed. Important note: starting with 1.7.13, [binary_path] does no longer need to be outside of the '''#ifdef ''MODIFICATION_SYMBOL''''' block to make custom binary data available, which could easily cause overwrites. E.g. icon=data/add-ons/whatever/something.png is supposed to work. This seems to have been a bug since at least BfW 1.0 which means that practically all available examples of user made add-ons are wrong in this aspect.
	* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.		* '''allow_scenario''': a list of scenario ids. Only the scenarios with matching ids will be allowed to be played with this modification.
	* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.		* '''disallow_scenario''': a list of scenario ids. Only the scenarios with matching ids will not be allowed to be played with this modification. Cannot be used in parallel with allow_scenario.

Soliton: /* The [modification] toplevel tag */

2022-07-19T13:30:13Z

The [modification] toplevel tag

← Older revision		Revision as of 13:30, 19 July 2022
Line 30:		Line 30:
	** '''set_cost''' : changes the unit type's recruit cost.		** '''set_cost''' : changes the unit type's recruit cost.
	** '''set_advances_to''' : changes the unit type's advancements.		** '''set_advances_to''' : changes the unit type's advancements.
	** '''add_advancement''' : adds a unit type to the possible advancements of this unit type.		** '''add_advancement''' : adds a (list of comma separated) unit type(s) to the possible advancements of this unit type.
	** '''remove_advancement''' : removes a unit type from 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.

	== The [resource] toplevel tag ==		== The [resource] toplevel tag ==

Shiki at 05:27, 24 February 2020

2020-02-24T05:27:46Z

← Older revision		Revision as of 05:27, 24 February 2020
Line 31:		Line 31:
	** '''set_advances_to''' : changes the unit type's advancements.		** '''set_advances_to''' : changes the unit type's advancements.
	** '''add_advancement''' : adds a unit type to the possible advancements of this unit type.		** '''add_advancement''' : adds a unit type to the possible advancements of this unit type.
	** '''remove_advancement''' : removes a unit type to the possible advancements of this unit type.		** '''remove_advancement''' : removes a unit type from the possible advancements of this unit type.

	== The [resource] toplevel tag ==		== The [resource] toplevel tag ==

Laela: /* The [modification] toplevel tag */

2019-12-05T15:50:27Z

The [modification] toplevel tag

← Older revision		Revision as of 15:50, 5 December 2019
Line 25:		Line 25:
	* '''[options]''': custom options. See [[OptionWML]] for details.		* '''[options]''': custom options. See [[OptionWML]] for details.
	* '''[ai]''': See [[AiWML]] for details.		* '''[ai]''': See [[AiWML]] for details.
	* '''[modify_unit_type]''' {{DevFeature1.15\|2}}: Changes a unit type while this modification is active ~~the~~ supported attributes are:		* '''[modify_unit_type]''' {{DevFeature1.15\|2}}: Changes a unit type while this modification is active. This tag is also supported in [campaign] and [era]. The supported attributes are:
	** '''type''' : the id of the unit type to change.		** '''type''' : the id of the unit type to change.
	** '''set_experience''' : changes the unit type's max experience.		** '''set_experience''' : changes the unit type's max experience.