Difference between revisions of "BinaryPathWML"
(Added an example) |
(→Resolving paths against the binary path: New section) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 3: | Line 3: | ||
This tag is used to recognize more than one directory as containing images, music, and sound. It only has one key: | This tag is used to recognize more than one directory as containing images, music, and sound. It only has one key: | ||
− | * '''path''': a directory. When an image is not found it the normal ''images'' directory, it will be looked for in '''''path'''/images''. Similarly, music will be looked for in '''''path'''/music'', and sound in '''''path'''/sound''. | + | * '''path''': a directory. When an image is not found it the normal ''images'' directory, it will be looked for in '''''path'''/images''. Similarly, |
+ | ** music will be looked for in '''''path'''/music'', and | ||
+ | ** sound in '''''path'''/sound''. | ||
+ | ** {{DevFeature1.15|3}} For '''[scenario]map_file''' and '''[replace_map]map_file''', the file will be looked for in '''''path'''/maps''. | ||
+ | |||
Notice that '''''path''''' is still relative to the main Wesnoth directory. | Notice that '''''path''''' is still relative to the main Wesnoth directory. | ||
[binary_path] should only be used where necessary. For example a multiplayer era should have its [binary_path] inside an #ifdef MULTIPLAYER instead of outside it in order to avoid possible clashes with single-player content. | [binary_path] should only be used where necessary. For example a multiplayer era should have its [binary_path] inside an #ifdef MULTIPLAYER instead of outside it in order to avoid possible clashes with single-player content. | ||
+ | |||
+ | == Resolving paths against the binary path == | ||
+ | |||
+ | When resolving an asset path to locate the actual file on disk, the game goes through all defined [binary_path] tags in reverse order of definition. For each binary path, it checks in the following directories, in order: | ||
+ | |||
+ | * <tt><user data dir>/<binary path>/<type>/<asset path></tt> | ||
+ | * <tt><game data dir>/<binary path>/<type>/<asset path></tt> | ||
+ | * <tt><user data dir>/<binary path>/<asset path></tt> | ||
+ | * <tt><game data dir>/<binary path>/<asset path></tt> | ||
+ | |||
+ | The <tt><user data dir></tt> is the directory containing the add-ons folder, while the <tt><game data dir></tt> is the directory containing the game data itself – it contains folders <tt>sounds</tt>, <tt>images</tt>, and <tt>data</tt>, at minimum. The <tt><binary path></tt> is the path defined in [binary_path] while the <tt><asset path></tt> is the path being resolved. Finally, <tt><type></tt> is the type of asset being resolved, usually one of <tt>images</tt>, <tt>sounds</tt>, <tt>music</tt>, or <tt>maps</tt>. Lua can define additional types as well. | ||
+ | |||
+ | Assuming you have loaded the default core, the penultimate binary path to be checked in this process is <tt>data/core</tt>, meaning that built-in assets can be overridden by an add-on simply by creating a file with the same asset path in the add-on's binary path. This binary path is defined by a [binary_path] tag in <tt><game data dir>/data/_main.cfg</tt>. It is expected that alternate cores would define a similar path. | ||
+ | |||
+ | The final binary path to be checked is the empty string, which means that if an asset is not found in any of the paths defined by [binary_path], then the game checks in the following four directories as a last resort: | ||
+ | |||
+ | * <tt><user data dir>/<type>/<asset path></tt> | ||
+ | * <tt><game data dir>/<type>/<asset path></tt> | ||
+ | * <tt><user data dir>/<asset path></tt> | ||
+ | * <tt><game data dir>/<asset path></tt> | ||
+ | |||
+ | This behaviour means that you can build what is called a "binary path independent path" by specifying the path relative to either the <tt><user data dir></tt> or the <tt><game data dir></tt>. These paths are used in contexts where there is no guarantee what the active binary path stack will be, such as [[AchievementsWML]] or the saved game cache. | ||
== Example == | == Example == | ||
Line 12: | Line 38: | ||
To enable the game to find images, sounds and music in the add-on MyAddOn: | To enable the game to find images, sounds and music in the add-on MyAddOn: | ||
− | + | <syntaxhighlight lang=wml> | |
− | + | [binary_path] | |
− | + | path=data/add-ons/MyAddOn | |
+ | [/binary_path] | ||
+ | </syntaxhighlight> | ||
When the game looks for an image '''''units/humans/footman.png''''', it'll now be able to find and use the file '''''MyAddOn/images/units/humans/footman.png'''''. | When the game looks for an image '''''units/humans/footman.png''''', it'll now be able to find and use the file '''''MyAddOn/images/units/humans/footman.png'''''. |
Latest revision as of 14:35, 23 July 2023
Contents
the toplevel [binary_path] tag
This tag is used to recognize more than one directory as containing images, music, and sound. It only has one key:
- path: a directory. When an image is not found it the normal images directory, it will be looked for in path/images. Similarly,
- music will be looked for in path/music, and
- sound in path/sound.
- (Version 1.15.3 and later only) For [scenario]map_file and [replace_map]map_file, the file will be looked for in path/maps.
Notice that path is still relative to the main Wesnoth directory.
[binary_path] should only be used where necessary. For example a multiplayer era should have its [binary_path] inside an #ifdef MULTIPLAYER instead of outside it in order to avoid possible clashes with single-player content.
Resolving paths against the binary path
When resolving an asset path to locate the actual file on disk, the game goes through all defined [binary_path] tags in reverse order of definition. For each binary path, it checks in the following directories, in order:
- <user data dir>/<binary path>/<type>/<asset path>
- <game data dir>/<binary path>/<type>/<asset path>
- <user data dir>/<binary path>/<asset path>
- <game data dir>/<binary path>/<asset path>
The <user data dir> is the directory containing the add-ons folder, while the <game data dir> is the directory containing the game data itself – it contains folders sounds, images, and data, at minimum. The <binary path> is the path defined in [binary_path] while the <asset path> is the path being resolved. Finally, <type> is the type of asset being resolved, usually one of images, sounds, music, or maps. Lua can define additional types as well.
Assuming you have loaded the default core, the penultimate binary path to be checked in this process is data/core, meaning that built-in assets can be overridden by an add-on simply by creating a file with the same asset path in the add-on's binary path. This binary path is defined by a [binary_path] tag in <game data dir>/data/_main.cfg. It is expected that alternate cores would define a similar path.
The final binary path to be checked is the empty string, which means that if an asset is not found in any of the paths defined by [binary_path], then the game checks in the following four directories as a last resort:
- <user data dir>/<type>/<asset path>
- <game data dir>/<type>/<asset path>
- <user data dir>/<asset path>
- <game data dir>/<asset path>
This behaviour means that you can build what is called a "binary path independent path" by specifying the path relative to either the <user data dir> or the <game data dir>. These paths are used in contexts where there is no guarantee what the active binary path stack will be, such as AchievementsWML or the saved game cache.
Example
To enable the game to find images, sounds and music in the add-on MyAddOn:
[binary_path]
path=data/add-ons/MyAddOn
[/binary_path]
When the game looks for an image units/humans/footman.png, it'll now be able to find and use the file MyAddOn/images/units/humans/footman.png.