The Battle for Wesnoth Wiki - User contributions [en]

User:Alink

2012-04-26T16:54:46Z

Alink:

I joined the project in 2007 as a coder.
I mainly worked on:

* Optimizations: graphics(engine and SDL), pathfinding, caching and loading/parsing data.

* Mouse interface on the main view: attack direction system, most info displayed on
path and units.

* Various pathfinding features, including some specific to MP (fog of war, out-of-sync), also handling teleport ability.

* Map view: lighting system, animated terrains perfomance, zoom and z-order issues. Full map screenshot and minimap scaling.

* Help system: sub-sections, faster loading, and better handling of special hyperlinks.

* Sidebar: readability improvements, better tooltips, also made clickable to open help)

* Attack window: readability improvements (central attack type, colors)

* Menu (GUI1): text filters in few places, some columns sorting etc.

* Map editor: map building improvements and few interface features.

* Various mouse shortcuts: middle-click on scrollbar (linux-like), right-click outside to close dialog, new middle-click map-scrolling.

* Some Image Path Functions.

* Many debug commands: show redraw(:sunset), terrain layers (:layers, :foreground), command alias(:alias), custom command hotkey (:command), benchmark, level-selection, discover hidden units, change time of day

* Experiment to convert the SDL engine to OpenGL, which works and is already faster on decent GPU. In pause for now. Wesnoth is currently used by a lot of different systems and hardwares (including mobile devices). I didn't want to cut some of them or split the codebase. The conversion to OpenGL is already a lot of work, and the compatibility burden is a bit too much for a one-man team. The OGL branch is still there and I might come back to it when I have time and maybe more testers.

ImagePathFunctions

2011-12-16T21:21:44Z

Alink: add ~MASK() doc

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

== Team-Color Function ==
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

=== Syntax ===
'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Re-Color Function ==
May be used to change some colors in an image.
=== Syntax ===
'''~RC(''' ''source color palette'' '''>''' ''color range ID'' ''')'''
*''source color palette'' - the first parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.
*''color range ID'' - this is the second parameter, signifying the ID of a color range defined in the file ''data/core/team-colors.cfg'' (or it may be a custom ID for a color range defined locally).

=== Example ===
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

== Palette-switch Function ==
May be used to change colors in an image following the specifications of a source and target (new) palette.
=== Syntax ===
'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

== Flip Function ==
May be used to flip an image horizontally and/or vertically
=== Syntax ===
'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizantally.
*if the argument list is empty, the image will only be flipped horizontally.

== Greyscale Function ==
May be used to greyscale the image (turn to black and white)
=== Syntax ===
'''~GS( )'''

== Crop Function ==
Extracts a rectangular section of an image file.
=== Syntax ===
'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width.
* ''height'': height of the selected region. Must be less than or equal to the original image's height.

== Blit Function ==
{{DevFeature1.9}}
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)
=== Syntax ===
'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. Must be greater or equal than zero. If missing assume (0,0).

== Mask Function ==
{{DevFeature1.9}}
Remove parts of the main image using the parameter image as a mask. Example: grass.png~MASK(circle.png) will give a circle of grass.
=== Syntax ===
'''~MASK(mask,x,y)'''
* ''mask'': an image file used as mask, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to put the mask. Parts ouside of the mask are considered transparent. If missing assume (0,0).

Only the alpha channel of the mask is used and each alpha value will be the maximum alpha of the resulting image. This means that the fully-transparent parts of the mask will erase the corresponding parts of the image, but also that a semi-transparent mask will create a semi-transparent image.

== Color-shift function ==
Performs simple per-channel color shifts by adding the arguments to the respective color channels.
=== Syntax ===
''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

== Lightmap color-shift function ==
{{DevFeature1.9}}
Performs per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

=== Syntax ===
'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully gray image (RGB = 128,128,128) and any non-gray pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

== Image-scaling function ==
Scales a graphic up or down.
=== Syntax ===

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr.

== Opacity modifying function ==
Changes an image's opacity at render time.
=== Syntax ===

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

== Blurring function ==
Blurs a graphic at render time using the same algorithm used for in-game dialogs.
=== Syntax ===

'''~BL( ''radius'' )'''

== Overlay function ==
{{DevFeature1.9}}
Puts a time-of-day overlay on the image.
=== Syntax ===

'''~LIGHTEN()'''

'''~DARKEN()'''

== Background coloring function ==
{{DevFeature1.9}}
Sets the color of all the (semi-)transparent pixels of the image.
=== Syntax ===

'''~BG(r,g,b)'''

== Null function ==
Does nothing.
=== Syntax ===

'''~NOP()'''

== Precedence of Functions ==

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like "units/elves-wood/fighter.png~CROP(0,0,20,20)~CROP(10,10,10,10)" would result in taking a crop of the rectangle x=20;y=20;w=40;h=40 and then taking a crop from ''that'' rectangle as x=10;y=10;w=10;h=10 resulting in the area x=30;y=30;w=10;h=10 from the original graphic.

[[Category:WML Reference]]

ImagePathFunctions

2011-12-16T21:01:05Z

Alink: /* Lightmap color-shift function */ fix 1.9 tag newline

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

== Team-Color Function ==
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

=== Syntax ===
'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Re-Color Function ==
May be used to change some colors in an image.
=== Syntax ===
'''~RC(''' ''source color palette'' '''>''' ''color range ID'' ''')'''
*''source color palette'' - the first parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.
*''color range ID'' - this is the second parameter, signifying the ID of a color range defined in the file ''data/core/team-colors.cfg'' (or it may be a custom ID for a color range defined locally).

=== Example ===
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

== Palette-switch Function ==
May be used to change colors in an image following the specifications of a source and target (new) palette.
=== Syntax ===
'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

== Flip Function ==
May be used to flip an image horizontally and/or vertically
=== Syntax ===
'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizantally.
*if the argument list is empty, the image will only be flipped horizontally.

== Greyscale Function ==
May be used to greyscale the image (turn to black and white)
=== Syntax ===
'''~GS( )'''

== Crop Function ==
Extracts a rectangular section of an image file.
=== Syntax ===
'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width.
* ''height'': height of the selected region. Must be less than or equal to the original image's height.

== Blit Function ==
{{DevFeature1.9}}
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)
=== Syntax ===
'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. Must be greater or equal than zero. If missing assume (0,0).

== Color-shift function ==
Performs simple per-channel color shifts by adding the arguments to the respective color channels.
=== Syntax ===
''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

== Lightmap color-shift function ==
{{DevFeature1.9}} Performs per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

=== Syntax ===
'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully gray image (RGB = 128,128,128) and any non-gray pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

== Image-scaling function ==
Scales a graphic up or down.
=== Syntax ===

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr.

== Opacity modifying function ==
Changes an image's opacity at render time.
=== Syntax ===

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

== Blurring function ==
Blurs a graphic at render time using the same algorithm used for in-game dialogs.
=== Syntax ===

'''~BL( ''radius'' )'''

== Overlay function ==
{{DevFeature1.9}}
Puts a time-of-day overlay on the image.
=== Syntax ===

'''~LIGHTEN()'''

'''~DARKEN()'''

== Background coloring function ==
{{DevFeature1.9}}
Sets the color of all the (semi-)transparent pixels of the image.
=== Syntax ===

'''~BG(r,g,b)'''

== Null function ==
Does nothing.
=== Syntax ===

'''~NOP()'''

== Precedence of Functions ==

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like "units/elves-wood/fighter.png~CROP(0,0,20,20)~CROP(10,10,10,10)" would result in taking a crop of the rectangle x=20;y=20;w=40;h=40 and then taking a crop from ''that'' rectangle as x=10;y=10;w=10;h=10 resulting in the area x=30;y=30;w=10;h=10 from the original graphic.

[[Category:WML Reference]]

ImagePathFunctions

2011-12-16T20:59:44Z

Alink: /* Lightmap color-shift function */ add 1.9 tag to ~L()

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

== Team-Color Function ==
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

=== Syntax ===
'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Re-Color Function ==
May be used to change some colors in an image.
=== Syntax ===
'''~RC(''' ''source color palette'' '''>''' ''color range ID'' ''')'''
*''source color palette'' - the first parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.
*''color range ID'' - this is the second parameter, signifying the ID of a color range defined in the file ''data/core/team-colors.cfg'' (or it may be a custom ID for a color range defined locally).

=== Example ===
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

== Palette-switch Function ==
May be used to change colors in an image following the specifications of a source and target (new) palette.
=== Syntax ===
'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

== Flip Function ==
May be used to flip an image horizontally and/or vertically
=== Syntax ===
'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizantally.
*if the argument list is empty, the image will only be flipped horizontally.

== Greyscale Function ==
May be used to greyscale the image (turn to black and white)
=== Syntax ===
'''~GS( )'''

== Crop Function ==
Extracts a rectangular section of an image file.
=== Syntax ===
'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width.
* ''height'': height of the selected region. Must be less than or equal to the original image's height.

== Blit Function ==
{{DevFeature1.9}}
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)
=== Syntax ===
'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. Must be greater or equal than zero. If missing assume (0,0).

== Color-shift function ==
Performs simple per-channel color shifts by adding the arguments to the respective color channels.
=== Syntax ===
''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

== Lightmap color-shift function ==
{{DevFeature1.9}}

Performs per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

=== Syntax ===
'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully gray image (RGB = 128,128,128) and any non-gray pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

== Image-scaling function ==
Scales a graphic up or down.
=== Syntax ===

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr.

== Opacity modifying function ==
Changes an image's opacity at render time.
=== Syntax ===

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

== Blurring function ==
Blurs a graphic at render time using the same algorithm used for in-game dialogs.
=== Syntax ===

'''~BL( ''radius'' )'''

== Overlay function ==
{{DevFeature1.9}}
Puts a time-of-day overlay on the image.
=== Syntax ===

'''~LIGHTEN()'''

'''~DARKEN()'''

== Background coloring function ==
{{DevFeature1.9}}
Sets the color of all the (semi-)transparent pixels of the image.
=== Syntax ===

'''~BG(r,g,b)'''

== Null function ==
Does nothing.
=== Syntax ===

'''~NOP()'''

== Precedence of Functions ==

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like "units/elves-wood/fighter.png~CROP(0,0,20,20)~CROP(10,10,10,10)" would result in taking a crop of the rectangle x=20;y=20;w=40;h=40 and then taking a crop from ''that'' rectangle as x=10;y=10;w=10;h=10 resulting in the area x=30;y=30;w=10;h=10 from the original graphic.

[[Category:WML Reference]]

ImagePathFunctions

2011-12-16T20:54:13Z

Alink: /* Syntax */ remove incorrect mention about precedence

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

== Team-Color Function ==
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

=== Syntax ===
'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Re-Color Function ==
May be used to change some colors in an image.
=== Syntax ===
'''~RC(''' ''source color palette'' '''>''' ''color range ID'' ''')'''
*''source color palette'' - the first parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.
*''color range ID'' - this is the second parameter, signifying the ID of a color range defined in the file ''data/core/team-colors.cfg'' (or it may be a custom ID for a color range defined locally).

=== Example ===
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

== Palette-switch Function ==
May be used to change colors in an image following the specifications of a source and target (new) palette.
=== Syntax ===
'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

== Flip Function ==
May be used to flip an image horizontally and/or vertically
=== Syntax ===
'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizantally.
*if the argument list is empty, the image will only be flipped horizontally.

== Greyscale Function ==
May be used to greyscale the image (turn to black and white)
=== Syntax ===
'''~GS( )'''

== Crop Function ==
Extracts a rectangular section of an image file.
=== Syntax ===
'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width.
* ''height'': height of the selected region. Must be less than or equal to the original image's height.

== Blit Function ==
{{DevFeature1.9}}
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)
=== Syntax ===
'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. Must be greater or equal than zero. If missing assume (0,0).

== Color-shift function ==
Performs simple per-channel color shifts by adding the arguments to the respective color channels.
=== Syntax ===
''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

== Lightmap color-shift function ==
Perform per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

=== Syntax ===
'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully gray image (RGB = 128,128,128) and any non-gray pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

== Image-scaling function ==
Scales a graphic up or down.
=== Syntax ===

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr.

== Opacity modifying function ==
Changes an image's opacity at render time.
=== Syntax ===

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

== Blurring function ==
Blurs a graphic at render time using the same algorithm used for in-game dialogs.
=== Syntax ===

'''~BL( ''radius'' )'''

== Overlay function ==
{{DevFeature1.9}}
Puts a time-of-day overlay on the image.
=== Syntax ===

'''~LIGHTEN()'''

'''~DARKEN()'''

== Background coloring function ==
{{DevFeature1.9}}
Sets the color of all the (semi-)transparent pixels of the image.
=== Syntax ===

'''~BG(r,g,b)'''

== Null function ==
Does nothing.
=== Syntax ===

'''~NOP()'''

== Precedence of Functions ==

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like "units/elves-wood/fighter.png~CROP(0,0,20,20)~CROP(10,10,10,10)" would result in taking a crop of the rectangle x=20;y=20;w=40;h=40 and then taking a crop from ''that'' rectangle as x=10;y=10;w=10;h=10 resulting in the area x=30;y=30;w=10;h=10 from the original graphic.

[[Category:WML Reference]]

ImagePathFunctions

2011-12-16T20:53:29Z

Alink: Document ~L() function

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

== Team-Color Function ==
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

=== Syntax ===
'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Re-Color Function ==
May be used to change some colors in an image.
=== Syntax ===
'''~RC(''' ''source color palette'' '''>''' ''color range ID'' ''')'''
*''source color palette'' - the first parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.
*''color range ID'' - this is the second parameter, signifying the ID of a color range defined in the file ''data/core/team-colors.cfg'' (or it may be a custom ID for a color range defined locally).

=== Example ===
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

== Palette-switch Function ==
May be used to change colors in an image following the specifications of a source and target (new) palette.
=== Syntax ===
'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

== Flip Function ==
May be used to flip an image horizontally and/or vertically
=== Syntax ===
'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizantally.
*if the argument list is empty, the image will only be flipped horizontally.

== Greyscale Function ==
May be used to greyscale the image (turn to black and white)
=== Syntax ===
'''~GS( )'''

== Crop Function ==
Extracts a rectangular section of an image file.
=== Syntax ===
'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width.
* ''height'': height of the selected region. Must be less than or equal to the original image's height.

== Blit Function ==
{{DevFeature1.9}}
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)
=== Syntax ===
'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. Must be greater or equal than zero. If missing assume (0,0).

== Color-shift function ==
Performs simple per-channel color shifts by adding the arguments to the respective color channels.
=== Syntax ===
''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

Any color-shift is performed before changing opacity or desaturating the graphic (see ~O() and ~GS()).

== Lightmap color-shift function ==
Perform per-pixel and per-channel color shifts using another image (a "lightmap") as source, allowing to create textured light effects.

=== Syntax ===
'''~L(lightmap)'''

For each pixel of the original image, it checks the RGB values from the corresponding pixel of the lightmap, slightly transform them, then add these values to the original pixel.

The transformation involved is done to convert the (0,255) spectrum to (-255,255), allowing to add or subtract color. The formula is (x-128)*2, which means that 0 gives -256, 128 gives 0 and 255 gives 254. So, the no-effect lightmap is a fully gray image (RGB = 128,128,128) and any non-gray pixel will shift the colors of the original.

Note that the lightmap will be scaled to the same dimensions as the original image.

== Image-scaling function ==
Scales a graphic up or down.
=== Syntax ===

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr.

== Opacity modifying function ==
Changes an image's opacity at render time.
=== Syntax ===

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

== Blurring function ==
Blurs a graphic at render time using the same algorithm used for in-game dialogs.
=== Syntax ===

'''~BL( ''radius'' )'''

== Overlay function ==
{{DevFeature1.9}}
Puts a time-of-day overlay on the image.
=== Syntax ===

'''~LIGHTEN()'''

'''~DARKEN()'''

== Background coloring function ==
{{DevFeature1.9}}
Sets the color of all the (semi-)transparent pixels of the image.
=== Syntax ===

'''~BG(r,g,b)'''

== Null function ==
Does nothing.
=== Syntax ===

'''~NOP()'''

== Precedence of Functions ==

All functions are applied in left-to-right order, with the exception of RC(), TC() and PAL() which are applied always before any other functions. Standard team coloring for a unit is applied after all custom RC(), TC() and PAL() functions but before any other functions.
That is, stuff like "units/elves-wood/fighter.png~CROP(0,0,20,20)~CROP(10,10,10,10)" would result in taking a crop of the rectangle x=20;y=20;w=40;h=40 and then taking a crop from ''that'' rectangle as x=10;y=10;w=10;h=10 resulting in the area x=30;y=30;w=10;h=10 from the original graphic.

[[Category:WML Reference]]

TerrainGraphicsWML

2010-08-29T12:44:18Z

Alink: /* The toplevel [terrain_graphics] tag */ update [variant] for 1.9

{{WML Tags}}

{{Needs update}}

== The toplevel [terrain_graphics] tag ==

For information about the multi-hex tiling system, see [[MultiHexTutorial]]

In terrain graphics, all images are assumed to be .png and relative to images/terrain/.
For example, writing 'image=grassland' means that the image file is images/terrain/grassland.png.

The multi-hex tiling system adds a new top-level element to WML, [terrain_graphics].
A building rule is used to specify images to place when terrains are in a certain formation.
When a building rule is applied to a map, it is applied once to each coordinate on the map;
when it is applied to a coordinate then that coordinate is considered the ''base''.
All locations in '''[terrain_graphics]''' are relative to the base.

The following keys/tags are recognized:
* '''[tile]''': whenever a building rule is applied, each [tile] tag corresponds to a tile on the map. The corresponding tile must match each condition contained in [tile] for the [tile] tag to match. All [tile] tags must match in order for a rule to match. If the rule for a [tile] tag is applied, each action within [tile] will be executed on the tile corresponding to that [tile] tag
** '''x''','''y''': standard coordinates - the location of the corresponding tile relative to the base.
** '''pos''': a shortcut to specifying coordinates. Used in combination with ''map''
** '''type''': a comma-separated list of terrain codes (See [[TerrainWML]], data/terrain.cfg). In order for a tile to match this condition, it must be one of the terrains specified. However, if the string is preceded by "!", the terrain must not be listed in order to match. If the string is '*', or if it is empty, any tile matches.
** '''set_flag''': a comma-separated list of strings. Attaches flags from that list to the corresponding tile if the rule matches. The only difference a flag makes is being detected by ''has_flag'' and ''no_flag'' in [tile]. This is determined by the order of the [terrain_graphics] tags; a tag after another one cannot influence it. See also ''has_flag'', ''no_flag''
** '''has_flag''': a comma-separated list of strings. Matches if all flags in that list are attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** '''no_flag''': a comma-separated list of strings. Matches if none of the flags in that list are attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** '''set_no_flag''': {{DevFeature1.9}} helper combining ''set_flag'' and ''no_flag''. Same effect as using them with the same flags. Added because it's the most common use; ''set_flag'' or ''no_flag'' can still be used to add flags in one group only.
** '''[image]''': images specified as a subtag to '''[tile]''' sets the images for a single tile.
*** '''layer''': an integer, usually negative. The more negative it is, the earlier it is drawn, and thus the farther "back" it is when compositing the terrain images together.
*** '''name''': the image to apply on this tile if appropriate
*** '''base''': specifies the point at which the image is considered to be for layering purposes. ''base'' is specified as '''x,y''' where x and y indicate distances in pixels from the top-left corner of the '''image'''. This is translated to a certain pixel on the map, and all images with the ''base'' attribute are drawn from top-to-bottom in terms of these specified pixel positions '''on the map'''.
*** '''[variant]''': an alternate image to use for differing times of day
**** '''tod''': the time of day for which this variant applies. {{DevFeature1.9}} Accepts a comma separated list of times of day.
**** '''name''': the image to apply on this tile if appropriate
* '''[image]''': image may also be used directly in the rule, to specify multihex images.
* '''probability''': the percent probability for each position that if the position matches, then the rule will be applied. Default is 100(%). See [[TerrainGraphicsTutorial#Cumulative_Probabilities|Cumulative_Probabilities]] for mathematical complications.
* '''rotations''': 6 comma(''',''') separated input strings. A rule that contains this key is not actually checked against the terrain; it instead is used as a template to create 6 new rules, each corresponding to a rotated version of the current rule. Whenever a rotated version is applied, instances of @(at-sign)R0, @R1, ... @R6 in attributes in the [terrain_graphics] tag will be adjusted by the corresponding amount and replaced with the letters specified by that numbered rotation in the ''rotations'' list. Each value corresponds to the rotated version that is -Pi/3 (60° clockwise) from the previous version; the first value corresponds to the unrotated version. For example, if '''rotations=n,ne,se,s,sw,nw''' and it is being rotated 120°, then "@R0"->"@R2"->"se", "@R1"->"@R3"->"s", ... "@R6"->"@R1"->"ne". Basically the important thing is that this lets the rule be applied in any of the six hex-directions, allowing you to adjust the name of the image files automatically.
* '''set_flag''','''has_flag''', '''no_flag''': shortcuts to putting these in the [tile] subtags; unbound attributes will apply to all [tile] subtags.
* '''map''': a shortcut for defining [tile] tags with ''type'' conditions. Inputs a multi-line string value visually describing the map. The lines are cut into words of 4 characters, which correspond to [tile] tags. The line types alternate between lines corresponding to relatively even-abciss tiles and lines preceded by two spaces corresponding to relatively odd-abciss tiles. Every two lines represent 1 row on the map.

=== Words ===

A ''word'' is a 4-character shortcut to a [tile] tag. There are different types of words:
* Usually a word is interpreted as being the input to the ''type'' key of the corresponding [tile]. That is, it creates a [tile] with the attribute '''type=''word'''''.
* A word can also be a digit followed by 3 spaces. In this case, it is a shortcut to the [tile] with the attribute '''pos=''word'''''. This is called ''anchoring''.

In 1.3, the format is basically the same but the following changes are made
* A ''word'' no longer needs to be 4 characters but is comma separated and spaces and tabs may be used for padding
* The 2 spaces for odd lines in no longer used, instead a leading comma is used on these lines (before the comma spaces and tabs are allowed for padding)
* A ''word'' may only be a dot a star or an anchor. The terrain letter format was not used and hard to support in the new engine, so that support is dropped.

== Examples ==

To define a north-south 2-tile mountain, the following syntax can be used:

[terrain_graphics]
[tile]
x=0
y=0
type=Mm
[/tile]
[tile]
x=0
y=1
type=Mm
[/tile]
no_flag="mountain-tile"
set_flag="mountain-tile"
image_background="mountain-n-s"
[/terrain_graphics]

This represents a tile T, and its 6 adjacent tiles A, in the map notation.

., ., ., .
, ., A, ., .
., A, A, .
, ., T, ., .
., A, A, .
, ., A, ., .

== See Also ==
* [[MultiHexTutorial]]
* [[ReferenceWML]]
* Ayin's [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml detailed Terrain Graphics document]
* [[TerrainGraphicsTutorial]] - First half of Ayin's document, wikified
* [[TerrainGraphicsReference]] - Second (partial) half of Ayin's document, wikified

[[Category: WML Reference]]

ImagePathFunctions

2010-08-27T19:57:27Z

Alink: Document ~BLIT

Image Path Functions provide a simple method for WML coders to alter the way their specified images will be displayed in the game. All of the function parameters are included at the end of an image path and should not contain any spaces or special characters (other than those specified here).

== Team-Color Function ==
In Wesnoth version 1.2, the only Image Path Function was '''~TC()''', which took two comma-separated parameters: the team number and the source color palette. The valid values for both of these parameters are defined in the file ''data/team-colors.cfg''

=== Syntax ===
'''~TC(''' ''team number'' ''',''' ''source color palette'' ''')'''
*''team number'' - this is the first parameter, a number 1-9 signifying the team number of a unit. Number 1 typically means the red team, 2 typically means the blue team, and so on (unless the scenario color settings for any side have been altered).
*''source color palette'' - the second parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.

== Re-Color Function ==
May be used to change some colors in an image.
=== Syntax ===
'''~RC(''' ''source color palette'' '''>''' ''color range ID'' ''')'''
*''source color palette'' - the first parameter is a source color palette, usually magenta. Do not surround this parameter with quotes.
*''color range ID'' - this is the second parameter, signifying the ID of a color range defined in the file ''data/core/team-colors.cfg'' (or it may be a custom ID for a color range defined locally).

=== Example ===
In the following example, the magenta regions in an elvish captain's image are turned a healthy shade of green:

[message]
speaker=narrator
image=units/elves-wood/captain.png~RC(magenta>green)
message=_ "Now I am on the green team."
[/message]

The IDs of the color ranges may be the lowercased English name of the palette's base color (e.g. 'red', 'brown', etc.). They may also be numeric color indices from the palette WML included with the game, but this is not recommended.

== Palette-switch Function ==
May be used to change colors in an image following the specifications of a source and target (new) palette.
=== Syntax ===
'''~PAL(''' ''source color palette'' '''>''' ''target color palette'' ''')'''
*''source color palette'' - the first parameter is a source color palette, such as magenta. Do not surround this parameter with quotes.
*''target color palette'' - the new palette to take the place of the source colors in the image.

== Flip Function ==
May be used to flip an image horizontally and/or vertically
=== Syntax ===
'''~FL(''' ''optional argument list'' ''')'''
*''vertical'' - if the string "vert" is found anywhere in the argument list, the image will be flipped vertically.
*''horizontal'' - if the string "horiz" is found anywhere in the argument list, the image will be flipped horizantally.
*if the argument list is empty, the image will only be flipped horizantally.

== Greyscale Function ==
May be used to greyscale the image (turn to black and white)
=== Syntax ===
'''~GS( )'''

== Crop Function ==
Extracts a rectangular section of an image file.
=== Syntax ===
'''~CROP(x,y,width,height)'''
* ''x'',''y'': top-left corner coordinates for the rectangular section extracted. Must be greater or equal than zero, and inside the image's bounds.
* ''width'': width of the selected region. Must be less than or equal to the original image's width.
* ''height'': height of the selected region. Must be less than or equal to the original image's height.

== Blit Function ==
{{DevFeature1.9}}
Blit the parameter image on the main image. Example: peasant.png~BLIT(hat.png,30,10)
=== Syntax ===
'''~BLIT(src,x,y)'''
* ''src'': an image file used as source for the blit, other image path functions can be used there.
* ''x'',''y'': top-left corner coordinates where to blit. Must be greater or equal than zero. If missing assume (0,0).

== Color-shift function ==
Performs simple per-channel color shifts by adding the arguments to the respective color channels.
=== Syntax ===
''Multi-channel:'' '''~CS(r,g,b)'''
''Single-channel:'' '''~R(v)''', '''~G(v)''', '''~B(v)'''

The multichannel syntax assumes all arguments are set to zero initially, so one can use, e.g. ~CS(2,4) to add +2 and +4 units to the red and green channels respectively, leaving the blue channel intact. Arguments may be negative to diminish a channel's value; this can be used to change an image's brightness. Checks for out-of-range arguments or results (less than 0 or greater than 255) are made, so the resultant values are truncated if necessary.

The single channel syntax behaves exactly the same, except that only single-channel modifications are made per function. However, one can stack them to produce the same behavior as ~CS(), e.g. ~R(r)~G(g)~B(b), but that tends to be just a performance loss.

Any color-shift is performed before changing opacity or desaturating the graphic (see ~O() and ~GS()).

== Image-scaling function ==
Scales a graphic up or down.
=== Syntax ===

'''~SCALE( ''new_width'', ''new_height'' )

The ''new_width'' and ''new_height'' parameters are taken as the image's original width or height, respectively, if one of them happens to be zero. Negative values are treated in the same way, but an error is printed in stderr.

== Opacity modifying function ==
Changes an image's opacity at render time.
=== Syntax ===

'''~O( ''factor or percentage%'' )'''

If the argument includes the percentage symbol (''%''), it will be treated as a percentage of full (real) opacity; an image will be displayed at its native opacity with ~O(100%).

Without the percentage symbol, the argument is assumed to be a factor by which the image's native opacity should be multiplied. Thus, ~O(0.5) and ~O(50%) are equivalent forms of specifying to reduce an image's opacity by half.

== Blurring function ==
Blurs a graphic at render time using the same algorithm used for in-game dialogs.
=== Syntax ===

'''~BL( ''radius'' )'''

== Null function ==
Does nothing.
=== Syntax ===

'''~NOP()'''

== Precedence of Functions ==

All functions are applied in left-to-right order, with the exception of RC() and TC() which are applied always before any other functions.
That is, stuff like "units/elves-wood/fighter.png~CROP(0,0,20,20)~CROP(10,10,10,10)" would result in taking a crop of the rectangle x=20;y=20;w=40;h=40 and then taking a crop from ''that'' rectangle as x=10;y=10;w=10;h=10 resulting in the area x=30;y=30;w=10;h=10 from the original graphic.

[[Category:WML Reference]]

DeveloperGuide

2010-08-01T14:47:47Z

Alink: Improve svn commits recommandations

== Commits ==
* Setting up developer SVN access: [[WesnothSVN#Commit_access]]
* Register to commit mailing list: https://mail.gna.org/listinfo/wesnoth-commits or get the list moderator to approve commit messages from you otherwise
* Trunk should compile and work after commit
* Few small commits are better than a big one (hard to review), so when possible split it in working parts with info about where you are going
* Be on #wesnoth-dev IRC channel and coordinate with other developers. Bots report commits and some devs may ask you a question about it.
* Don't forget changelogs: ''changelog'' for any (significant enough) changes and ''player_changelog'' for changes visible to users.
* Always check your changes before commit (use ''svn diff'')
* Commit message:
** Mention any change, especially if some are unrelated to the main one (but you should use separated commits for this).
** Mention "bug #1234" for automatic cc to that gna bug number
** Mention a developer's IRC name will ping him on IRC (when the bot report it), and if he's not there, he may see it on the IRC logs
== Bugs management ==
* Change status of fixed bugs to "Fixed" when committed
* Change status of fixed bugs to "Closed" when released, see [[ReportingBugs#Bug_protocol]] for details
* Check if there is new bugs relevant to your code and if any, assign them to you.

== See also ==
* [[Project#Developers]]
* [[WesnothSVN]]

[[Category:Development]]

WesnothRepository

2010-08-01T14:22:46Z

Alink: add a commit access section

{{Compiling Wesnoth}}
== SVN ==

Wesnoth development currently uses the [[SVN|Subversion]] software tool to keep developers in sync with each other. See the [http://svnbook.org SVN book] for more on how to use Subversion.

== Browse the code ==

There are currently two main streams of development: trunk (1.9.x) and stable branch (1.8.x). Most other branches are only used for a short time to do some testing without disturbing the main development. You can use your web browser to navigate through the source code:

http://svn.gna.org/viewcvs/wesnoth/

== Download ==

To check out trunk into a directory ''wesnoth'' (about 400 MB to download and 960 MB disk space, including .svn dirs, required as of March 30th 2009):
svn co http://svn.gna.org/svn/wesnoth/trunk wesnoth

Or, to check out the 1.8 branch (about 400 MB to download and 960 MB to store on disk as of March 30th 2009) into a directory ''wesnoth-1.8'':
svn co http://svn.gna.org/svn/wesnoth/branches/1.8 wesnoth-1.8

More info on the repository: https://gna.org/svn/?group=wesnoth

== Commit access ==

For commit access, you must have a developer account on gna, it must be registered as part of the Wesnoth group, and you must check out with
svn co svn+ssh://gna_username@svn.gna.org/svn/wesnoth/trunk wesnoth

== Update ==

Do this from inside the ''wesnoth'' or ''wesnoth-1.8'' directory where you checked out the repository:
svn update

The following is only relevant when relying on the autotools based build system. This is not needed when relying on CMake or SCons as build environment:

Note that when you update from Subversion, you should always run 'autogen.sh' if ''configure.ac'' or any of the ''Makefile.am'' files were changed. It is safest to 'make clean' before updating, then update and finally run 'autogen.sh', 'configure' and 'make'.

You may be able to skip the 'autogen.sh' and the 'make clean' if the makefiles and ''configure.ac'' have not changed. If only minor changes were made then even the 'configure' step is optional.

== See Also ==

* [[CompilingWesnoth]]
* [[UsingAutotools]]
* [[SVN_on_Windows]]

[[Category:Development]]

Project

2010-08-01T13:56:00Z

Alink: /* Developers */ remove shorcut to a bad page

The Battle for Wesnoth is a [http://gna.org/projects/wesnoth/ Gna! project]. See also the [http://freshmeat.net/projects/wesnoth/ project] and [http://freshmeat.net/project-stats/view/38720/ stats] at [http://www.freshmeat.net/ freshmeat].

There are also Wesnoth pages in other languages:
French ([http://tournoiswesnoth.frbb.net/ 1], [http://wesnothfr.ww7.be/ 2]),
[http://wesnoth.fsf.hu/ Hungarian],
[http://wikiwiki.jp/wesnoth/ Japanese],
[http://perso.wanadoo.es/wesnoth/ Spanish],
[http://www.wesnoth.cn Chinese],
[http://www.wesnoth.com.pl Polish],
[http://wif.altervista.org/index.php Italian].

== Artists ==
Graphic artists and musicians usually meet on the [http://www.wesnoth.org/forum/ forum].
* [http://www.wesnoth.org/forum/viewforum.php?f=9 Artwork development forum]
* [http://www.wesnoth.org/forum/viewforum.php?f=14 Music development forum]

== Developers ==
Coders can help fixing [http://bugs.wesnoth.org bugs], adding new features...
* [[CodingStandards]]
* [[PatchSubmissionGuidelines]]
* [[Roadmap]]
* [http://devdocs.wesnoth.org/ Documentation] - generated and uploaded once a day.
* [[WesnothSVN]]
* [[DeveloperResources]]

== Translators ==
* [[WesnothTranslations]]
* [http://gettext.wesnoth.org Statistics]
* [[WesCamp|Translating User made Campaigns (featuring wescamp-i18n)]]

[[Category:Development]]

TerrainGraphicsWML

2010-08-01T13:54:50Z

Alink: /* The toplevel [terrain_graphics] tag */ mark set_no_flag as 1.9 only

{{WML Tags}}

{{Needs update}}

== The toplevel [terrain_graphics] tag ==

For information about the multi-hex tiling system, see [[MultiHexTutorial]]

In terrain graphics, all images are assumed to be .png and relative to images/terrain/.
For example, writing 'image=grassland' means that the image file is images/terrain/grassland.png.

The multi-hex tiling system adds a new top-level element to WML, [terrain_graphics].
A building rule is used to specify images to place when terrains are in a certain formation.
When a building rule is applied to a map, it is applied once to each coordinate on the map;
when it is applied to a coordinate then that coordinate is considered the ''base''.
All locations in '''[terrain_graphics]''' are relative to the base.

The following keys/tags are recognized:
* '''[tile]''': whenever a building rule is applied, each [tile] tag corresponds to a tile on the map. The corresponding tile must match each condition contained in [tile] for the [tile] tag to match. All [tile] tags must match in order for a rule to match. If the rule for a [tile] tag is applied, each action within [tile] will be executed on the tile corresponding to that [tile] tag
** '''x''','''y''': standard coordinates - the location of the corresponding tile relative to the base.
** '''pos''': a shortcut to specifying coordinates. Used in combination with ''map''
** '''type''': a comma-separated list of terrain codes (See [[TerrainWML]], data/terrain.cfg). In order for a tile to match this condition, it must be one of the terrains specified. However, if the string is preceded by "!", the terrain must not be listed in order to match. If the string is '*', or if it is empty, any tile matches.
** '''set_flag''': a comma-separated list of strings. Attaches flags from that list to the corresponding tile if the rule matches. The only difference a flag makes is being detected by ''has_flag'' and ''no_flag'' in [tile]. This is determined by the order of the [terrain_graphics] tags; a tag after another one cannot influence it. See also ''has_flag'', ''no_flag''
** '''has_flag''': a comma-separated list of strings. Matches if all flags in that list are attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** '''no_flag''': a comma-separated list of strings. Matches if none of the flags in that list are attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** '''set_no_flag''': {{DevFeature1.9}} helper combining ''set_flag'' and ''no_flag''. Same effect as using them with the same flags. Added because it's the most common use; ''set_flag'' or ''no_flag'' can still be used to add flags in one group only.
** '''[image]''': images specified as a subtag to '''[tile]''' sets the images for a single tile.
*** '''layer''': an integer, usually negative. The more negative it is, the earlier it is drawn, and thus the farther "back" it is when compositing the terrain images together.
*** '''name''': the image to apply on this tile if appropriate
*** '''base''': specifies the point at which the image is considered to be for layering purposes. ''base'' is specified as '''x,y''' where x and y indicate distances in pixels from the top-left corner of the '''image'''. This is translated to a certain pixel on the map, and all images with the ''base'' attribute are drawn from top-to-bottom in terms of these specified pixel positions '''on the map'''.
*** '''[variant]''': an alternate image to use for differing times of day
**** '''tod''': the time of day for which this variant applies
**** '''name''': the image to apply on this tile if appropriate
* '''[image]''': image may also be used directly in the rule, to specify multihex images.
* '''probability''': the percent probability for each position that if the position matches, then the rule will be applied. Default is 100(%). See [[TerrainGraphicsTutorial#Cumulative_Probabilities|Cumulative_Probabilities]] for mathematical complications.
* '''rotations''': 6 comma(''',''') separated input strings. A rule that contains this key is not actually checked against the terrain; it instead is used as a template to create 6 new rules, each corresponding to a rotated version of the current rule. Whenever a rotated version is applied, instances of @(at-sign)R0, @R1, ... @R6 in attributes in the [terrain_graphics] tag will be adjusted by the corresponding amount and replaced with the letters specified by that numbered rotation in the ''rotations'' list. Each value corresponds to the rotated version that is -Pi/3 (60° clockwise) from the previous version; the first value corresponds to the unrotated version. For example, if '''rotations=n,ne,se,s,sw,nw''' and it is being rotated 120°, then "@R0"->"@R2"->"se", "@R1"->"@R3"->"s", ... "@R6"->"@R1"->"ne". Basically the important thing is that this lets the rule be applied in any of the six hex-directions, allowing you to adjust the name of the image files automatically.
* '''set_flag''','''has_flag''', '''no_flag''': shortcuts to putting these in the [tile] subtags; unbound attributes will apply to all [tile] subtags.
* '''map''': a shortcut for defining [tile] tags with ''type'' conditions. Inputs a multi-line string value visually describing the map. The lines are cut into words of 4 characters, which correspond to [tile] tags. The line types alternate between lines corresponding to relatively even-abciss tiles and lines preceded by two spaces corresponding to relatively odd-abciss tiles. Every two lines represent 1 row on the map.

=== Words ===

A ''word'' is a 4-character shortcut to a [tile] tag. There are different types of words:
* Usually a word is interpreted as being the input to the ''type'' key of the corresponding [tile]. That is, it creates a [tile] with the attribute '''type=''word'''''.
* A word can also be a digit followed by 3 spaces. In this case, it is a shortcut to the [tile] with the attribute '''pos=''word'''''. This is called ''anchoring''.

In 1.3, the format is basically the same but the following changes are made
* A ''word'' no longer needs to be 4 characters but is comma separated and spaces and tabs may be used for padding
* The 2 spaces for odd lines in no longer used, instead a leading comma is used on these lines (before the comma spaces and tabs are allowed for padding)
* A ''word'' may only be a dot a star or an anchor. The terrain letter format was not used and hard to support in the new engine, so that support is dropped.

== Examples ==

To define a north-south 2-tile mountain, the following syntax can be used:

[terrain_graphics]
[tile]
x=0
y=0
type=Mm
[/tile]
[tile]
x=0
y=1
type=Mm
[/tile]
no_flag="mountain-tile"
set_flag="mountain-tile"
image_background="mountain-n-s"
[/terrain_graphics]

This represents a tile T, and its 6 adjacent tiles A, in the map notation.

., ., ., .
, ., A, ., .
., A, A, .
, ., T, ., .
., A, A, .
, ., A, ., .

== See Also ==
* [[MultiHexTutorial]]
* [[ReferenceWML]]
* Ayin's [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml detailed Terrain Graphics document]
* [[TerrainGraphicsTutorial]] - First half of Ayin's document, wikified
* [[TerrainGraphicsReference]] - Second (partial) half of Ayin's document, wikified

[[Category: WML Reference]]

TerrainGraphicsWML

2010-07-31T17:49:37Z

Alink: /* The toplevel [terrain_graphics] tag */ Document set_no flag and update flag keys

{{WML Tags}}

{{Needs update}}

== The toplevel [terrain_graphics] tag ==

For information about the multi-hex tiling system, see [[MultiHexTutorial]]

In terrain graphics, all images are assumed to be .png and relative to images/terrain/.
For example, writing 'image=grassland' means that the image file is images/terrain/grassland.png.

The multi-hex tiling system adds a new top-level element to WML, [terrain_graphics].
A building rule is used to specify images to place when terrains are in a certain formation.
When a building rule is applied to a map, it is applied once to each coordinate on the map;
when it is applied to a coordinate then that coordinate is considered the ''base''.
All locations in '''[terrain_graphics]''' are relative to the base.

The following keys/tags are recognized:
* '''[tile]''': whenever a building rule is applied, each [tile] tag corresponds to a tile on the map. The corresponding tile must match each condition contained in [tile] for the [tile] tag to match. All [tile] tags must match in order for a rule to match. If the rule for a [tile] tag is applied, each action within [tile] will be executed on the tile corresponding to that [tile] tag
** '''x''','''y''': standard coordinates - the location of the corresponding tile relative to the base.
** '''pos''': a shortcut to specifying coordinates. Used in combination with ''map''
** '''type''': a comma-separated list of terrain codes (See [[TerrainWML]], data/terrain.cfg). In order for a tile to match this condition, it must be one of the terrains specified. However, if the string is preceded by "!", the terrain must not be listed in order to match. If the string is '*', or if it is empty, any tile matches.
** '''set_flag''': a comma-separated list of strings. Attaches flags from that list to the corresponding tile if the rule matches. The only difference a flag makes is being detected by ''has_flag'' and ''no_flag'' in [tile]. This is determined by the order of the [terrain_graphics] tags; a tag after another one cannot influence it. See also ''has_flag'', ''no_flag''
** '''has_flag''': a comma-separated list of strings. Matches if all flags in that list are attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** '''no_flag''': a comma-separated list of strings. Matches if none of the flags in that list are attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** '''set_no_flag''': helper combining ''set_flag'' and ''no_flag''. Same effect as using them with the same flags. Added because it's the most common use; ''set_flag'' or ''no_flag'' can still be used to add flags in one group only.
** '''[image]''': images specified as a subtag to '''[tile]''' sets the images for a single tile.
*** '''layer''': an integer, usually negative. The more negative it is, the earlier it is drawn, and thus the farther "back" it is when compositing the terrain images together.
*** '''name''': the image to apply on this tile if appropriate
*** '''base''': specifies the point at which the image is considered to be for layering purposes. ''base'' is specified as '''x,y''' where x and y indicate distances in pixels from the top-left corner of the '''image'''. This is translated to a certain pixel on the map, and all images with the ''base'' attribute are drawn from top-to-bottom in terms of these specified pixel positions '''on the map'''.
*** '''[variant]''': an alternate image to use for differing times of day
**** '''tod''': the time of day for which this variant applies
**** '''name''': the image to apply on this tile if appropriate
* '''[image]''': image may also be used directly in the rule, to specify multihex images.
* '''probability''': the percent probability for each position that if the position matches, then the rule will be applied. Default is 100(%). See [[TerrainGraphicsTutorial#Cumulative_Probabilities|Cumulative_Probabilities]] for mathematical complications.
* '''rotations''': 6 comma(''',''') separated input strings. A rule that contains this key is not actually checked against the terrain; it instead is used as a template to create 6 new rules, each corresponding to a rotated version of the current rule. Whenever a rotated version is applied, instances of @(at-sign)R0, @R1, ... @R6 in attributes in the [terrain_graphics] tag will be adjusted by the corresponding amount and replaced with the letters specified by that numbered rotation in the ''rotations'' list. Each value corresponds to the rotated version that is -Pi/3 (60° clockwise) from the previous version; the first value corresponds to the unrotated version. For example, if '''rotations=n,ne,se,s,sw,nw''' and it is being rotated 120°, then "@R0"->"@R2"->"se", "@R1"->"@R3"->"s", ... "@R6"->"@R1"->"ne". Basically the important thing is that this lets the rule be applied in any of the six hex-directions, allowing you to adjust the name of the image files automatically.
* '''set_flag''','''has_flag''', '''no_flag''': shortcuts to putting these in the [tile] subtags; unbound attributes will apply to all [tile] subtags.
* '''map''': a shortcut for defining [tile] tags with ''type'' conditions. Inputs a multi-line string value visually describing the map. The lines are cut into words of 4 characters, which correspond to [tile] tags. The line types alternate between lines corresponding to relatively even-abciss tiles and lines preceded by two spaces corresponding to relatively odd-abciss tiles. Every two lines represent 1 row on the map.

=== Words ===

A ''word'' is a 4-character shortcut to a [tile] tag. There are different types of words:
* Usually a word is interpreted as being the input to the ''type'' key of the corresponding [tile]. That is, it creates a [tile] with the attribute '''type=''word'''''.
* A word can also be a digit followed by 3 spaces. In this case, it is a shortcut to the [tile] with the attribute '''pos=''word'''''. This is called ''anchoring''.

In 1.3, the format is basically the same but the following changes are made
* A ''word'' no longer needs to be 4 characters but is comma separated and spaces and tabs may be used for padding
* The 2 spaces for odd lines in no longer used, instead a leading comma is used on these lines (before the comma spaces and tabs are allowed for padding)
* A ''word'' may only be a dot a star or an anchor. The terrain letter format was not used and hard to support in the new engine, so that support is dropped.

== Examples ==

To define a north-south 2-tile mountain, the following syntax can be used:

[terrain_graphics]
[tile]
x=0
y=0
type=Mm
[/tile]
[tile]
x=0
y=1
type=Mm
[/tile]
no_flag="mountain-tile"
set_flag="mountain-tile"
image_background="mountain-n-s"
[/terrain_graphics]

This represents a tile T, and its 6 adjacent tiles A, in the map notation.

., ., ., .
, ., A, ., .
., A, A, .
, ., T, ., .
., A, A, .
, ., A, ., .

== See Also ==
* [[MultiHexTutorial]]
* [[ReferenceWML]]
* Ayin's [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml detailed Terrain Graphics document]
* [[TerrainGraphicsTutorial]] - First half of Ayin's document, wikified
* [[TerrainGraphicsReference]] - Second (partial) half of Ayin's document, wikified

[[Category: WML Reference]]

CommandMode

2010-07-19T14:38:01Z

Alink: /* Command Mode */ show parameter of :turn and :turn_limit

== Command Mode ==

You can access command mode by typing ' ''':''' ' in a single player or multiplayer scenario.
(Prior to version 1.1.1, you need to type shift - semicolon( ''';''' ). However this isn't possible on all keyboards; if your keyboard doesn't have ':' above ';' you can change the hotkey in the Preferences, or you could edit '''game.cfg''' by hand.')

Note: you can highlight, copy, and paste text in debug mode.

Several vi-like commands are available in command mode. They are defined in ''menu_events.cpp''. In the 1.5 branch, there is a ''':help''' command that lists all available commands, and ''':help ''foo''''' displays more info about command ''foo''. This is more reliable than the list that follows here:

;<nowiki>:q or :q!</nowiki>
:quit the scenario (without prompting)
;<nowiki>:w</nowiki>
:save the game (without prompting)
;<nowiki>:wq</nowiki>
:save the game and quit the scenario (without prompting)
;<nowiki>:refresh</nowiki>
:redraw the screen
;<nowiki>:droid</nowiki> [''side''] [on|off]
:toggle player on ''side'' between human and AI player. The player/client who controls that side needs to issue this command. If you don't provide ''side'', the current side is assumed.
;<nowiki>:muteall</nowiki>
:toggles muting/silencing of all observers on/off
;<nowiki>:mute</nowiki> [''username'']
:mute a specific observer. If no ''username'' is supplied the muted usernames are displayed.
;<nowiki>:unmute</nowiki> [''username'']
:unmute a specific observer. If no ''username'' is given everyone is unmuted. (Doesn't effect the muteall setting.)
;<nowiki>:kick</nowiki> ''username''
:kick a user in multiplayer. They will be able to rejoin the game. Generally a friendly way to remove someone who is having connection or other difficulties.
;<nowiki>:ban</nowiki> ''username''
:kick and ban a user in multiplayer by the IP address used by that ''username''. Can be used on users not in the game but on the server. (Of course they won't be kicked then.)
;<nowiki>:unban</nowiki> ''username''
:unban a user by the IP address used by that ''username''. Can be used on users not in the game but on the server.
;<nowiki>:control</nowiki> ''side'' ''username''
:change the controller for ''side'' (write here the number of the side, the side must be controlled by you) to ''username'' (write here the nick of the player or observer)
;<nowiki>:clear</nowiki>
:clear chat messages
;<nowiki>:debug</nowiki>
:switch debug mode on (does not work in multiplayer). Debug mode is turned off by quitting the game or using the :nodebug command.
;<nowiki>:theme</nowiki>
:bring up theme selection menu
;<nowiki>:nosaves</nowiki>
:turns off the autosave function
;<nowiki>:show_coordinates (or :sc)</nowiki>
:Overlay x,y coordinates on map tiles. 1.5.5 onwards
;<nowiki>:show_terrain_codes (or :tc)</nowiki>
:Overlay terrain codes on visible map tiles. 1.5.5 onwards
;<nowiki>:lua</nowiki> ''statement''
:{{DevFeature}} execute a Lua statement
;<nowiki>:discover</nowiki>
:Show all hidden unit descriptions in the in-game Help. 1.7.0 onwards

===Extra Debugging Commands===
[[DebugMode]] enables additional commands in command mode:

;<nowiki>:nodebug</nowiki>
:disables debug-mode commands
;<nowiki>:n</nowiki>
:skip to next scenario by triggering a win event
;<nowiki>:shroud</nowiki>
:toggles shroud on/off (implemented since 1.3.10)
;<nowiki>:fog</nowiki>
:toggles fog on/off (implemented since 1.3.10)
;<nowiki>:gold</nowiki> ''amount''
:add ''amount'' gold to the current player's side
;<nowiki>:create</nowiki> ''unit_type''
:create a unit of type specified at last selected hex
;<nowiki>:unit hitpoints=</nowiki>''amount''
:edit units hitpoints
;<nowiki>:unit experience=</nowiki>''amount''
:edit units experience
;<nowiki>:unit</nowiki> ''attribute=value''
:when a unit is selected, this will set the unit's ''attribute'' to ''value''. See [[SingleUnitWML]] for possible values.
;<nowiki>:unit</nowiki> ''advances=N''
:{{DevFeature}} when a unit is selected, this will advance (level up) the unit N times.
;<nowiki>:set_var</nowiki> ''attribute=value''
:this will set a WML variable to a given value
;<nowiki>:show_var</nowiki> ''attribute''
:this will display a popup with the content of the variable
;<nowiki>:throw/fire</nowiki> ''event_name''
:throw an event by name, like ''time over'' or ''enemies defeated''. (Only available in 1.3.5 or later.)
;<nowiki>:inspect</nowiki>
:{{DevFeature}} show a gamestate inspector dialog which allows to see variable info, team info, ai info.
;<nowiki>:cl</nowiki>
:pops up a menu that allows you to move directly to a specified scenario.
;<nowiki>:turn</nowiki> [''number'']
:{{DevFeature1.9}} change the current turn to the specified number. If no number is provided, the turn number is increased by one.
;<nowiki>:turn_limit</nowiki> [''number'']
:{{DevFeature1.9}} change the turn limit for the current scenario to the specified number. If no number is provided, or it is -1, the turn limit is switched off.
;<nowiki>:version</nowiki>
:Report version and SVN revision level.

== See Also ==

* [[DebugMode]]
* [[DeveloperResources]]

[[Category:Playing Wesnoth]]
[[Category:Development]]

TerrainGraphicsWML

2010-07-14T22:33:40Z

Alink: /* The toplevel [terrain_graphics] tag */

{{WML Tags}}

{{Needs update}}

== The toplevel [terrain_graphics] tag ==

For information about the multi-hex tiling system, see [[MultiHexTutorial]]

In terrain graphics, all images are assumed to be .png and relative to images/terrain/.
For example, writing 'image=grassland' means that the image file is images/terrain/grassland.png.

The multi-hex tiling system adds a new top-level element to WML, [terrain_graphics].
A building rule is used to specify images to place when terrains are in a certain formation.
When a building rule is applied to a map, it is applied once to each coordinate on the map;
when it is applied to a coordinate then that coordinate is considered the ''base''.
All locations in '''[terrain_graphics]''' are relative to the base.

The following keys/tags are recognized:
* '''[tile]''': whenever a building rule is applied, each [tile] tag corresponds to a tile on the map. The corresponding tile must match each condition contained in [tile] for the [tile] tag to match. All [tile] tags must match in order for a rule to match. If the rule for a [tile] tag is applied, each action within [tile] will be executed on the tile corresponding to that [tile] tag
** '''x''','''y''': standard coordinates - the location of the corresponding tile relative to the base.
** '''pos''': a shortcut to specifying coordinates. Used in combination with ''map''
** Conditions for [tile]:
*** '''type''': a comma-separated list of terrain codes (See [[TerrainWML]], data/terrain.cfg). In order for a tile to match this condition, it must be one of the terrains specified. However, if the string is preceded by "!", the terrain must not be listed in order to match. If the string is '*', or if it is empty, any tile matches.
*** '''has_flag''': a string. Matches if a flag named after the given string is attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
*** '''no_flag''': a string. Matches if no flag named after the given string has been attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** Actions for [tile]:
*** '''set_flag''': Followed by a string of characters. Attaches a flag named after the given string to the corresponding tile if the rule matches. The only difference a flag makes is being detected by ''has_flag'' and ''no_flag'' in [tile]. This is determined by the order of the [terrain_graphics] tags; a tag after another one cannot influence it. See also ''has_flag'', ''no_flag''
*** '''[image]''': images specified as a subtag to '''[tile]''' sets the images for a single tile.
**** '''layer''': an integer, usually negative. The more negative it is, the earlier it is drawn, and thus the farther "back" it is when compositing the terrain images together.
**** '''name''': the image to apply on this tile if appropriate
**** '''base''': specifies the point at which the image is considered to be for layering purposes. ''base'' is specified as '''x,y''' where x and y indicate distances in pixels from the top-left corner of the '''image'''. This is translated to a certain pixel on the map, and all images with the ''base'' attribute are drawn from top-to-bottom in terms of these specified pixel positions '''on the map'''.
**** '''[variant]''': an alternate image to use for differing times of day
***** '''tod''': the time of day for which this variant applies
***** '''name''': the image to apply on this tile if appropriate
* '''[image]''': image may also be used directly in the rule, to specify multihex images.
* '''probability''': the percent probability for each position that if the position matches, then the rule will be applied. Default is 100(%). See [[TerrainGraphicsTutorial#Cumulative_Probabilities|Cumulative_Probabilities]] for mathematical complications.
* '''rotations''': 6 comma(''',''') separated input strings. A rule that contains this key is not actually checked against the terrain; it instead is used as a template to create 6 new rules, each corresponding to a rotated version of the current rule. Whenever a rotated version is applied, instances of @(at-sign)R0, @R1, ... @R6 in attributes in the [terrain_graphics] tag will be adjusted by the corresponding amount and replaced with the letters specified by that numbered rotation in the ''rotations'' list. Each value corresponds to the rotated version that is -Pi/3 (60° clockwise) from the previous version; the first value corresponds to the unrotated version. For example, if '''rotations=n,ne,se,s,sw,nw''' and it is being rotated 120°, then "@R0"->"@R2"->"se", "@R1"->"@R3"->"s", ... "@R6"->"@R1"->"ne". Basically the important thing is that this lets the rule be applied in any of the six hex-directions, allowing you to adjust the name of the image files automatically.
* '''set_flag''','''has_flag''', '''no_flag''': shortcuts to putting these in the [tile] subtags; unbound attributes will apply to all [tile] subtags.
* '''map''': a shortcut for defining [tile] tags with ''type'' conditions. Inputs a multi-line string value visually describing the map. The lines are cut into words of 4 characters, which correspond to [tile] tags. The line types alternate between lines corresponding to relatively even-abciss tiles and lines preceded by two spaces corresponding to relatively odd-abciss tiles. Every two lines represent 1 row on the map.

=== Words ===

A ''word'' is a 4-character shortcut to a [tile] tag. There are different types of words:
* Usually a word is interpreted as being the input to the ''type'' key of the corresponding [tile]. That is, it creates a [tile] with the attribute '''type=''word'''''.
* A word can also be a digit followed by 3 spaces. In this case, it is a shortcut to the [tile] with the attribute '''pos=''word'''''. This is called ''anchoring''.

In 1.3, the format is basically the same but the following changes are made
* A ''word'' no longer needs to be 4 characters but is comma separated and spaces and tabs may be used for padding
* The 2 spaces for odd lines in no longer used, instead a leading comma is used on these lines (before the comma spaces and tabs are allowed for padding)
* A ''word'' may only be a dot a star or an anchor. The terrain letter format was not used and hard to support in the new engine, so that support is dropped.

== Examples ==

To define a north-south 2-tile mountain, the following syntax can be used:

[terrain_graphics]
[tile]
x=0
y=0
type=Mm
[/tile]
[tile]
x=0
y=1
type=Mm
[/tile]
no_flag="mountain-tile"
set_flag="mountain-tile"
image_background="mountain-n-s"
[/terrain_graphics]

This represents a tile T, and its 6 adjacent tiles A, in the map notation.

., ., ., .
, ., A, ., .
., A, A, .
, ., T, ., .
., A, A, .
, ., A, ., .

== See Also ==
* [[MultiHexTutorial]]
* [[ReferenceWML]]
* Ayin's [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml detailed Terrain Graphics document]
* [[TerrainGraphicsTutorial]] - First half of Ayin's document, wikified
* [[TerrainGraphicsReference]] - Second (partial) half of Ayin's document, wikified

[[Category: WML Reference]]

TerrainGraphicsWML

2010-07-14T22:31:11Z

Alink: /* The toplevel [terrain_graphics] tag */ fix link

{{WML Tags}}

{{Needs update}}

== The toplevel [terrain_graphics] tag ==

For information about the multi-hex tiling system, see [[MultiHexTutorial]]

In terrain graphics, all images are assumed to be .png and relative to images/terrain/.
For example, writing 'image=grassland' means that the image file is images/terrain/grassland.png.

The multi-hex tiling system adds a new top-level element to WML, [terrain_graphics].
A building rule is used to specify images to place when terrains are in a certain formation.
When a building rule is applied to a map, it is applied once to each coordinate on the map;
when it is applied to a coordinate then that coordinate is considered the ''base''.
All locations in '''[terrain_graphics]''' are relative to the base.

The following keys/tags are recognized:
* '''[tile]''': whenever a building rule is applied, each [tile] tag corresponds to a tile on the map. The corresponding tile must match each condition contained in [tile] for the [tile] tag to match. All [tile] tags must match in order for a rule to match. If the rule for a [tile] tag is applied, each action within [tile] will be executed on the tile corresponding to that [tile] tag
** '''x''','''y''': standard coordinates - the location of the corresponding tile relative to the base.
** '''pos''': a shortcut to specifying coordinates. Used in combination with ''map''
** Conditions for [tile]:
*** '''type''': a comma-separated list of terrain codes (See [[TerrainWML]], data/terrain.cfg). In order for a tile to match this condition, it must be one of the terrains specified. However, if the string is preceded by "!", the terrain must not be listed in order to match. If the string is '*', or if it is empty, any tile matches.
*** '''has_flag''': a string. Matches if a flag named after the given string is attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
*** '''no_flag''': a string. Matches if no flag named after the given string has been attached to the corresponding tile. Flags are attached using the ''set_flag'' key.
** Actions for [tile]:
*** '''set_flag''': Followed by a string of characters. Attaches a flag named after the given string to the corresponding tile if the rule matches. The only difference a flag makes is being detected by ''has_flag'' and ''no_flag'' in [tile]. This is determined by the order of the [terrain_graphics] tags; a tag after another one cannot influence it. See also ''has_flag'', ''no_flag''
*** '''[image]''': images specified as a subtag to '''[tile]''' sets the images for a single tile.
**** '''layer''': an integer, usually negative. The more negative it is, the earlier it is drawn, and thus the farther "back" it is when compositing the terrain images together.
**** '''name''': the image to apply on this tile if appropriate
**** '''base''': specifies the point at which the image is considered to be for layering purposes. ''base'' is specified as '''x,y''' where x and y indicate distances in pixels from the top-left corner of the '''image'''. This is translated to a certain pixel on the map, and all images with the ''base'' attribute are drawn from top-to-bottom in terms of these specified pixel positions '''on the map'''.
**** '''[variant]''': an alternate image to use for differing times of day
***** '''tod''': the time of day for which this variant applies
***** '''name''': the image to apply on this tile if appropriate
* '''[image]''': image may also be used directly in the rule, to specify multihex images.
* '''probability''': the percent probability for each position that if the position matches, then the rule will be applied. Default is 100(%). See [[TerrainGraphicsTutorial#Cumulative_Probabilities]] for mathematical complications.
* '''rotations''': 6 comma(''',''') separated input strings. A rule that contains this key is not actually checked against the terrain; it instead is used as a template to create 6 new rules, each corresponding to a rotated version of the current rule. Whenever a rotated version is applied, instances of @(at-sign)R0, @R1, ... @R6 in attributes in the [terrain_graphics] tag will be adjusted by the corresponding amount and replaced with the letters specified by that numbered rotation in the ''rotations'' list. Each value corresponds to the rotated version that is -Pi/3 (60° clockwise) from the previous version; the first value corresponds to the unrotated version. For example, if '''rotations=n,ne,se,s,sw,nw''' and it is being rotated 120°, then "@R0"->"@R2"->"se", "@R1"->"@R3"->"s", ... "@R6"->"@R1"->"ne". Basically the important thing is that this lets the rule be applied in any of the six hex-directions, allowing you to adjust the name of the image files automatically.
* '''set_flag''','''has_flag''', '''no_flag''': shortcuts to putting these in the [tile] subtags; unbound attributes will apply to all [tile] subtags.
* '''map''': a shortcut for defining [tile] tags with ''type'' conditions. Inputs a multi-line string value visually describing the map. The lines are cut into words of 4 characters, which correspond to [tile] tags. The line types alternate between lines corresponding to relatively even-abciss tiles and lines preceded by two spaces corresponding to relatively odd-abciss tiles. Every two lines represent 1 row on the map.

=== Words ===

A ''word'' is a 4-character shortcut to a [tile] tag. There are different types of words:
* Usually a word is interpreted as being the input to the ''type'' key of the corresponding [tile]. That is, it creates a [tile] with the attribute '''type=''word'''''.
* A word can also be a digit followed by 3 spaces. In this case, it is a shortcut to the [tile] with the attribute '''pos=''word'''''. This is called ''anchoring''.

In 1.3, the format is basically the same but the following changes are made
* A ''word'' no longer needs to be 4 characters but is comma separated and spaces and tabs may be used for padding
* The 2 spaces for odd lines in no longer used, instead a leading comma is used on these lines (before the comma spaces and tabs are allowed for padding)
* A ''word'' may only be a dot a star or an anchor. The terrain letter format was not used and hard to support in the new engine, so that support is dropped.

== Examples ==

To define a north-south 2-tile mountain, the following syntax can be used:

[terrain_graphics]
[tile]
x=0
y=0
type=Mm
[/tile]
[tile]
x=0
y=1
type=Mm
[/tile]
no_flag="mountain-tile"
set_flag="mountain-tile"
image_background="mountain-n-s"
[/terrain_graphics]

This represents a tile T, and its 6 adjacent tiles A, in the map notation.

., ., ., .
, ., A, ., .
., A, A, .
, ., T, ., .
., A, A, .
, ., A, ., .

== See Also ==
* [[MultiHexTutorial]]
* [[ReferenceWML]]
* Ayin's [http://www.anathas.org/ayin/wesnoth/doc/terrain_graphics_wml detailed Terrain Graphics document]
* [[TerrainGraphicsTutorial]] - First half of Ayin's document, wikified
* [[TerrainGraphicsReference]] - Second (partial) half of Ayin's document, wikified

[[Category: WML Reference]]

Download

2010-05-17T14:24:40Z

Alink: /* Development (1.7 branch) */ marking 1.7 as old and updating 1.9 info. Mention svn.

Welcome to the Battle for Wesnoth downloads page. The BFW project team only officially releases the source code. Binary packages are only provided by community volunteers and hosted here. Torrents are also unofficial.

If the latest binaries are not currently available for your OS, please check back in a few days to see if they have been placed here. Packagers have been informed of the release, please be patient. In the meantime, read the [[FAQ#A_new_version_is_out.2C_but_where_is_the_download_for_.5BWindows.2C_Mac_OS.2C_etc..5D.3F|FAQ]].

__NOTOC__
Jump to: [[Download#Stable_.281.8_branch.29|Stable Branch]] | [[Download#Stable_.28older_versions.29|Stable Branch (older versions)]] | [[Download#Development_.281.7_branch.29|Development Branch]]

== Stable (1.8 branch) ==
The stable files are meant to be used as a stable and rather balanced version of the game. Each version of the 1.8 branch is compatible to each other.

Version 1.8.0 is the latest stable version. This version is recommended for most players since the 1.8 online multiplayer community is very large and user-made campaign server has a robust content selection.

==== Source code ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.8.1.tar.bz2/download Current Version] (1.8.1, 274.9 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.8.tar.bz2/download Previous Version] (1.8.0, 274.6 MB)
* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code

==== MS Windows ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.8.1-win32.exe/download Current Version] (1.8.1, 255.9 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.8-win32.exe/download Previous Version] (1.8.0, 255.6 MB)

==== Mac OS X (10.4+) ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/Wesnoth_1.8.1.dmg/download Current Version] (1.8.1, 279.5 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/Wesnoth_1.8.dmg/download Previous Version] (1.8.0, 279.0 MB)

==== GNU/Linux ====
* There are binaries for many different GNU/Linux Distributions. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.

==== Miscellaneous ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.8.1.tar.bz2.md5/download md5sum for current source code]
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Stable_Version_1.8.x Xdelta for the source code]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]

== Stable (older versions) ==
Several operating systems do not offer a binary of the latest stable release. Here is a list of the latest known (stable version) binaries for various systems. For those older versions there often is no (official) multiplayer or addon server available anymore.

==== (Open)Solaris ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-solaris-i386-1.4.5.pkg.bz2/download Older Version] (1.4.5, 145.6 MB), not compatible with 1.6.x

==== AmigaOS4 ====
* [http://os4depot.net/index.php?function=showfile&file=game/strategy/wesnoth.lha Older Version] (1.4.7, 140 MB), not compatible with 1.6.x

==== OS/2 & eComStation ====
* [http://download.smedley.info/wesnoth-1.4.5-os2-20080828.zip Older Version] (1.4.5, 160 MB), not compatible with 1.6.x

==== RISC OS ====
*[http://www.riscos.info/packages/arm/Games/wesnoth_1.4.5-1.zip Older version] (1.4.5-1, 140MB), not compatible with 1.6.x

==== Syllable ====
* [http://downloads.syllable.org/Syllable/i586/applications/contributed/Battle-for-Wesnoth/Battle-for-Wesnoth-1.2.6.application Older Version] (1.2.6, 60.8 MB), not compatible with 1.6.x

== Development (1.7 branch) ==
Version 1.7.x was the previous development version.
At the moment the stable 1.8.x branch offers all the new features known from 1.7.x. The next development release will take some more time and be known as 1.9.x. In the mean time, people familiar with SVN can follow its development by checking [[WesnothSVN]].

==== Source code ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.7.15.tar.bz2/download Current Version] (1.7.15-1.8rc1, 270.4 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.7.14.tar.bz2/download Previous Version] (1.7.14-1.8beta7, 264.8 MB)

* [[CompilingWesnoth|Compiling Guide]] - how to compile the source code

==== MS Windows ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.7.15-1.8rc1-win32.exe/download Current Version] (1.7.15-1.8rc1, 253.1 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.7.14-1.8beta7-win32.exe/download Previous Version] (1.7.14-1.8beta7, 247.6 MB)

==== Mac OS X (10.4+) ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/Wesnoth_1.7.15.dmg/download Current Version] (1.7.15-1.8rc1, 275.3 MB)
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/Wesnoth_1.7.14.dmg/download Previous Version] (1.7.14-1.8beta7, 269.4 MB)

==== GNU/Linux ====
* There are binaries for many different GNU/Linux Distributions developed for [http://www.professays.com custom essay writers] and other users. Not all are always up to date with the current release. Please have a look at the [[WesnothBinariesLinux|Linux binary page]] for more information about the binaries for your Distribution.
* [http://professaywriters.com/ essay writing][http://www.breastpumpdeals.com/medela-freestyle-breast-pump.html Freestyle Medela]

==== Miscellaneous ====
* [http://sourceforge.net/projects/wesnoth/files/wesnoth/wesnoth-1.7.15.tar.bz2.md5/download md5sum for current source code]
* [http://www.wesnoth.org/wiki/Download_Xdeltas#Development_Version_1.7.x Xdelta for the source code]
* [http://sourceforge.net/projects/wesnoth/files/ SourceForge page for current and all previous versions]
* [http://downloads.sourceforge.net/wesnoth/Mac_Compile_Stuff_1.5.3.tar.bz2/download MacCompileStuff for 1.5.3]

== License ==
''Main article: [[Wesnoth:Copyrights]]

This program is free software; you can redistribute it and/or modify it under the terms of the [http://www.fsf.org/copyleft/gpl.html GNU General Public License version 2], as published by the [http://www.essayontime.com/ paper writing service].
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

== See also ==
* [http://changelog.wesnoth.org Changelog]
* [[WesnothBinaries| More binaries]]
* [[WesnothSVN]] - bleeding edge version from SVN

[[Category:Building and Installing]]

Category:Summer of Code 2010

2010-05-09T16:13:44Z

Alink: Adding this page in the 'Summer of Code' category

{{SoC2010 NoCategory}}

This category lists everything that is related to Summer of Code 2010

[[Category:Summer of Code]]

FilterWML

2009-05-17T17:07:31Z

Alink: /* Filtering Weapons */ add damage key

{{WML Tags}}
== Filtering in WML ==

A ''filter'' is a special WML block.
Filters are used to describe a set of units, hexes, or weapons.
Filters are defined as matching something if all the keys in the filter match that thing.
For example, if a unit filter contains two keys,
a unit must match both of the keys in order to match the filter.

== Filtering Units ==

Filters are often used in action tags (see [[EventWML]]).
In this case the phrase "standard unit filter" is used in place of the set of standard keys.
Sometimes a filter is used to find the first unit that matches the filter;
for example, the '''[recall]''' tag recalls that unit.

Standard unit filters are also used in the tags '''[filter]''' and '''[filter_second]'''.
These are subtags of '''[event]''' which describe when the event should trigger.
Most event names (see [[EventWML]]) have units related to them called "primary unit" and "secondary unit".
In order for an event to be triggered, ''primary unit'' must match the filter contained in '''[filter]''',
and ''secondary unit'' must match the filter contained in '''[filter_second]'''.

See [[StandardUnitFilter]] for details.

== Filtering Locations ==

As you have seen, standard unit filter can contain a location filter.
Several actions, such as '''[terrain]''', also use location filters.
Location filters are represented on this site by the phrase "standard location filter".

See [[StandardLocationFilter]] for details.

== Filtering Weapons ==

Sometimes weapons are filtered on in WML. See also [[EventWML]], [[EffectWML]], [[AnimationWML]].

These keys are used as filter input for weapon filters.

* '''range''': a range to filter
** '''melee''': only melee weapons pass
** '''ranged''': only ranged weapons pass
* '''name''': filter on the attack's name.
See '''data/units/''' or http://www.wesnoth.org/units/
to find the name of a particular unit's attack.
* '''type''': filter on the attack's type.
Values are 'blade', 'pierce', 'impact', 'fire', 'cold', and 'arcane'.
* '''damage''': {{DevFeature}} filter on damage value. Can be a specific number or a list of ranges like 'damage=0-5,7-99'
* '''special''': filter on the attack's special power.
For values see [[AbilitiesWML]].

== Filtering Terrains ==

Use '''[filter_location]''' within '''[filter]''' , for example:

[event]
[filter]
[filter_location]
terrain=Ch
[/filter_location]
[/filter]
[/event]

At some places the terrains can be filtered with a
match list. The list is a comma separated list and matching will stop
at the first matched [[TerrainCodesWML|terrain string]]. There's one special character
''!'' which inverts the meaning of a match. Terrain strings can
use the wildcard * to match zero or more following letters, characters
behind the * are not allowed and the result is undefined.

Eg: 
ww* matches ww, www, wwW but not WWW 
!, ww returns false if ww found and true if not 
!, ww, wa, !, aa returns false if ww or wa found and true if aa found and false if none found.

For a list of terrain types and their string codes see [[TerrainCodesWML|TerrainCodesWML]].

== See Also ==

* [[UnitTypeWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

UnitsWML

2009-05-17T17:03:05Z

Alink: /* the [units] tag */ mark [hide_help] as (development only)

{{WML Tags}}
== the [units] tag ==

This tag is a top level WML tag which is in game.cfg.
It defines the set of all units in Wesnoth.

The following subtags are recognized:
* '''[unit_type]''': describes one unit type. See [[UnitTypeWML]] for syntax.
* '''[trait]''': describes a global trait.
All races with the attribute '''ignore_global_traits=no''' will have this trait.
See '''[trait]''': below for syntax.
* '''[movetype]''': used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype.
** '''name''': an ID for this movetype. Units with the attribute '''movetype=''name''''' will be assigned this movetype.
** ''flies'' either 'true' or 'false'(default). A unit with ''flies=true'' does not have its image's height adjusted for different terrains.
** '''[movement_costs]''': describes how fast the unit moves on different terrains. The attribute '''terrain=''speed''''' means that the unit will need to use ''speed'' move points to move onto the terrain with '''name=''terrain''''' (see [[TerrainWML]]).
** '''[defense]''': describes how likely the unit is to be hit on different terrains. The attribute '''terrain=''defense''''' means that the unit will be hit ''defense'' percent of the time in the terrain with '''name=''terrain'''''.
** '''[resistance]''': describes how much damage the unit takes from different types of attacks. The attribute '''type=''resistance''''' makes the unit receive '''resistance''' percent of damage, or resist '''100-resistance''' percent of damage from attacks with '''type=''type'''''. So for example, a resistance of fire=110 means, this unit will receive 110% of damage, or have a resistance of -10% as displayed in-game. A value of fire=0 would mean, the unit receives no damage and therefore has a resistance of 100%.
* '''[race]''': is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions.
** '''id''': ID for this race. Units with the attribute '''race=''id''''' will be assigned this race. If missing in old WML, the value of the name key will be used as id.
** '''plural_name''': user-visible name for its people (e.g. "Merfolk" or "Elves"). Currently only used in the in-game help.
** '''male_name''': user-visible name for the race of the male units (e.g. "Merman"). Currently only used in the in-game unit status.
** '''female_name''': user-visible name for the race of the female units (e.g. "Mermaid"). Currently only used in the in-game unit status.
** '''name''': the default value for the three keys above.
** '''description''': description of this race, used in the race page of the in-game help. Note: currently not used by all mainline races because their descriptions are not ready. But this is already supported by the engine.
** '''male_names''', '''female_names''': lists of names (i.e. non-translatable strings). They are inputted into the Markov name generator to generate random names. ''male_names'' describes units with '''gender=male'''; ''female_names'' describes units with '''gender=female'''.
** '''markov_chain_size''': (default 2) number of letters per "syllable". "Syllables" are groupings of names that the Markov name generator uses to determine names. It does this by running a probability algorithm to guess from the name list which syllables fit well together, which can start or end a name, etc.
** '''num_traits''': is the number of non-repeating traits each unit of this race can be assigned.
** '''ignore_global_traits''': 'yes' or 'no'(default). Determines whether global traits (see [traits] above) are applied.
** '''[trait]''': describes a trait for this race. :
*** '''id''': unique identifier
*** '''availability''': describes whether a trait is "musthave" for a race or is available to "any" unit in a race, including leaders, or "none" if it is not normally available, but should be kept when advancing to this unit type. (Traits not available to the advanced unit type at all, are permanently lost upon advancement.) The default is for a trait to only be available to nonleaders. Currently "any" should not be used for traits available in multiplayer. It can be used for campaign specific traits. (Note that currently "musthave" is somewhat misused to have what are really abilities (''undead'' and ''mechanical'') default from a unit type's race. Ideally someone will eventually extend ''race'' to allow for default abilities. It might also be possible to unify traits and abilities with keys to indicate how you get them and what happens to them when you advance, while allowing them to come from race, unit type and unit definitions. There are also display issues related to doing this.)
*** '''male_name''': text displayed in the status of unit with the trait if the unit is male.
*** '''female_name''': text displayed in the status of unit with the trait if the unit is female.
*** '''name''': text displayed in the status of unit with the trait if none of the two above is used.
*** '''description''': text displayed for the description of the trait.
*** '''[effect]''': described in [[EffectWML]].

* '''[hide_help]''': {{DevFeature}} allow to hide some units from the help. Mainly useful if you can't change these units (e.g. mainline units) and thus can't add a 'hide_help=yes' key to them. The following keys and theirs contents uses an 'OR' logic between them.
** '''type''': list of unit types.
** '''race''': list of races. Equivalent to all unit types of these races.
** '''type_adv_tree''': list of unit types. Equivalent to all these types and their advancement trees.
** '''all''': 'yes' or 'no'(default). 'yes' is equivalent to all unit types (useful before [not])
** '''[not]''': all the previous keys (except 'all') can also be used in [not] sub-tags. And you can use [not] recursively. For example, if you want to only show the Yeti and the human race except the mage tree, uses:
[hide_help]
all=yes
[not]
type=Yeti
race=human
[not]
type_adv_tree=Mage
[/not]
[/not]
[/hide_help]

== See Also ==

* [[UnitTypeWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

UnitsWML

2009-05-17T16:59:42Z

Alink: /* the [units] tag */ add doc for [hide_help]

{{WML Tags}}
== the [units] tag ==

This tag is a top level WML tag which is in game.cfg.
It defines the set of all units in Wesnoth.

The following subtags are recognized:
* '''[unit_type]''': describes one unit type. See [[UnitTypeWML]] for syntax.
* '''[trait]''': describes a global trait.
All races with the attribute '''ignore_global_traits=no''' will have this trait.
See '''[trait]''': below for syntax.
* '''[movetype]''': used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype.
** '''name''': an ID for this movetype. Units with the attribute '''movetype=''name''''' will be assigned this movetype.
** ''flies'' either 'true' or 'false'(default). A unit with ''flies=true'' does not have its image's height adjusted for different terrains.
** '''[movement_costs]''': describes how fast the unit moves on different terrains. The attribute '''terrain=''speed''''' means that the unit will need to use ''speed'' move points to move onto the terrain with '''name=''terrain''''' (see [[TerrainWML]]).
** '''[defense]''': describes how likely the unit is to be hit on different terrains. The attribute '''terrain=''defense''''' means that the unit will be hit ''defense'' percent of the time in the terrain with '''name=''terrain'''''.
** '''[resistance]''': describes how much damage the unit takes from different types of attacks. The attribute '''type=''resistance''''' makes the unit receive '''resistance''' percent of damage, or resist '''100-resistance''' percent of damage from attacks with '''type=''type'''''. So for example, a resistance of fire=110 means, this unit will receive 110% of damage, or have a resistance of -10% as displayed in-game. A value of fire=0 would mean, the unit receives no damage and therefore has a resistance of 100%.
* '''[race]''': is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions.
** '''id''': ID for this race. Units with the attribute '''race=''id''''' will be assigned this race. If missing in old WML, the value of the name key will be used as id.
** '''plural_name''': user-visible name for its people (e.g. "Merfolk" or "Elves"). Currently only used in the in-game help.
** '''male_name''': user-visible name for the race of the male units (e.g. "Merman"). Currently only used in the in-game unit status.
** '''female_name''': user-visible name for the race of the female units (e.g. "Mermaid"). Currently only used in the in-game unit status.
** '''name''': the default value for the three keys above.
** '''description''': description of this race, used in the race page of the in-game help. Note: currently not used by all mainline races because their descriptions are not ready. But this is already supported by the engine.
** '''male_names''', '''female_names''': lists of names (i.e. non-translatable strings). They are inputted into the Markov name generator to generate random names. ''male_names'' describes units with '''gender=male'''; ''female_names'' describes units with '''gender=female'''.
** '''markov_chain_size''': (default 2) number of letters per "syllable". "Syllables" are groupings of names that the Markov name generator uses to determine names. It does this by running a probability algorithm to guess from the name list which syllables fit well together, which can start or end a name, etc.
** '''num_traits''': is the number of non-repeating traits each unit of this race can be assigned.
** '''ignore_global_traits''': 'yes' or 'no'(default). Determines whether global traits (see [traits] above) are applied.
** '''[trait]''': describes a trait for this race. :
*** '''id''': unique identifier
*** '''availability''': describes whether a trait is "musthave" for a race or is available to "any" unit in a race, including leaders, or "none" if it is not normally available, but should be kept when advancing to this unit type. (Traits not available to the advanced unit type at all, are permanently lost upon advancement.) The default is for a trait to only be available to nonleaders. Currently "any" should not be used for traits available in multiplayer. It can be used for campaign specific traits. (Note that currently "musthave" is somewhat misused to have what are really abilities (''undead'' and ''mechanical'') default from a unit type's race. Ideally someone will eventually extend ''race'' to allow for default abilities. It might also be possible to unify traits and abilities with keys to indicate how you get them and what happens to them when you advance, while allowing them to come from race, unit type and unit definitions. There are also display issues related to doing this.)
*** '''male_name''': text displayed in the status of unit with the trait if the unit is male.
*** '''female_name''': text displayed in the status of unit with the trait if the unit is female.
*** '''name''': text displayed in the status of unit with the trait if none of the two above is used.
*** '''description''': text displayed for the description of the trait.
*** '''[effect]''': described in [[EffectWML]].
* '''[hide_help]''': allow to hide some units from the help. Mainly useful if you can't change these units (e.g. mainline units) and thus can't add a 'hide_help=yes' key to them. The following keys and theirs contents uses an 'OR' logic between them.
** '''type''': list of unit types.
** '''race''': list of races. Equivalent to all unit types of these races.
** '''type_adv_tree''': list of unit types. Equivalent to all these types and their advancement trees.
** '''all''': 'yes' or 'no'(default). 'yes' is equivalent to all unit types (useful before [not])
** '''[not]''': all the previous keys (except 'all') can also be used in [not] sub-tags. And you can use [not] recursively. For example, if you want to only show the Yeti and the human race except the mage tree, uses:
[hide_help]
all=yes
[not]
type=Yeti
race=human
[not]
type_adv_tree=Mage
[/not]
[/not]
[/hide_help]

== See Also ==

* [[UnitTypeWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

SummerOfCodeIdeas

2009-03-20T00:23:42Z

Alink: add links to irc logs

This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):

== I want to be one of your Google Summer of Code students, what should I do... ==

Here is a quick list of things to do to get you started
* Create an account on gna.org
* Create an account on the wesnoth forum, and tell an admin on the IRC channel to mark is as a GSoC Student account (Admins are boucman, Ivanovic, mordante, Shadow_Master, Sirp and Turuk)
* Join the irc channel (#wesnoth-dev on irc.freenode.net) and introduce yourself. We will not give formal interviews, but we will clearly favor people we have learned to know during the selection process (basically communication via IRC is mandatory for our project! it is the main way of "every day communication" for Wesnoth. For the same reason, it's also a good idea to regularly read the [http://wesnoth.debian.net/?C=M;O=A IRC logs].).

* Start a wiki page about your idea, add a link on the bottom of this page and add this information on it:
** List your account names (gna, forum, irc nick) so that we can recognize you
** Fill the questionnaire on this page: [[SoC_Information_for_Google#Does_your_organization_have_an_application_template_you_would_like_to_see_students_use.3F_If_so.2C_please_provide_it_now.| List of questions to answer]]
** Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done
** Add a link to the page at the bottom of this page

* Though not mandatory, it is highly advisable to go to the [[EasyCoding]] and [[NotSoEasyCoding]] pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use your gna account when submitting these patches so we know who it is coming from. You can also implement some features from our feature request database at gna. When you implement something, also list it on your own page with a reference to the patch.

* For working on Wesnoth you have to be able to compile trunk. To do so you should have a look at the [[WesnothSVN|page about svn]] and afterwards [[CompilingWesnoth|compile Wesnoth svn]].

* Once you have everything done here and think your idea is okay, go to [http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants page at google] to submit your application. You have to submit it before '''Date to be supplied later''' or you have no chance to get in!

== List of Ideas for the Project (Suggestions from the wesnoth developers) ==

Here is only a short description of possible Ideas we have, each has a page of its own with a more detailed version on it.

=== Optimize implementation of WML for memory usage ===

Based on this idea: [http://dave.wesnoth.org/?p=9] optimize WML to minimize its memory usage. High memory usage has been a problem for Wesnoth, and this project will aim to reduce it.

=== Implement campaign statistics reports on stats.wesnoth.org ===

Wesnoth has an infrastructure which records details of campaigns that players play into a centralized MySQL database. However, we only have rudimentary reports based on this MySQL database available at this time, at [http://stats.wesnoth.org].

This project would involve writing a stats reporting web site which would take the data from the MySQL database and produce reports in chart and table form. Campaign designers would be able to use these reports to gather feedback on their campaigns and get ideas for improvements.

A student could largely make their choice of infrastructure for creating the Website -- whether they prefer Python, Perl, Ruby, PHP, etc. This is a great opportunity for someone who doesn't want to dive into hardcore C++ to make a valuable contribution to Wesnoth.

=== Extending the Multiplayer server ===

Our multiplayer community is generally strong and healthy, but we believe its growth is limited by some problems in the interface of the multiplayer lobby.

[[SoC Ideas Multiplayer server]] - Full version of the idea, with detailed information

=== Addon server ===
Wesnoth has an addon server which offers users to upload user
made content (UMC). This allows all other users of Wesnoth
to easily download and install this content. The server was
originally written for user-made campaigns but contains a lot
more types of addons nowadays. Both the server side and the
client side need to be improved.

[[SoC Ideas Addon Server]] - Full version of the idea, with detailed information

=== WML validation schemes ===
Wesnoth uses WML as basic data structure. Over the years
this language has evolved and got more complex. At the
moment the WML is validated at runtime and in case of a
problem the engine stops. With schemes these problems can
be validated when loading the WML, making it easier to find
problems before running into them.

[[SoC Ideas Schemes]] - Full version of the idea, with detailed information

=== Write a primitive library for Formula AI ===

Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth: [[FormulaAI]]

The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done. But keep in mind that [[WhyWritingAWesnothAIIsHard|writing an AI for Wesnoth is difficult]].

Writing a whole AI is so complicated that we believe it can't be done in a single Summer of code. All proposals should keep that in mind and try to identify an interesting subset that would be workable in the limited time of a summer of code

[[SoC Ideas FormulaAI]] - Full version of the idea, with detailed information

=== Savegame reorganization ===
The savegame formats of Wesnoth for single player campaigns
and multiplayer differ from each other. And they are processed
differently as well. Now there is an additional request coming
up: Multiplayer campaigns. The task will be to unify the savegames
for all types of scenarios in order to provide a maintainable code
again.

[[SoC Ideas Savegame]] - Full version of the idea, with detailed information

=== Other possible ideas to be fleshed out ===
A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the cave generator) etc.

=== Make your own ideas ===
If you have your own idea the best thing is to join IRC wesnoth-dev at irc.freenode.net and discuss the idea with the developers there. If the developers think your idea is interesting and like the feature you can start to turn it into a full proposal. Once done discuss it again on IRC so the developers can accept your idea.

== Information about our Project ==
The information we provided google with about our project can be looked up at the site [[SoC Information for Google]].

Also see the [[DeveloperResources]] link (from the [[Project]] page).

== People to bug on IRC ==
We have prepared a list of people with their "area of competence". This is to give you an idea on which areas those people can be of help for you. Of course you should always just ask in the IRC chan, but those are the most likely ones to answer questions in the respective area. And here is the list:

[[SoC People to bug on IRC]]

== GSoC Student pages ==

Please add a link to your wiki page below

[[SummerOfCodeProposal_Velory| Velory - SoC Proposal]]

[[SummerOfCodeProposal_AI_Improvement_Crab| Crab - SoC Proposal - AI Improvement]]

[[SummerOfCodeProposal_Sparksteel | Sparksteel - Improving the AI engine design]]

[[Category:Summer of Code|*]]

Distributing content

2008-08-11T09:08:52Z

Alink: /* The Campaign Server */ remove info about a 1.5.1 bug

== The Forum ==

The [http://www.wesnoth.org/forum/ BFW forum] is a good way to distribute small creations, like single multiplayer maps. Larger creations, like unit packs or campaigns, should be compressed before uploading them. Note that you may encounter a size limit on attachments.

Also, there is a [http://www.wesnoth.org/forum/viewtopic.php?t=2014 legal announcement] that you should read before distributing anything on the forum. Basically, by posting you say that you own the license to what you are posting, and that you are licensing it under the [http://www.gnu.org/copyleft/gpl.html General Public License].

== The Campaign Server ==

The campaign server is the preferred way to distribute your creations, but it is more suited for larger projects. It currently lacks advanced organization features such as filtering and reviewing, so adding hundreds of little things makes it harder to find anything. Basically, the server should not be used to post single maps, units, songs, or artwork, but map packs, campaigns, entire eras, music packs, and unit packs are fine.

Once you are ready to publish, here is how you access the campaign server:
# Open Wesnoth
# Select "Get Add-ons" from the main menu
# Select "Publish Campaign: ''Your Campaign Name''" (the last entry in the list of campaigns)

Anything you distribute on the server will be upload from and downloaded to the ''userdata''/data/campaigns directory regardless of what it is (units, maps, campaign, etc). For this reason, you need three things in the campaigns directory to distribute via the server:
# A .cfg file, for example MyCampaign.cfg
# A .pbl file, for example MyCampaign.pbl
# A folder, for example MyCampaign

==== General Reading ====
* [[BuildingCampaignsThePBLFile|General information about the .pbl file]] - It has a campaign flavor, but it is adaptable to any content
* [[PblWML|Syntax reference for the .pbl file]]

==== Content-specific instructions ====
* Campaign - see the [[BuildingCampaigns|Buidling Campaigns Article]]
** [[BuildingCampaignsDistribution|About distributing campaigns]]
* Multiplayer era - see the [[BuildingFactions#Adding_a_whole_new_era_with_its_own_factions_-_modular|MP Era Article]]
* Unit pack - see the [[BuildingUnits#Distributing_your_unit|Units Article]]
* Map pack - see the
* Others?

(If I don't have BFW on the computer I'm working on, but I have it on a different computer, on which I don't Know how to find it's "./wesnoth/userdata" folder, how do I publish my Campaigns?-Drake Raider)

(To Find that folder, go into prefrences and make it in a window. Then at the top of the screen there should be a menu. Not at the top of the game screen but computer screen. Saerch the menu until you see user data folder.-Knight)

==== License ====
You should note that by uploading anything to the campaign server, you say that you own the license to all content in your upload and that it is under the GPL. Whenever you upload or update your content pack, you will have to say "OK" to this statement: "All campaigns uploaded to this server must be licensed under the terms of the GNU General Public License (GPL). By uploading content to this server, you certify that you have the right to placethe content under the conditions of the GPL, and choose to do so."

== See Also ==

* [[Create]]
* [[BuildingCampaignsDistribution]]
* [[BuildingCampaignsThePBLFile]]
* [[PblWML]]
* [[Wesnoth:Copyrights]]

[[Category:Create]]

Distributing content

2008-07-08T10:05:18Z

Alink: /* The Campaign Server */ note about a 1.5.1 bug and a trick yo avoid it

== The Forum ==

The [http://www.wesnoth.org/forum/ BFW forum] is a good way to distribute small creations, like single multiplayer maps. Larger creations, like unit packs or campaigns, should be compressed before uploading them. Note that you may encounter a size limit on attachments.

Also, there is a [http://www.wesnoth.org/forum/viewtopic.php?t=2014 legal announcement] that you should read before distributing anything on the forum. Basically, by posting you say that you own the license to what you are posting, and that you are licensing it under the [http://www.gnu.org/copyleft/gpl.html General Public License].

== The Campaign Server ==

The campaign server is the preferred way to distribute your creations, but it is more suited for larger projects. It currently lacks advanced organization features such as filtering and reviewing, so adding hundreds of little things makes it harder to find anything. Basically, the server should not be used to post single maps, units, songs, or artwork, but map packs, campaigns, entire eras, music packs, and unit packs are fine.

Once you are ready to publish, here is how you access the campaign server:
# Open Wesnoth
# Select "Get Add-ons" from the main menu
# Select "Publish Campaign: ''Your Campaign Name''" (the last entry in the list of campaigns)

{{DevFeature}} Version 1.5.1 has a bug hiding the last entry of these options. You can use 1.5.0 or trunk to upload an add-on. Another trick is to create (but not publish) a second dummy add-on with a name starting by 'z'. Because of the alphabetical order, this one will take the bad missing row, making accessible the option of your real add-on.

Anything you distribute on the server will be upload from and downloaded to the ''userdata''/data/campaigns directory regardless of what it is (units, maps, campaign, etc). For this reason, you need three things in the campaigns directory to distribute via the server:
# A .cfg file, for example MyCampaign.cfg
# A .pbl file, for example MyCampaign.pbl
# A folder, for example MyCampaign

==== General Reading ====
* [[BuildingCampaignsThePBLFile|General information about the .pbl file]] - It has a campaign flavor, but it is adaptable to any content
* [[PblWML|Syntax reference for the .pbl file]]

==== Content-specific instructions ====
* Campaign - see the [[BuildingCampaigns|Buidling Campaigns Article]]
** [[BuildingCampaignsDistribution|About distributing campaigns]]
* Multiplayer era - see the [[BuildingFactions#Adding_a_whole_new_era_with_its_own_factions_-_modular|MP Era Article]]
* Unit pack - see the [[BuildingUnits#Distributing_your_unit|Units Article]]
* Map pack - see the
* Others?

(If I don't have BFW on the computer I'm working on, but I have it on a different computer, on which I don't Know how to find it's "./wesnoth/userdata" folder, how do I publish my Campaigns?-Drake Raider)

(To Find that folder, go into prefrences and make it in a window. Then at the top of the screen there should be a menu. Not at the top of the game screen but computer screen. Saerch the menu until you see user data folder.-Knight)

==== License ====
You should note that by uploading anything to the campaign server, you say that you own the license to all content in your upload and that it is under the GPL. Whenever you upload or update your content pack, you will have to say "OK" to this statement: "All campaigns uploaded to this server must be licensed under the terms of the GNU General Public License (GPL). By uploading content to this server, you certify that you have the right to placethe content under the conditions of the GPL, and choose to do so."

== See Also ==

* [[Create]]
* [[BuildingCampaignsDistribution]]
* [[BuildingCampaignsThePBLFile]]
* [[PblWML]]
* [[Wesnoth:Copyrights]]

[[Category:Create]]

UnitTypeWML

2008-06-28T18:32:40Z

Alink: add info about the old "attacks"

{{WML Tags}}
== The [unit] tag ==

Each '''[unit]''' tag defines one unit type. (for the use of [unit] to create a unit, see [[SingleUnitWML]]) Note: this tag has been renamed {{DevFeature}} and is now '''[unit_type]'''.

Unit animation syntax is described in [[AnimationWML]].

The following key/tags are recognized:
{| class="gallery" style="text-align:left;"
|-
! advancefrom
| the previous level unit on the advancement tree
- allows a campaign-specific unit to be spliced into an already existing advancement tree. It should generally be used only inside a campaign ifdef, to prevent changes to other campaigns. This tag makes changes to the ''advanceto'' and ''experience'' keys of a base unit to make it advance into this unit. It takes these keys: ** ''unit'' the id of the base unit from which this unit advances. This adds the unit into the list of units which ''unit'' can advance into. ** [[experience]] is optional. If present and lower than the experience already required for the base unit to advance, then the experience to advance is lowered. Note: this will also lower the experience required to advance to other units which the base unit can advance into.
|-
! advanceto
| When this unit has experience greater than or equal to [[experience]], it is replaced by a unit of the type that the value of [[advanceto]] refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.
|-
! alignment
| how the unit's damage should be affected by its lawful bonus (See [[TimeWML]]).
|-
! cost
| when a player recruits a unit of this type, the player loses ''cost'' gold. If this would cause gold to drop below 0, the unit cannot be recruited.
|-
! do_not_list
| {{DevFeature}} Not used by the game, but by tools for browsing and listing the unit tree. If this is 'yes', the unit will be ignored by these tools.
|-
! experience
| When this unit has experience greater than or equal to ''experience'', it is replaced by a unit with 0 experience of the type that the value of ''advanceto'' refers to. All modifications that have been done to the unit are applied to the unit it is replaced by.
|-
! gender
| has a value of either ''male'' or ''female'', and determines which of the keys ''male_names'' and ''female_names'' should be read. When a unit of this type is recruited, it will be randomly assigned a name by the random name generator, which will use these names as a base.
|-
! hide_help
| determines if the unit type will appear in the in-game help. Possible values ''true'' and ''false'', defaults to ''false''.
|-
! hitpoints
| the maximum HP that the unit has, and the HP it has when it is created.
|-
! id
|the value of the ''type'' key for units of this type. An ''id'' should consist only of alphanumerics and spaces (or underscores). ''type'' keys are found in [[SingleUnitWML]] and [[FilterWML]]. For example, id=Drake Flare
WARNING : characters "$", "&", "*", "(" and ")" are illegal for use in the unit id and must be avoided because they might lead to corrupted saved games
|-
! level
| the amount of upkeep the unit costs. After this unit fights, its opponent gains ''level'' experience. See also kill_experience ([[GameConfigWML]]), and leadership ([[AbilitiesWML]]).
|-
! movement
| the number of move points that this unit recieves each turn.
|-
! movetype
| See '''[[movetype]]''', [[UnitsWML]]. Note that the tags '''[[movement_costs]]''', '''[[defense]]''', and '''[[resistance]]''' can be used to modify this movetype.
|-
! attacks
| the number of times that this unit can attack each turn.
|-
! name
|(translatable) displayed in the Status Table for units of this type.
|-
! num_traits
| the number of traits that units of this type should receive when they are recruited, overriding the value set in the [race] tag.
|-
! profile
| the portrait image to use for this unit type. You can also set a portrait for an individual unit instead of the whole unit type (see [[SingleUnitWML]]).
|-
! race
| See '''[race]''', [[UnitsWML]]. Also used in standard unit filter (see [[FilterWML]]).
|-
! unit_description
| (translatable) the text displayed in the unit descriptor box for this unit. Default 'No description available...'.
|-
! undead_variation
| Which image to use when a unit of this type is killed by a unit with the plague ability.
|-
! usage
| the way that the AI should recruit this unit, as determined by the scenario designer. (See ''recruitment_pattern'', [[AiWML]]). The following are conventions on usage: ** 'scout' Fast, ** 'fighter' Melee fighter, ** 'archer' Ranged fighter, ** 'mixed fighter' Melee and ranged fighter, and ** 'healer' Specialty 'heals' or 'cures'.
|-
! zoc
| if "yes" the unit will have a zone of control regardless of level. If present but set to anything other than "yes," the unit will have no zone of control. If the tag is omitted, zone of control is dictated by unit level (level 0 = no zoc, level 1+ = has zoc).
|}
==== After max level advancement (AMLA) ====
* '''[advancement]''': describes what happens to a unit when it reaches the XP required for advancement. It is considered as an advancement in the same way as advancement described by '''advanceto'''; however, if the player chooses this advancement, the unit will have one or more effects applied to it instead of advancing.
** '''description''': a description (see [[DescriptionWML]]) displayed as the option for this advancement if there is another advancement option that the player must choose from; otherwise, the advancement is chosen automatically and this key is irrelevant.
** '''image''': an image to display next to the description in the advancement menu.
** '''max_times''': default 1. The maximum times the unit can be awarded this advancement.
** '''strict_amla''': (yes|no) default=no. Disable the AMLA if the unit can advance to another unit.
** '''require_amla''': An optional list of AMLA ''id'' keys that act as prerequisites for this advancement to become available. Order is not important, and an AMLA id can be repeated any number of times to indicate that another advancement must be chosen several times before this advancement option will become available.
*** example: <tt>require_amla=tough,tough,incr_damage</tt> assumes there exist other [advancement] options called ''id=tough'' and ''id=incr_damage''. Once ''tough'' is chosen twice and ''incr_damage'' is chosen once, then the current [advancement] will become available.
*** ''require_amla=tough,incr_damage,tough'' is an equivalent way of expressing this.
** '''[effect]''': A modification applied to the unit whenever this advancement is chosen. See [[EffectWML]]

==== Other tags ====
* '''[base_unit]''': Contains one attribute, '''id''', which must be the ID of a unit type. If specified, the UnitWML for that unit is copied into this one. Subsequent attributes modify the copy. (1.3.7 and later versions only.)
* '''[attack]''': one of the unit's attacks.
** '''description''': a translatable text for name of the attack, to be displayed to the user.
** '''name''': the name of the attack. Used as a default description, if ''description'' is not present, and to determine the default icon, if ''icon'' is not present (if ''name=x'' then ''icon=attacks/x.png'' is assumed unless present). Non-translatable. Used for the ''has_weapon'' key; see [[FilterWML]]
** '''type''': the damage type of the attack. Used in determining resistance to this attack (see '''[resistances]''', [[UnitsWML]]). Possible values are 'blade', 'pierce', 'impact', 'fire', 'cold', and 'arcane'.
** '''[specials]''': contains the specials of the attack. See [[AbilitiesWML]].
** '''icon''': the image to use as an icon for the attack in the attack choice menu, as a path relative to the images directory.
** '''range''': the range of the attack. Used to determine the enemy's retaliation, which will be of the same type. Also displayed on the status table in parentheses; 'melee'(default) displays "melee", while 'ranged' displays "ranged". Range can be anything. Standard values are now "melee" and "ranged". From now on, ''short'' and ''long'' will be treated as totally different ranges. You can create any number of ranges now (with any name), and units can only retaliate against attacks for which they have a corresponding attack of the same range. This value is translatable.
** '''damage''': the damage of this attack
** '''number''': the number of strikes per attack this weapon has
For those two following settings, the engine usually chooses the attack with the best average total damages * weight (default weight = 1.0).
** '''attack_weight''': helps the AI to choose which attack to use when attacking; highly weighted attacks are more likely to be used. Setting it to 0 disables the attack on attack
** '''defense_weight''': used to determine which attack is used for retaliation. This affects gameplay, as the player is not allowed to determine his unit's retaliation weapon. Setting it to 0 disable the attacks on defense
** '''movement_used''': determines how many movement points using this attack expends. By default all movement is used up, set this to 0 to make attacking with this attack expend no movement.

** '''[animation]'''
:: This describes an animation for this attack. If multiple animations are present, one will be randomly chosen each time the unit attacks. See [[AnimationWML]] for possible keys.

* '''[defend]''': See [[AnimationWML]]
* '''[death]''': See [[AnimationWML]]
* '''[teleport_anim]''': See [[AnimationWML]]
* '''[extra_anim]''': See [[AnimationWML]]
* '''[event]''': Any [event] written inside the [unit] tag will get included into any scenario where a unit of this type appears in. Note that such events get included when a unit of this type first appears in the scenario, not automatically when the scenario begins (meaning that ''name=prestart'' events, for example, would usually never trigger). See [[EventWML]] and [[WML_Abilities]]

* '''[variation]''': Defines a variation of a unit. Variations are invoked with an [effect] tag. They are currently used for graphical variations (giving character sprites new weapons) but theoretically you could do anything with it.
** '''variation_name''': The name of the variation.
** '''inherit''': if ''yes'', inherits all the properties of the base unit.
: All other keys in '''[variation]''' are the same as for '''[unit]''' itself.

* '''[male]''', '''[female]''': They can contain all '''[unit]''' tags, to specify a variation of different gender for a unit.
** '''inherit''': if ''yes'', inherits all the properties of the base unit. defaults to yes

* '''[abilities]''': Defines the abilities of a unit. See [[AbilitiesWML]]

== See Also ==

* [[AnimationWML]]
* [[ReferenceWML]]
* [[TerrainWML]]

[[Category: WML Reference]]

IntroWML

2007-10-11T17:03:14Z

Alink: /* The [story] tag */ add the centered key

{{WML Tags}}
== The [story] tag ==

The '''[story]''' tag is a series of images and text to display as the first part of the intro screen.

The only tag recognized for '''[story]''' is '''[part]'''.
Each '''[part]''' represents one image and text.
The part is displayed until the user clicks on the "Next>>>" button.

The following key/tags are recognized for '''[part]''':
* ''background'' the image to display. Story images are usually created specially for this purpose, except for the map.
* ''story'' (translatable) the text to display below the image.
* ''show_title'' whether to display the title of the scenario at the top
* ''music'' change to this music
* '''[image]''' an image to display.
** ''x'', ''y'' the location in pixels to draw the image. The x,y pixel location is relative to the image specified in background, but not in a normal way. The background image is scaled up or down to fill the screen resolution, but images are never scaled in size. Their coordinates, however, are scaled. It's basically a big pain in the rear. Example: I have a background image at 640x480 and an overlay at 640x480. To horizontally center the overlay on a 1024x768 screen, I want to position it at x=192. This is because 1024-640 = 384 total extra pixel space, then 384/2 = 192. This results in equal space on both sides of the overlay. However, now you have to account for the background scaling. The background image at 640 is scaled up to 1024, a scaling factor of 1.6. All image locations are also scaled up, so the overlay is not drawn at x=192, rather it is drawn at x=192*1.6 or x=307! To compensate for this, divide the desired pixel location by the scaling factor. In the example, x_compensated=192/1.6 or x_compensated=120.
** ''centered'' {{DevFeature}} If "yes", use the center of the image when placing at the x,y coordinates, which is useful since this image is not scaled like the background is (and by centering no need to worry about this).
** ''file'' the image to display.
** ''delay'' the time to delay drawing this image.

See also the '''DOT''' and '''CROSS''' macros, in [[UtilWML]]

== See Also ==

* [[ReferenceWML]]

[[Category: WML Reference]]

User:Alink

2007-10-11T12:27:35Z

Alink: Flush this outdated and unmaintained content

UnitsWML

2007-09-19T12:58:16Z

Alink: update [race] keys

{{WML Tags}}
== the [units] tag ==

This tag is a top level WML tag which is in game.cfg.
It defines the set of all units in Wesnoth.

The following subtags are recognized:
* '''[unit]''' describes one unit type. See [[UnitWML]] for syntax.
* '''[trait]''' describes a global trait.
All races with the attribute '''ignore_global_traits=no''' will have this trait.
See '''[trait]''' below for syntax.
* '''[movetype]''' used to make shortcuts to describe units with similar terrain handicaps. Units from the same advancement tree should generally have the same movetype.
** ''name'' an ID for this movetype. Units with the attribute '''movetype=''name''''' will be assigned this movetype.
** ''flies'' either 'true' or 'false'(default). A unit with ''flies=true'' does not have its image's height adjusted for different terrains.
** '''[movement_costs]''' describes how fast the unit moves on different terrains. The attribute '''terrain=''speed''''' means that the unit will need to use ''speed'' move points to move onto the terrain with '''name=''terrain''''' (see [[TerrainWML]]).
** '''[defense]''' describes how likely the unit is to be hit on different terrains. The attribute '''terrain=''defense''''' means that the unit will be hit ''defense'' percent of the time in the terrain with '''name=''terrain'''''.
** '''[resistance]''' describes how much damage the unit takes from different types of attacks. The attribute '''type=''resistance''''' makes the unit receive '''resistance''' percent of damage, or resist '''100-resistance''' percent of damage from attacks with '''type=''type'''''. So for example, a resistance of fire=110 means, this unit will receive 110% of damage, or have a resistance of -10% as displayed in-game. A value of fire=0 would mean, the unit receives no damage and therefore has a resistance of 100%.
* '''[race]''' is used to make shortcuts to describe units with similar names. Units from the same advancement tree should generally have the same race. Also, units with the same race should generally be recruitable by the same sides/factions.
** ''id'' {{DevFeature}} ID for this race. Units with the attribute '''race=''id''''' will be assigned this race. If missing in old WML, the value of the name key will be used as id.
** ''name'' stable version use this as ID for this race. {{DevFeature}} Now it's the user-visible name for its people (e.g. "Elves"). Currently only used in the in-game help.
** ''description'' description of this race, used in the race page of the in-game help. Note: currently not used by mainline races because their descriptions are not ready. But this is already supported by the engine.
** ''male_names'', ''female_names'' lists of names (i.e. non-translatable strings). They are inputted into the Markov name generator to generate random names. ''male_names'' describes units with '''gender=male'''; ''female_names'' describes units with '''gender=female'''.
** ''markov_chain_size'' (default 2) number of letters per "syllable". "Syllables" are groupings of names that the Markov name generator uses to determine names. It does this by running a probability algorithm to guess from the name list which syllables fit well together, which can start or end a name, etc.
** ''not_living'' 'yes' or 'no'(default). Units with '''not_living=yes''' cannot be poisoned, drained from, or plagued (see [[AbilitiesWML]]). {{DevFeature}} ''not_living'' is no longer a property of race. Instead it is a per unit state that derives from the undead and mechanical traits.
** ''num_traits'' is the number of non-repeating traits each unit of this race can be assigned.
** ''ignore_global_traits'' 'yes' or 'no'(default). Determines whether global traits (see [traits] above) are applied.
** '''[trait]''' describes a trait for this race. :
*** ''id'' unique identifier
*** ''availability'' {{DevFeature}} describes whether a trait is "musthave" for a race or is available to "any" unit in a race, including leaders, or "none" if it is not normally available, but should be kept when advancing to this unit type. (Traits not available to the advanced unit type at all, are permanently lost upon advancement.) The default is for a trait to only be available to nonleaders. Currently "any" should not be used for traits available in multiplayer. It can be used for campaign specific traits. (Note that currently "musthave" is somewhat misused to have what are really abilities (''undead'' and ''mechanical'') default from a unit type's race. Ideally someone will eventually extend ''race'' to allow for default abilities. It might also be possible to unify traits and abilities with keys to indicate how you get them and what happens to them when you advance, while allowing them to come from race, unit type and unit definitions. There are also display issues related to doing this.)
*** ''male_name'' {{DevFeature}} text displayed in the status of unit with the trait if the unit is male.
*** ''female_name'' {{DevFeature}} text displayed in the status of unit with the trait if the unit is female.
*** ''name'' text displayed in the status of unit with the trait if none of the two above is used.
*** ''description'' text displayed for the description of the trait.
*** '''[effect]''', described in [[EffectWML]].

== See Also ==

* [[UnitWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

GameConfigWML

2007-07-20T14:27:05Z

Alink: /* The [game_config] tag */ added some keys about masks used on map

This page has several unknown informations; they are represented by '???'.
Feel free to replace them with actual data.

{{WML Tags}}
== The [game_config] tag ==

This tag is a top level WML tag which can only be used once because
it defines basic settings that are used everywhere in the game.
In official versions of Wesnoth it is in ''game.cfg''; values used there are labeled 'standard'.

The following keys are recognised
* ''base_income'' (standard 2) how much your leader earns without any villages
* ''heal_amount'' (standard 4) how much the 'heal' ability (see [[AbilitiesWML]]) heals per unit
* ''healer_heals_per_turn'' (standard 8) how much a healer can heal per turn (total).
Healing is distributed clockwise, starting north of the healer,
until ''healer_heals_per_turn'' hitpoints have been regenerated.
* ''cure_amount'' (standard 8) how much the 'cure' ability heals per unit
* ''curer_heals_per_turn'' (standard 18) how much a curer can heal per turn (total)
* ''rest_heal_amount'' (standard 2) how much HP a unit gains each turn it rests
* ''recall_cost'' (standard 20) how much it costs to recall a unit; this cost is independent of level.
* ''kill_experience'' (standard 8)
killing a unit with ''level=X'' will give ''X''*''kill_experience'' experience to the killing unit.
However, if a unit has ''level=0'', it will still give half of ''X'' experience.

* ''icon'' (standard 'wesnoth-icon.png') the game icon file
* ''title'' (standard 'misc/title.png') the title screen image
* ''logo'' (standard 'misc/logo.png') the wesnoth logo which will be put over the title image
* ''title_music'' (standard 'main_menu.ogg') the music to play at the title screen
* ''anonymous_music'' (standard 'main_menu.ogg') the music to play during an unknown faction turn (1.1.x only)

* ''logo_x'' (standard 292) the x position of the logo on the title screen
* ''logo_y'' (standard 120) the y position of the logo on the title screen
* ''buttons_x'' (standard 760) the x position of the buttons on the title screen
* ''buttons_y'' (standard 330) the y position of the buttons on the title screen
* ''buttons_padding'' (standard 20) space between buttons, and border in main menu
* ''tip_x'' (standard 100) space between the button panel left edge and the tip-of-the-day panel right edge
* ''tip_y'' (standard 500) not used (the bottom right corner of the tip-of-the-day panel is pegged to align with the bottom of the button panel)
* ''tip_width'' (standard 495) max width in pixels of the tip-of-the-day panel. The width will actually adjust to be the smallest size necessary to fit the text. Once the max width is reached, if text must flow onto multiple lines, then the height will also automatically adjust.
* ''tip_padding'' (standard 20) space between the edge of the tip-of-the-day panel and an imaginary bounding box containing the text inside the panel

* ''map_image'' (standard 'maps/wesnoth.png') the background image for the "About" screen
* ''sidebar_image'' (standard 'misc/rightside.png') border of window when displaying unit statistics
* ''sidebar_image_bottom'' (standard 'misc/rightside-bottom.png') border of image when displaying unit statistics
* ''energy_image'' (standard 'misc/bar-energy.png') the images used to display hp/xp bars.
* ''moved_ball_image'' (standard 'misc/ball-moved.png') the orb image to add on top of the hp bar for player's moved units; see 'Orbs', [[WesnothManual]]
* ''unmoved_ball_image'' (standard 'misc/ball-unmoved.png') like ''moved_ball_image'', but for player's unmoved units
* ''partmoved_ball_image'' (standard 'misc/ball-partmoved.png') like ''moved_energy_image'', but for player's partially moved units
* ''flag_image'' (standard 'image/flag'terrain/flag-1.png:150,terrain/flag-2.png:150,terrain/flag-3.png:150,terrain/flag-4.png:150') the default flag animation to mark captured villages (if no custom flag is defined in the [side] tag). By example, this animation has 4 frames of 150ms each. An automatic side-coloring is applied.
* ''flag_icon_image'' {{DevFeature}} (standard 'flags/flag-icon.png') the default flag icon to indicate the side playing in the statusbar (if no custom flag_icon is defined in the [side] tag). An automatic side-coloring is applied.

* ''cross_image'' (standard 'misc/cross.png') the cross image displayed on the map at start of scenarios; see [[IntroWML]]
* ''dot_image'' (standard 'misc/dot.png') the dot image used to draw a path on the map before scenarios

* ''footprint_left_nw'', ''footprint_left_n'', ''footprint_right_nw'', ''footprint_right_n''
images used to display the path that a unit would take to the tile the cursor is on.
The first image of each key is used for tiles which would take only 1 movement point for the selected unit to move onto;
the second for ones which would take more.
The 'n' and 'nw' designations distinguish between tiles which are moved from orthogonally and diagonally in the same way as described in '''[missile_frame]''', [[AttackWML]].
The 'left' and 'right' designations are used alternately throughout the path;
however, the standard values are the same for 'left' and 'right'.

* ''terrain_mask_image'' (standard 'terrain/alphamask.png') used to give a hex-shape from a rectangular image.
* ''grid_image'' (standard 'terrain/grid.png') the image used by the grid option
* ''unreachable_image'' (standard 'terrain/darken.png') the stripes mask used to show unreachable locations

* ''missile_n_image'' (standard 'projectiles/missile-n.png') orthogonal missile image to use if none is specified;
see ''image'', '''[missile_frame]''', [[AttackWML]]
* ''missile_ne_image'' (standard 'projectiles/missile-ne.png') diagonal missile image to use if none is specified;
see ''image_diagonal'', '''[missile_frame]''', [[AttackWML]]
* ''observer_image'' (standard 'misc/eye.png') the image to use for observer ???
* ''download_campaign_image'' (standard no image) the icon for the "Download more Campaigns" campaign menu option.

== See Also ==

* [[ReferenceWML]]

[[Category: WML Reference]]

ImagePathFunctions

2007-07-20T14:01:03Z

Alink: /* Syntax */ we managed to keep ~TC so remove the warning

ReportingBugs

2007-06-22T19:22:47Z

Alink: /* Who To Bug */ add myself as mouse maintainer

== Where to report bugs ==
The prefered way to report bugs is through our bug tracking system on Gna, but you can also post your problem to the forums.
* [http://bugs.wesnoth.org/ Wesnoth bugs page on Gna]
* [http://www.wesnoth.org/forum/viewforum.php?f=4 Wesnoth forum - Technical Support]

== Needed information ==
* What version of the game are you running?
* Have you built (from sources) the game by yourself? gcc/g++ version? SDL library versions?
* What operating system are you using? What version/release of that operating system?
* Can you reproduce the problem? If you can please provide steps to do it.
On special request another note: Use common sense! If you know the information can't be relevant to your report simply omit it. Nevertheless too much information usually doesn't hurt.

== Guidelines for reporting bugs ==
# First, please make sure the bug you are reporting has not already been fixed (consult http://changelog.wesnoth.org/ to see the history of changes to the game).
# If it hasn't been fixed yet, please check that the bug hasn't already been reported, by [bugs.wesnoth.org].
# If your bug or feature request hasn't been fixed and has not yet been submitted, please go ahead and report it.
# Please post only one bug per bug report. If you have multiple bugs that are related, you can cross reference them.

Note that feature requests should usually be discussed on the forums first, or they will generally be ignored until there is evidence that such a feature would be generally liked.

Keep bug reports to the point, and make sure your bug is easily reproducible given the information you provide. Clearly written, reproducible single bug reports will get attention before those reports that mix several different bugs into one report, or that are incomprehensible.

If there is already an existing bug report, do not hesitate to add a comment with your details - this way we know when some bug is getting "popular".

''Please login to Gna! before reporting bugs''

An account at Gna! is free and takes very little time to set up. You can submit anonymous bug reports, but then you will have to keep an eye on the bug report in case developers ask for clarification, which will delay your bug being fixed. If you login, you will receive notifications of any changes to your bug reports, which speeds things up considerably.

=== In-play problems ===
If it is in-play problem that you can reproduce, save the game and send the savegame to us with details how to reproduce the problem from the savegame.

=== Problems with scenarios ===
If it is a problem with a contributed scenario (like the ones on the Campaign Server), please report the problem to the maintainer of the scenario, not as a bug in Wesnoth itself. Bugs in the [[MainlineScenarios]] should be reported in the bug tracker.

=== Multiplayer out-of-sync errors ===
* We need wesnoth stdout/stderr output from person who got the error (if you started wesnoth in terminal stdout/stderr is in that terminal).
* We need savegame from person who got the error.
* Savegame from some other player if possible.
* The person who got the error should report the bug, other players can then add their savegames to that bug.

=== Segfault ===
* In Unix follow the instructions at [[DebuggingWesnoth]] to generate information to send to a developer.
* In NT based OS's (including Win2k, XP) you enable/configure core dumps by running 'drwtsn32', the location of the dumps can be changed there.
* In Mac OS X, you can enable Crash Reporter -- the output is a backtrace. Run Applications -> Utilities -> Console to see log output. See http://www.mozilla.org/mailnews/osxinfo.html for information on how to enable Crash Reporter.

=== Sending savegames, screenshots, coredumps, etc ===
* Please compress the files (bzip2, gzip, zip).
* You can attach files if you submit your bug through Gna!, else
* Put them on some web or ftp server where we can download them.
* You can attach files to forum posts.
* As a last resort you can send them via email to: [mailto:davidnwhite_AT_verizon.net]

== Bug protocol ==

* When adding a new bug, please choose either "Bug" or "Feature Request" as its Category; it may not be noticed if you leave the Category as "None".
* We use the Status values "None" (awaiting action), "Fixed", "Won't Fix", "Invalid" (not a bug), "Works For Me" (unreproducible), or "Need Info".
* A bug which is fixed is marked "Fixed" by a developer, probably the one committing the fix or reviewing it.
* A bug present in a release is marked "Closed" only upon a new release containing the fix.
* Any bug present only in [[WesnothSVN]] is marked "Closed" when it is fixed.

== Who To Bug ==

This list is intended to give guidance on who developers doing bug triage should assign bugs to. Wesnoth developers who have agreed to take responsibility for particular subsystems, campaigns, or topic areas are listed here.

; alink: Maintainer of the mouse interface, also like to fix inconsistencies in the UI or add small usability feature.

; allefant: Maintainer of campaigns-client.py. Python expert.

; baufo: Maintainer of Descent Into Darkness campaign.

; boucman: Animation engine guru, can also help with low-level networking and generic map drawing issues. You can also bug him for unassigned patches.

; esr: Maintainer of wmllint, wmlscope. Backup autotools expert, after isaac. Python expert. General toolsmith; if you need a development or auditing tool for WML, talk to him. Co-maintainer of the Northern Rebirth campaign. Resident prose fixer and English-usage pedant, refer spelling errors and storyline copy-edit problems to him.

; ivanovic: The master of releases. Also the master of translations and gettext-related infrastructure.

; mythological: Maintainer of the Eastern Invasion and The Rise of Wesnoth campaigns.

; sapient: Maintainer of the WML interpreter engine and the UI widget set.

; taurus: Maintainer of Northern Rebirth campaign.

; zookeeper: Mainline campaigns maintainer. Our resident WML quality fanatic.

GameConfigWML

2007-05-30T18:35:47Z

Alink: fix a missing " ' "

This page has several unknown informations; they are represented by '???'.
Feel free to replace them with actual data.

{{WML Tags}}
== The [game_config] tag ==

This tag is a top level WML tag which can only be used once because
it defines basic settings that are used everywhere in the game.
In official versions of Wesnoth it is in ''game.cfg''; values used there are labeled 'standard'.

The following keys are recognised
* ''base_income'' (standard 2) how much your leader earns without any villages
* ''heal_amount'' (standard 4) how much the 'heal' ability (see [[AbilitiesWML]]) heals per unit
* ''healer_heals_per_turn'' (standard 8) how much a healer can heal per turn (total).
Healing is distributed clockwise, starting north of the healer,
until ''healer_heals_per_turn'' hitpoints have been regenerated.
* ''cure_amount'' (standard 8) how much the 'cure' ability heals per unit
* ''curer_heals_per_turn'' (standard 18) how much a curer can heal per turn (total)
* ''rest_heal_amount'' (standard 2) how much HP a unit gains each turn it rests
* ''recall_cost'' (standard 20) how much it costs to recall a unit; this cost is independent of level.
* ''kill_experience'' (standard 8)
killing a unit with ''level=X'' will give ''X''*''kill_experience'' experience to the killing unit.
However, if a unit has ''level=0'', it will still give half of ''X'' experience.

* ''icon'' (standard 'wesnoth-icon.png') the game icon file
* ''title'' (standard 'misc/title.png') the title screen image
* ''logo'' (standard 'misc/logo.png') the wesnoth logo which will be put over the title image
* ''title_music'' (standard 'main_menu.ogg') the music to play at the title screen
* ''anonymous_music'' (standard 'main_menu.ogg') the music to play during an unknown faction turn (1.1.x only)

* ''logo_x'' (standard 292) the x position of the logo on the title screen
* ''logo_y'' (standard 120) the y position of the logo on the title screen
* ''buttons_x'' (standard 760) the x position of the buttons on the title screen
* ''buttons_y'' (standard 330) the y position of the buttons on the title screen
* ''buttons_padding'' (standard 20) space between buttons, and border in main menu
* ''tip_x'' (standard 100) space between the button panel left edge and the tip-of-the-day panel right edge
* ''tip_y'' (standard 500) not used (the bottom right corner of the tip-of-the-day panel is pegged to align with the bottom of the button panel)
* ''tip_width'' (standard 495) max width in pixels of the tip-of-the-day panel. The width will actually adjust to be the smallest size necessary to fit the text. Once the max width is reached, if text must flow onto multiple lines, then the height will also automatically adjust.
* ''tip_padding'' (standard 20) space between the edge of the tip-of-the-day panel and an imaginary bounding box containing the text inside the panel

* ''map_image'' (standard 'maps/wesnoth.png') the background image for the "About" screen
* ''sidebar_image'' (standard 'misc/rightside.png') border of window when displaying unit statistics
* ''sidebar_image_bottom'' (standard 'misc/rightside-bottom.png') border of image when displaying unit statistics
* ''energy_image'' (standard 'misc/bar-energy.png') the images used to display hp/xp bars.
* ''moved_ball_image'' (standard 'misc/ball-moved.png') the orb image to add on top of the hp bar for player's moved units; see 'Orbs', [[WesnothManual]]
* ''unmoved_ball_image'' (standard 'misc/ball-unmoved.png') like ''moved_ball_image'', but for player's unmoved units
* ''partmoved_ball_image'' (standard 'misc/ball-partmoved.png') like ''moved_energy_image'', but for player's partially moved units
* ''flag_image'' (standard 'image/flag'terrain/flag-1.png:150,terrain/flag-2.png:150,terrain/flag-3.png:150,terrain/flag-4.png:150') the default flag animation to mark captured villages (if no custom flag is defined in the [side] tag). By example, this animation has 4 frames of 150ms each. An automatic side-coloring is applied.
* ''flag_icon_image'' {{DevFeature}} (standard 'flags/flag-icon.png') the default flag icon to indicate the side playing in the statusbar (if no custom flag_icon is defined in the [side] tag). An automatic side-coloring is applied.

* ''cross_image'' (standard 'misc/cross.png') the cross image displayed on the map at start of scenarios; see [[IntroWML]]
* ''dot_image'' (standard 'misc/dot.png') the dot image used to draw a path on the map before scenarios

* ''footprint_left_nw'', ''footprint_left_n'', ''footprint_right_nw'', ''footprint_right_n''
images used to display the path that a unit would take to the tile the cursor is on.
The first image of each key is used for tiles which would take only 1 movement point for the selected unit to move onto;
the second for ones which would take more.
The 'n' and 'nw' designations distinguish between tiles which are moved from orthogonally and diagonally in the same way as described in '''[missile_frame]''', [[AttackWML]].
The 'left' and 'right' designations are used alternately throughout the path;
however, the standard values are the same for 'left' and 'right'.

* ''missile_n_image'' (standard 'projectiles/missile-n.png') orthogonal missile image to use if none is specified;
see ''image'', '''[missile_frame]''', [[AttackWML]]
* ''missile_ne_image'' (standard 'projectiles/missile-ne.png') diagonal missile image to use if none is specified;
see ''image_diagonal'', '''[missile_frame]''', [[AttackWML]]
* ''terrain_mask_image'' (standard 'terrain/alphamask.png') ???
* ''observer_image'' (standard 'misc/eye.png') the image to use for observer ???
* ''download_campaign_image'' (standard no image) the icon for the "Download more Campaigns" campaign menu option.

== See Also ==

* [[ReferenceWML]]

[[Category: WML Reference]]

GameConfigWML

2007-05-30T18:33:55Z

Alink: Fix incorrect info about flag animation and add the new flag_icon_image

This page has several unknown informations; they are represented by '???'.
Feel free to replace them with actual data.

{{WML Tags}}
== The [game_config] tag ==

This tag is a top level WML tag which can only be used once because
it defines basic settings that are used everywhere in the game.
In official versions of Wesnoth it is in ''game.cfg''; values used there are labeled 'standard'.

The following keys are recognised
* ''base_income'' (standard 2) how much your leader earns without any villages
* ''heal_amount'' (standard 4) how much the 'heal' ability (see [[AbilitiesWML]]) heals per unit
* ''healer_heals_per_turn'' (standard 8) how much a healer can heal per turn (total).
Healing is distributed clockwise, starting north of the healer,
until ''healer_heals_per_turn'' hitpoints have been regenerated.
* ''cure_amount'' (standard 8) how much the 'cure' ability heals per unit
* ''curer_heals_per_turn'' (standard 18) how much a curer can heal per turn (total)
* ''rest_heal_amount'' (standard 2) how much HP a unit gains each turn it rests
* ''recall_cost'' (standard 20) how much it costs to recall a unit; this cost is independent of level.
* ''kill_experience'' (standard 8)
killing a unit with ''level=X'' will give ''X''*''kill_experience'' experience to the killing unit.
However, if a unit has ''level=0'', it will still give half of ''X'' experience.

* ''icon'' (standard 'wesnoth-icon.png') the game icon file
* ''title'' (standard 'misc/title.png') the title screen image
* ''logo'' (standard 'misc/logo.png') the wesnoth logo which will be put over the title image
* ''title_music'' (standard 'main_menu.ogg') the music to play at the title screen
* ''anonymous_music'' (standard 'main_menu.ogg') the music to play during an unknown faction turn (1.1.x only)

* ''logo_x'' (standard 292) the x position of the logo on the title screen
* ''logo_y'' (standard 120) the y position of the logo on the title screen
* ''buttons_x'' (standard 760) the x position of the buttons on the title screen
* ''buttons_y'' (standard 330) the y position of the buttons on the title screen
* ''buttons_padding'' (standard 20) space between buttons, and border in main menu
* ''tip_x'' (standard 100) space between the button panel left edge and the tip-of-the-day panel right edge
* ''tip_y'' (standard 500) not used (the bottom right corner of the tip-of-the-day panel is pegged to align with the bottom of the button panel)
* ''tip_width'' (standard 495) max width in pixels of the tip-of-the-day panel. The width will actually adjust to be the smallest size necessary to fit the text. Once the max width is reached, if text must flow onto multiple lines, then the height will also automatically adjust.
* ''tip_padding'' (standard 20) space between the edge of the tip-of-the-day panel and an imaginary bounding box containing the text inside the panel

* ''map_image'' (standard 'maps/wesnoth.png') the background image for the "About" screen
* ''sidebar_image'' (standard 'misc/rightside.png') border of window when displaying unit statistics
* ''sidebar_image_bottom'' (standard 'misc/rightside-bottom.png') border of image when displaying unit statistics
* ''energy_image'' (standard 'misc/bar-energy.png') the images used to display hp/xp bars.
* ''moved_ball_image'' (standard 'misc/ball-moved.png') the orb image to add on top of the hp bar for player's moved units; see 'Orbs', [[WesnothManual]]
* ''unmoved_ball_image'' (standard 'misc/ball-unmoved.png') like ''moved_ball_image'', but for player's unmoved units
* ''partmoved_ball_image'' (standard 'misc/ball-partmoved.png') like ''moved_energy_image'', but for player's partially moved units
* ''flag_image'' (standard image/flag'terrain/flag-1.png:150,terrain/flag-2.png:150,terrain/flag-3.png:150,terrain/flag-4.png:150') the default flag animation to mark captured villages (if no custom flag is defined in the [side] tag). By example, this animation has 4 frames of 150ms each. An automatic side-coloring is applied.
* ''flag_icon_image'' {{DevFeature}} (standard 'flags/flag-icon.png') the default flag icon to indicate the side playing in the statusbar (if no custom flag_icon is defined in the [side] tag). An automatic side-coloring is applied.

* ''cross_image'' (standard 'misc/cross.png') the cross image displayed on the map at start of scenarios; see [[IntroWML]]
* ''dot_image'' (standard 'misc/dot.png') the dot image used to draw a path on the map before scenarios

* ''footprint_left_nw'', ''footprint_left_n'', ''footprint_right_nw'', ''footprint_right_n''
images used to display the path that a unit would take to the tile the cursor is on.
The first image of each key is used for tiles which would take only 1 movement point for the selected unit to move onto;
the second for ones which would take more.
The 'n' and 'nw' designations distinguish between tiles which are moved from orthogonally and diagonally in the same way as described in '''[missile_frame]''', [[AttackWML]].
The 'left' and 'right' designations are used alternately throughout the path;
however, the standard values are the same for 'left' and 'right'.

* ''missile_n_image'' (standard 'projectiles/missile-n.png') orthogonal missile image to use if none is specified;
see ''image'', '''[missile_frame]''', [[AttackWML]]
* ''missile_ne_image'' (standard 'projectiles/missile-ne.png') diagonal missile image to use if none is specified;
see ''image_diagonal'', '''[missile_frame]''', [[AttackWML]]
* ''terrain_mask_image'' (standard 'terrain/alphamask.png') ???
* ''observer_image'' (standard 'misc/eye.png') the image to use for observer ???
* ''download_campaign_image'' (standard no image) the icon for the "Download more Campaigns" campaign menu option.

== See Also ==

* [[ReferenceWML]]

[[Category: WML Reference]]

GameConfigWML

2007-05-28T19:25:42Z

Alink: /* The [game_config] tag */

This page has several unknown informations; they are represented by '???'.
Feel free to replace them with actual data.

{{WML Tags}}
== The [game_config] tag ==

This tag is a top level WML tag which can only be used once because
it defines basic settings that are used everywhere in the game.
In official versions of Wesnoth it is in ''game.cfg''; values used there are labeled 'standard'.

The following keys are recognised
* ''base_income'' (standard 2) how much your leader earns without any villages
* ''heal_amount'' (standard 4) how much the 'heal' ability (see [[AbilitiesWML]]) heals per unit
* ''healer_heals_per_turn'' (standard 8) how much a healer can heal per turn (total).
Healing is distributed clockwise, starting north of the healer,
until ''healer_heals_per_turn'' hitpoints have been regenerated.
* ''cure_amount'' (standard 8) how much the 'cure' ability heals per unit
* ''curer_heals_per_turn'' (standard 18) how much a curer can heal per turn (total)
* ''rest_heal_amount'' (standard 2) how much HP a unit gains each turn it rests
* ''recall_cost'' (standard 20) how much it costs to recall a unit; this cost is independent of level.
* ''kill_experience'' (standard 8)
killing a unit with ''level=X'' will give ''X''*''kill_experience'' experience to the killing unit.
However, if a unit has ''level=0'', it will still give half of ''X'' experience.

* ''icon'' (standard 'wesnoth-icon.png') the game icon file
* ''title'' (standard 'misc/title.png') the title screen image
* ''logo'' (standard 'misc/logo.png') the wesnoth logo which will be put over the title image
* ''title_music'' (standard 'main_menu.ogg') the music to play at the title screen
* ''anonymous_music'' (standard 'main_menu.ogg') the music to play during an unknown faction turn (1.1.x only)

* ''logo_x'' (standard 292) the x position of the logo on the title screen
* ''logo_y'' (standard 120) the y position of the logo on the title screen
* ''buttons_x'' (standard 760) the x position of the buttons on the title screen
* ''buttons_y'' (standard 330) the y position of the buttons on the title screen
* ''buttons_padding'' (standard 20) space between buttons, and border in main menu
* ''tip_x'' (standard 100) space between the button panel left edge and the tip-of-the-day panel right edge
* ''tip_y'' (standard 500) not used (the bottom right corner of the tip-of-the-day panel is pegged to align with the bottom of the button panel)
* ''tip_width'' (standard 495) max width in pixels of the tip-of-the-day panel. The width will actually adjust to be the smallest size necessary to fit the text. Once the max width is reached, if text must flow onto multiple lines, then the height will also automatically adjust.
* ''tip_padding'' (standard 20) space between the edge of the tip-of-the-day panel and an imaginary bounding box containing the text inside the panel

* ''map_image'' (standard 'maps/wesnoth.png') the background image for the "About" screen
* ''sidebar_image'' (standard 'misc/rightside.png') border of window when displaying unit statistics
* ''sidebar_image_bottom'' (standard 'misc/rightside-bottom.png') border of image when displaying unit statistics
* ''energy_image'' (standard 'misc/bar-energy.png') the images used to display hp/xp bars.
* ''moved_ball_image'' (standard 'misc/ball-moved.png') the orb image to add on top of the hp bar for player's moved units; see 'Orbs', [[WesnothManual]]
* ''unmoved_ball_image'' (standard 'misc/ball-unmoved.png') like ''moved_ball_image'', but for player's unmoved units
* ''partmoved_ball_image'' (standard 'misc/ball-partmoved.png') like ''moved_energy_image'', but for player's partially moved units
* ''flag_image'' (standard 'terrain/flag-team%d-1.png:150,terrain/flag-team%d-2.png:150')
the image for a flag.
The symbol '%d' is used as a shortcut for an integer which depends on the color of the flag;
for example, a red flag is shown by the alternating images 'terrain/flag-team1-1.png' and 'terrain/flag-team1-2.png'.
(What does ':150' do???)

* ''cross_image'' (standard 'misc/cross.png') the cross image displayed on the map at start of scenarios; see [[IntroWML]]
* ''dot_image'' (standard 'misc/dot.png') the dot image used to draw a path on the map before scenarios

* ''footprint_left_nw'', ''footprint_left_n'', ''footprint_right_nw'', ''footprint_right_n''
images used to display the path that a unit would take to the tile the cursor is on.
The first image of each key is used for tiles which would take only 1 movement point for the selected unit to move onto;
the second for ones which would take more.
The 'n' and 'nw' designations distinguish between tiles which are moved from orthogonally and diagonally in the same way as described in '''[missile_frame]''', [[AttackWML]].
The 'left' and 'right' designations are used alternately throughout the path;
however, the standard values are the same for 'left' and 'right'.

* ''missile_n_image'' (standard 'projectiles/missile-n.png') orthogonal missile image to use if none is specified;
see ''image'', '''[missile_frame]''', [[AttackWML]]
* ''missile_ne_image'' (standard 'projectiles/missile-ne.png') diagonal missile image to use if none is specified;
see ''image_diagonal'', '''[missile_frame]''', [[AttackWML]]
* ''terrain_mask_image'' (standard 'terrain/alphamask.png') ???
* ''observer_image'' (standard 'misc/eye.png') the image to use for observer ???
* ''download_campaign_image'' (standard no image) the icon for the "Download more Campaigns" campaign menu option.

== See Also ==

* [[ReferenceWML]]

[[Category: WML Reference]]

SideWML

2007-05-28T18:40:16Z

Alink: /* the [side] tag */

{{WML Tags}}
== the [side] tag ==

The [side] tag is used to describe a side in a particular scenario.

The following keys are recognized:

* ''side'' a digit. The leader of this side is placed on the tile represented by this digit (see [[BuildingMaps]]). When defining sides, they must be defined in order since the side number is checked against the number of sides seen so far.

* ''controller'' how moves for this side should be inputted.
** 'ai' the Wesnoth AI makes this side's moves. This is the default setting.
** 'human' a player controls this side's moves.
** 'null' the side doesn't get a turn to move and doesn't have a leader generated from the contents of the [side] tag. (It still can get units from [unit] tags in the [side] tag.)

* ''no_leader'' if "no" (default), then keys describing a unit which will begin on the side's keep will be described in the remainder of the '''[side]''' tag, See [[SingleUnitWML]]. Note that if the keys ''x'', ''y'' are included, the leader will begin there regardless of keep location. If this side has a recall list from a previous level, then the recall list will be searched for a leader (using canrecruit) and if one is found it will be used instead of the one described in the '''[side]''' tag.

* ''type'' the unit type of the side's leader. This must be present if ''no_leader'' is not set to "yes." ''Description'', ''type'', ''x'', ''y'', ''profile'', and ''hitpoints'' are examples of keys from [[SingleUnitWML]] that will describe the leader if placed within the [side] tag.

* ''description'' (translatable) the name of the side's leader. It is used in standard unit filter ([[FilterWML]]) and it is not affected by a player renaming a unit.

* ''unrenamable'' if "no" (default), the player can rename the unit. Renaming the unit alters the ''user_description'' key, so the ''description'' key can still be used for filtering. It is generally a good idea to set this to yes in campaigns since dialog will usually refer to the leader by name. It is technically possible to read ''user_description'' into a variable every time you want to call the leader by name, but this is a hassle.

* ''recruit'' a list of unit types. At the beginning of the scenario, the side gains recruitment of these units.

* ''gold'' the starting gold for this side. Default 100. (If gold is carried over from a previous scenario, this value is the minimum starting gold.)

* ''income'' the base income for this side, default 0. This is added to ''base_income'', '''[game_config]''' to determine the side's base income. (see [[GameConfigWML]]).

* ''fog'' if 'yes', this side cannot see any tiles it is not within vision of, except at the start.

* ''shroud'' if 'yes', this side cannot see any tiles it has not moved within sight of.

* ''shroud_data'' describes the area which this team has de-shrouded.

* ''persistent'' whether the side exists in any other scenarios. If '1'(yes), then ''save_id''(see below) becomes active for this side. Default '0'(no); when '''controller=human''', this is always '1'.

* ''save_id'' default ''description'' if available, 'Unknown' otherwise. The ID of the side with respect to the previous and next scenarios. Used to carry over the side's recall list (including the side's leader), recruitment list, and starting gold from scenario to scenario. Also used for the side's displayed name in the victory gold-calculation dialog.

* ''team_name'' a non translatable string representing the team's description. Sides with the same team_name are allied. Default ''side''.

* ''user_team_name'' a translatable string representing the team's description. This has no effect on alliances. Default ''team_name''.

* ''colour'' if you want side 4 to be the same colour as side 2 normally is, put colour=2.
** The default list of numbers and corresponding colours can be found in data/team_colors.cfg.

* ''flag'' a custom flag animation to use instead of the default one to mark captured villages. {{DevFeature}} an automatic side-coloring is applied.
** Example animation that has three frames and loops every 750ms: ''flag=misc/myflag-1.png:250,misc/myflag-2.png:250,misc/myflag-3.png:250''

* ''flag_icon'' {{DevFeature}} a custom flag icon to indicate the side playing in the statusbar (a size of 24x16 is recommended). An automatic side-coloring is applied.

* ''village_gold'' the amount of gold given to this side per village it controls per turn. Default specified in ''village_gold'', '''[game_config]''' ([[GameConfigWML]]).

* ''share_maps'' whether sides allied with this side see all terrains that this side sees, if they are on shroud.

* ''share_view'' whether sides allied with this side see the units that this side sees, if they are on FoW (fog).

* ''name'', ''id'', ''leader'' not used; see [[EraWML]].

* ''music'' music to play for this player. Default specified in [scenario] (see [[ScenarioWML]]).

* '''[ai]''' if '''controller=ai''', gives parameters to the AI. See [[AiWML]].

* '''[village]''' describes a village the side begins in control of.
** ''x'', ''y'' the location of the village.

* '''[unit]''' describes a unit which begins on the side. See [[SingleUnitWML]]. If the side has a recall list and the unit is not given a location, it will start on the recall list. Note that the ''side'' attribute under '''[unit]''' will be ignored, as the side will come from the ''side'' attribute of '''[side]'''.

The following keys are multiplayer only:

* ''allow_player'' if false then this side will not be allowed to be modified and will be hidden during game creation.

* ''team_lock'' if true then this side's team is not allowed to be modified.

* ''colour_lock'' if true then this side's color is not allowed to be modified.

* ''gold_lock'' if true then this side's gold is not allowed to be modified.

* ''income_lock'' if true then this side's income is not allowed to be modified.

== See Also ==
* [[EraWML]]
* [[ScenarioWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

User:Alink

2007-05-25T18:45:48Z

Alink: /* Icons in the status bar */

I'm just starting this page, so for the moment, there is only the essential current things

= Current projects =

== Icons in the status bar ==
* Remove a "feature" of the theme engine which delete transparent part of icons and strech them regardless of their proportions.
* Add support and nice icons for other resolutions (tiny-gui). Need to do previous point before and take care of the automatic resizing during the tiny-gui install
* Try to graying icons during opponent's turn. https://gna.org/bugs/?9058

== Dialog engine ==
I recently discover some flaws with dialogs using long texts in cells or buttons ( https://gna.org/bugs/?4299 ). A first easy step will be to add some maximum width for dialog and after that, do the same for each cells (not sure how). Probably will use ellipsis ("long text...") because for the moment each row have the same height, so using linebreak for a big text will cause a general growing of all the rows.

== Text rendering ==
* Fix the imprecise wrapping when using special format characters and don't even watch size variation.
* Do something about wrapping of language not using spaces (add a new wrap parameter for language: CJK or wrap-letter): http://www.wesnoth.org/forum/viewtopic.php?p=228337#228337

== hp/xp bars ==
Replace this old, complex, buggy(zoom), hard-coded code of bars ( https://gna.org/bugs/?4931 ). I plan to use an all images-based system for easy configuration and customization. Current prototype works fine and seems powerful. Except this stupid alpha variation of the filled part of the bar. So on standby, 3 currents options:
* Drop the alpha variation.
* Use a little expensive adjust_alpha for the special cases, and maybe just use 2 states : normal / highlighted.
* Use new bars (and so a different set of images) when highlighting an unit. This will also allow some fancy things like bigger bars etc... but need more memory (a dozen of images)

= Future projects =
* Do some tweaking about the mousewheel scrolling
* Polish the drag&drop
* Try again the grab-map feature for scrolling
* Starting to replace coloUr by color in the code
* Continue to improve zoom
* Optimize the image cache system
* Optimize some sdl_utils functions
* Desynchronize flags of villages
* Change this bad system of special characters to a tag system. Or at least, use a better characters choice (using "{" for normal text is really a bad idea for macros)

User:Alink

2007-05-14T16:44:33Z

Alink: /* Current projects */

I'm just starting this page, so for the moment, there is only the essential current things

= Current projects =

== Icons in the status bar ==
* Modify themes to add space for the new flag icon (from 16 pixels to 24). For better visibility of the playing side, because a rectangle is better for a flag and the images ave already this size (so they are shrinked). ''Done for the default theme.''
* Use standard size (16x16, 24x16) for the icons instead of 15x15. ''Done, except for the flag-icons.''
* Remove a "feature" of the theme engine which delete transparent part of icons and strech them regardless of their proportions.
* Add support and nice icons for other resolutions (tiny-gui). Need to do previous point before and take care of the automatic resizing during the tiny-gui install
* Try to graying icons during opponent's turn. https://gna.org/bugs/?9058

== Dialog engine ==
I recently discover some flaws with dialogs using long texts in cells or buttons ( https://gna.org/bugs/?4299 ). A first easy step will be to add some maximum width for dialog and after that, do the same for each cells (not sure how). Probably will use ellipsis ("long text...") because for the moment each row have the same height, so using linebreak for a big text will cause a general growing of all the rows.

== Text rendering ==
* Fix the imprecise wrapping when using special format characters and don't even watch size variation.
* Do something about wrapping of language not using spaces (add a new wrap parameter for language: CJK or wrap-letter): http://www.wesnoth.org/forum/viewtopic.php?p=228337#228337

== hp/xp bars ==
Replace this old, complex, buggy(zoom), hard-coded code of bars ( https://gna.org/bugs/?4931 ). I plan to use an all images-based system for easy configuration and customization. Current prototype works fine and seems powerful. Except this stupid alpha variation of the filled part of the bar. So on standby, 3 currents options:
* Drop the alpha variation.
* Use a little expensive adjust_alpha for the special cases, and maybe just use 2 states : normal / highlighted.
* Use new bars (and so a different set of images) when highlighting an unit. This will also allow some fancy things like bigger bars etc... but need more memory (a dozen of images)

= Future projects =
* Do some tweaking about the mousewheel scrolling
* Polish the drag&drop
* Try again the grab-map feature for scrolling
* Starting to replace coloUr by color in the code
* Continue to improve zoom
* Optimize the image cache system
* Optimize some sdl_utils functions
* Desynchronize flags of villages
* Change this bad system of special characters to a tag system. Or at least, use a better characters choice (using "{" for normal text is really a bad idea for macros)

User:Alink

2007-05-14T16:37:37Z

Alink: /* hp/xp bars */

I'm just starting this page, so for the moment, there is only the essential current things

= Current projects =

== Icons in the status bar ==
* Modify themes to add space for the new flag icon (from 16 pixels to 24). For better visibility of the playing side, because a rectangle is better for a flag and the images ave already this size (so they are shrinked). ''Done for the default theme.''
* Use standard size (16x16, 24x16) for the icons instead of 15x15. ''Done, except for the flag-icons.''
* Remove a "feature" of the theme engine which delete transparent part of icons and strech them regardless of their proportions.
* Add support and nice icons for other resolutions (tiny-gui). Need to do previous point before and take care of the automatic resizing during the tiny-gui install
* Try to graying icons during opponent's turn. https://gna.org/bugs/?9058

== Text rendering ==
* Fix the imprecise wrapping when using special format characters and don't even watch size variation.
* Do something about wrapping of language not using spaces (add a new wrap parameter for language: CJK or wrap-letter): http://www.wesnoth.org/forum/viewtopic.php?p=228337#228337

== hp/xp bars ==
Replace this old, complex, buggy(zoom), hard-coded code of bars ( https://gna.org/bugs/?4931 ). I plan to use an all images-based system for easy configuration and customization. Current prototype works fine and seems powerful. Except this stupid alpha variation of the filled part of the bar. So on standby, 3 currents options:
* Drop the alpha variation.
* Use a little expensive adjust_alpha for the special cases, and maybe just use 2 states : normal / highlighted.
* Use new bars (and so a different set of images) when highlighting an unit. This will also allow some fancy things like bigger bars etc... but need more memory (a dozen of images)

= Future projects =
* Do some tweaking about the mousewheel scrolling
* Polish the drag&drop
* Try again the grab-map feature for scrolling
* Starting to replace coloUr by color in the code
* Continue to improve zoom
* Optimize the image cache system
* Optimize some sdl_utils functions
* Desynchronize flags of villages
* Change this bad system of special characters to a tag system. Or at least, use a better characters choice (using "{" for normal text is really a bad idea for macros)

User:Alink

2007-05-14T16:36:02Z

Alink: /* Text rendering */

I'm just starting this page, so for the moment, there is only the essential current things

= Current projects =

== Icons in the status bar ==
* Modify themes to add space for the new flag icon (from 16 pixels to 24). For better visibility of the playing side, because a rectangle is better for a flag and the images ave already this size (so they are shrinked). ''Done for the default theme.''
* Use standard size (16x16, 24x16) for the icons instead of 15x15. ''Done, except for the flag-icons.''
* Remove a "feature" of the theme engine which delete transparent part of icons and strech them regardless of their proportions.
* Add support and nice icons for other resolutions (tiny-gui). Need to do previous point before and take care of the automatic resizing during the tiny-gui install
* Try to graying icons during opponent's turn. https://gna.org/bugs/?9058

== Text rendering ==
* Fix the imprecise wrapping when using special format characters and don't even watch size variation.
* Do something about wrapping of language not using spaces (add a new wrap parameter for language: CJK or wrap-letter): http://www.wesnoth.org/forum/viewtopic.php?p=228337#228337

== hp/xp bars ==
Replace this old, complex, buggy(zoom), hard-coded code of bars ( https://gna.org/bugs/?4931 ). I plan to use an all images-based system for easy configuration and customization. Current prototype works fine except and seems powerfull. Except this stupid alpha variation of the filled part of the bar. So on standby, 3 currents options:
* Drop the alpha variation.
* Use a little expensive adjust_alpha for the special cases.
* Use new bars (and so a different set of images) when highlighting an unit. This will also allow some fancy things like bigger bars etc... but need more memory (a dozen of images)

= Future projects =
* Do some tweaking about the mousewheel scrolling
* Polish the drag&drop
* Try again the grab-map feature for scrolling
* Starting to replace coloUr by color in the code
* Continue to improve zoom
* Optimize the image cache system
* Optimize some sdl_utils functions
* Desynchronize flags of villages
* Change this bad system of special characters to a tag system. Or at least, use a better characters choice (using "{" for normal text is really a bad idea for macros)

User:Alink

2007-05-14T16:34:01Z

Alink: /* Icons in the status bar */

I'm just starting this page, so for the moment, there is only the essential current things

= Current projects =

== Icons in the status bar ==
* Modify themes to add space for the new flag icon (from 16 pixels to 24). For better visibility of the playing side, because a rectangle is better for a flag and the images ave already this size (so they are shrinked). ''Done for the default theme.''
* Use standard size (16x16, 24x16) for the icons instead of 15x15. ''Done, except for the flag-icons.''
* Remove a "feature" of the theme engine which delete transparent part of icons and strech them regardless of their proportions.
* Add support and nice icons for other resolutions (tiny-gui). Need to do previous point before and take care of the automatic resizing during the tiny-gui install
* Try to graying icons during opponent's turn. https://gna.org/bugs/?9058

== Text rendering ==
* Fix the imprecise wrapping when using special format characters and don't even watch size variation.
* Do something about wrapping of language not using spaces (fix tag use or add a new wrap parameter for language): http://www.wesnoth.org/forum/viewtopic.php?p=228337#228337

== hp/xp bars ==
Replace this old, complex, buggy(zoom), hard-coded code of bars ( https://gna.org/bugs/?4931 ). I plan to use an all images-based system for easy configuration and customization. Current prototype works fine except and seems powerfull. Except this stupid alpha variation of the filled part of the bar. So on standby, 3 currents options:
* Drop the alpha variation.
* Use a little expensive adjust_alpha for the special cases.
* Use new bars (and so a different set of images) when highlighting an unit. This will also allow some fancy things like bigger bars etc... but need more memory (a dozen of images)

= Future projects =
* Do some tweaking about the mousewheel scrolling
* Polish the drag&drop
* Try again the grab-map feature for scrolling
* Starting to replace coloUr by color in the code
* Continue to improve zoom
* Optimize the image cache system
* Optimize some sdl_utils functions
* Desynchronize flags of villages
* Change this bad system of special characters to a tag system. Or at least, use a better characters choice (using "{" for normal text is really a bad idea for macros)

User:Alink

2007-05-08T23:54:35Z

Alink:

I'm just starting this page, so for the moment, there is only the essential current things

= Current projects =

== Icons in the status bar ==
* Modify themes to add space for the new flag icon (from 16 pixels to 24). For better visibility of the playing side, because a rectangle is better for a flag and the images ave already this size (so they are shrinked).
* Use standard size (16x16, 24x16) for the icons instead of 15x15
* Remove a "feature" of the theme engine which delete transparent part of icons and strech them regardless of their proportions.
* Add support and nice icons for other resolutions (tiny-gui). Easy but need to do previous point before
* Try to graying icons during opponent's turn. https://gna.org/bugs/?9058

== Text rendering ==
* Fix the imprecise wrapping when using special format characters and don't even watch size variation.
* Do something about wrapping of language not using spaces (fix tag use or add a new wrap parameter for language): http://www.wesnoth.org/forum/viewtopic.php?p=228337#228337

== hp/xp bars ==
Replace this old, complex, buggy(zoom), hard-coded code of bars ( https://gna.org/bugs/?4931 ). I plan to use an all images-based system for easy configuration and customization. Current prototype works fine except and seems powerfull. Except this stupid alpha variation of the filled part of the bar. So on standby, 3 currents options:
* Drop the alpha variation.
* Use a little expensive adjust_alpha for the special cases.
* Use new bars (and so a different set of images) when highlighting an unit. This will also allow some fancy things like bigger bars etc... but need more memory (a dozen of images)

= Future projects =
* Do some tweaking about the mousewheel scrolling
* Polish the drag&drop
* Try again the grab-map feature for scrolling
* Starting to replace coloUr by color in the code
* Continue to improve zoom
* Optimize the image cache system
* Optimize some sdl_utils functions
* Desynchronize flags of villages
* Change this bad system of special characters to a tag system. Or at least, use a better characters choice (using "{" for normal text is really a bad idea for macros)

EasyCoding

2007-04-25T17:40:34Z

Alink: /* Theme Changes */

== Foreword ==
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to juge the difficulty of a given task.

If you are such a person, you should feel free to edit this page.

If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.

Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.

If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)

--[[User:Boucman|Boucman]] 20:48, 3 October 2006 (CEST)

== Animation related features ==
=== Victory animation ===
'''an animation to be played by the surviving unit during the death animation of the other unit'''

this should be fairly easy to do, just duplicate all death animation code, and modify the unit_die function to change the state of both units.

ask Boucman for extra help

* unit_display.cpp
* unit_type.cpp
* unit.cpp
* unit_animation.cpp;

Done! Submitting patch as soon as it can be tested. [[User:TheAT|TheAT]] 01:53, 17 October 2006 (CEST)

=== En Guard animation ===
'''An animation to replace the standing animation when the unit is next to an enemy'''

Slightly more tricky than the previous one, you should copy most of the standing code,
but beware that this should be invisible to external callers.
The call to get_stats should be looked at

Ask Boucman for extra help

* unit.cpp
* unit_type.cpp
* unit_animation.cpp

=== Special tags for Extra_anim ===
'''Special tags in the animate_unit event to call standard unit animations'''

One of the big limitation of the extra_animation tags is
that you need to modify the unit itself to have the extra anim.
Most anims can't be easily called that way.
It would be interesting to have special tags that would be recognised
to call the standard animations (attack, defense, etc...)

The tricky part is to handle correctly the "offset" parameter,
and add all the WML handling to "fill in" the information
we won't have available (non-existant filtering criterias)

This is more tricky than the two above,
and I would advise doing one of the other two first to understand how it works

Ask Boucman for extra help

* unit.cpp
* actions.cpp

=== Animate flags during a [delay] event ===
currently, the [event] tag calls SDL_delay() and blocks the game completely. It would be trivial to change it to a loop that would call event::pump() every 10ms to have all animations updated

the tricky part is to make sure the screen is somehow "locked" and that player can't play during that time (should be the case, simple checking is needed)

grep should give you the file to change

I am on this.Boucman please email me with more details when you have time [[User:Spx2|Spx2]] 12:31, 23 December 2006 (CEST)

Boucman please email me with an event that i can test this on

== WML related features ==
=== Side-specific messages ===
Side-specific [message]s ([http://gna.org/bugs/index.php?7427 FR #7427])
=== Side-specific results ===
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960])
=== Recall Event ===
WML event trigger for recalling (the current one triggers on both recalls and recruits) ([http://gna.org/bugs/index.php?3622 FR #3622]) (please read the comments of the report for a proper description of how this should work)
=== Enabling checking of damage dealt in WML ===
A WML variable should be set when triggering some combat-related events, allowing WML to know the amount of damage being dealt. ([http://gna.org/bugs/index.php?7673 FR #7673])
=== Support for leaderless multiplayergames ===
Add support for the WML tag victory_when_enemies_defeated in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])

== GUI related features ==
=== Theme Changes ===
* show number of owned villages/total villages (FR: #3135) (--[[User:Alink|alink]] done but must update help, doc, tooltip...)
* allow custom themes to display values of WML variables ([http://gna.org/bugs/index.php?6209 FR #6209])
* hide the hourglass item from the statusbar when there is no timer

=== Widget Changes ===
* show side number, name and team association information in the status table
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)
* input history (chat, commands, ..), seek Sapient for more info and tips

== Miscellaneous ==
=== More powerful village naming ===
'''Adding mountain names and other features to village names, having a second random name in village names'''

Currently the village naming engine has a very good structure that could allow
more powerfull names to be generated.
Understanding how it works should be quite easy, and a few usefull improvements could be added.

* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...
* It would be nice to have a separate list of "first sylabus" and "last sylabus" for naming. That's not really needed in english, but some translations could use it
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice

=== Debug Mode ===
* New debug command functionality (setting status.variables, possibly terrain, WML value display)
* Make it possible to toggle shroud and fog (but take care that this is only possible in campaigns)