The Battle for Wesnoth Wiki - User contributions [en]

TerrainMaskWML

2008-05-22T13:28:15Z

Mog: Add new layer features to [terrain_mask] tag

{{WML Tags}}

== The [terrain_mask] tag ==

The [terrain_mask] tag makes map manipulation from within WML much easier.
It uses a Wesnoth map as a "mask" over a given location,
placing it down on top of the scenario map.
Fog('~') and void(' ') are used like alpha in an image; i.e. they cause the previous terrain to be used.

* '''x,y''': the x,y location in the scenario map to place the top-left corner of the mask onto
* '''mask''': a Wesnoth map; see [[BuildingMaps]].
* '''[rule]''': specifies a rule for blending the mask with the scenario.
The terrain on each hex fitting the rule will be changed to the terrain specified in the rule.
** '''old''': a comma-separated list of terrain codes. The rule fits only those hexes that have one of these terrains in the scenario.
** '''new''': a list of terrain letters. The rule fits only those hexes with this terrain specified in the mask.
** '''terrain''': the letter of the terrain to change hexes which fit this rule (i.e. for which the '''new''' terrain code in the mask falls on top of the '''old''' terrain in the scenario) into.
** {{DevFeature}} '''layer''': (overlay|base|both, default=both) only change the specified layer.
** {{DevFeature}} '''replace_if_failed''': (default=no) When replacing just one layer failed, try to replace the whole terrain. If '''terrain''' is an overlay only terrain, use the default_base as base layer. If the terrain has no default base, do nothing.

As an example, suppose you want to lay down a road somewhere. You could specify by hand the path the road takes using
[terrain], or you could use
[terrain_mask]:

[terrain_mask]
x,y=12,10
mask="border_size=1
usage=map

Re, Re, _f, _f, _f, _f, _f, _f, _f, _f, _f, _f
Re, Re, _f, _f, _f, _f, _f, _f, _f, _f, _f, _f
Re, Re, _f, _f, _f, _f, _f, _f, _f, _f, _f, _f
_f, _f, Re, _f, _f, _f, _f, _f, _f, _f, _f, _f
_f, _f, Re, _f, _f, _f, _f, _f, _f, _f, _f, _f
Re, Re, _f, _f, _f, _f, _f, _f, _f, _f, _f, _f
_f, _f, Re, _f, _f, Re, Re, _f, _f, _f, _f, _f
_f, _f, _f, Re, Re, Re, _f, Re, Re, _f, _f, _f
_f, _f, _f, _f, _f, _f, _f, Re, _f, _f, _f, _f
_f, _f, _f, _f, _f, _f, _f, Re, Re, _f, _f, _f
_f, _f, _f, _f, _f, _f, _f, Re, Re, Re, Re, Re
_f, _f, _f, _f, _f, _f, _f, Re, Re, Re, Re, Re
"
[/terrain_mask]

For instance, suppose you want snow to fall in an area. You want villages (v) to turn into snowed-villages (V), forest
(f) to turn into snowed-forest (F), hills
(h) to turn into snowed-hills (H), and grassland (g) and roads (r) to turn into snow (S), while other terrain remains
untouched. You could look over your
destination map and work out which terrain type is which and draw your mask, but that's alot of effort, you want to just
draw a simple mask which has
areas of snow and areas of no snow, and make the game work out the rest.

You can do it like this:

[terrain_mask]
x,y=1,1
mask="border_size=1
usage=map

_f, _f, Aa, _f, _f, _f, Aa, _f, _f
_f, _f, Aa, _f, _f, _f, Aa, _f, _f
_f, _f, Aa, _f, Aa, _f, Aa, _f, _f
Aa, Aa, _f, _f, Aa, Aa, Aa, _f, _f
_f, _f, Aa, Aa, Aa, Aa, Aa, Aa, Aa
_f, _f, _f, Aa, Aa, Aa, Aa, Aa, Aa
_f, _f, _f, _f, Aa, Aa, _f, _f, _f
_f, _f, _f, _f, Aa, Aa, _f, _f, _f"
[rule]
old=Gg^Vh
new=Aa
terrain=Aa^Vha
[/rule]
[rule]
old=Gs^Fp
new=Aa
terrain=Aa^Fpa
[/rule]
[rule]
old=Hh
new=Aa
terrain=Ha
[/rule]

[rule]
old=Gg,Re
new=Aa
#don't specify terrain and it just uses the new terrain
[/rule]

#default: Will match everything, since 'old' and 'new' aren't
#specified. Set 'use_old=yes' to signal no change.
[rule]
use_old=yes
[/rule]
[/terrain_mask]

== See Also ==

* [[DirectActionsWML]]
* [[ReferenceWML]]

[[Category:WML Reference]]

DirectActionsWML

2008-05-22T13:27:58Z

Mog: Add new layer features for [terrain] action

{{WML Tags}}
== Direct actions ==

Direct actions are actions that have a direct effect on gameplay.

The following tags are actions:
* '''[endlevel]''': ends the scenario.
** '''result''': before the scenario is over, all events with ''name=result'' are triggered. The message ''result_message'' with the heading ''result_heading'' (see [[LanguageWML]]) are displayed. If ''result=victory'', the player progresses to the next level; if ''result=defeat'', the game returns to the main menu. These last two are rarely used: ''result=continue'' behaves identically to ''result=victory'' except the player's gold is not reduced to 80%, and it does not bring up a "Victory" message or the gold changing message (since it doesn't change); ''result=continue_no_save'' works similarly, except the player is not asked whether to save the game, and is taken directly to the next scenario without any messages. Unless ''result=defeat'', the following keys can also be used:
** '''bonus''': whether the player should get bonus gold (maximum possible gold that could have been earned by waiting the level out). The default is bonus=yes.
** '''next_scenario''': (default specified in '''[scenario]''' tag) the ID of the next scenario that should be played. All units that side 1 controls at this point become available for recall in ''next_scenario''.
** When the result is "victory" the following keys can be used:
*** '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
*** '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''[unit]''': places a unit on the map. For syntax see [[SingleUnitWML]].{{Short Note:Predefined Macro|GENERIC_UNIT}}
* '''[recall]''': recalls a unit. The unit is recalled free of charge, and is placed near the leader.
** [[StandardUnitFilter]]: the first matching unit will be recalled. If no units match this tag is ignored.
** '''x,y''': the unit is placed here instead of next to the leader.
** '''show''': if not "no", display the unit being recalled.
* '''[teleport]''': teleports a unit on map. {{Short Note:Predefined Macro|TELEPORT_UNIT}}
** '''[filter]''': [[StandardUnitFilter]] all units matching the filter will be teleported.
** '''x,y''': the position to teleport to.
* '''[terrain_mask]''': changes the terrain on the map. See [[TerrainMaskWML]].
* '''[terrain]''': changes the terrain on the map.
** '''terrain''': the character of the terrain to use. See [[TerrainCodesWML]] to see what letter a type of terrain uses.
** '''x,y''': the position (or range of positions) to change.
** {{DevFeature}} '''layer''': (overlay|base|both, default=both) only change the specified layer.
** {{DevFeature}} '''replace_if_failed''': (default=no) When replacing just one layer failed, try to replace the whole terrain. If '''terrain''' is an overlay only terrain, use the default_base as base layer. If the terrain has no default base, do nothing.
* '''[gold]''': give one side gold.
** '''amount''': the amount of gold to give.
** '''side''': (default=1) the number of the side to give the gold to.
* '''[unstore_unit]''': creates a unit from a game variable, and activates it on the playing field. This must be a specific variable describing a unit, and may not be an array -- to unstore an entire array, iterate over it. The variable is not cleared. See also '''[store_unit]''', '''[while]''' and [clear_variable] in [[InternalActionsWML]]. Note units with a negative amount of hitpoints will be unstored with 1 hitpoint.
** '''variable''': the name of the variable.
** '''find_vacant''': whether the unit should be placed on the nearest vacant tile to its specified location. If this is set to 'no'(default), then any unit on the same tile as the unit being unstored will be destroyed.
** '''text''': (translatable) floating text to display above the unit, such as a damage amount
** '''red''', '''green''', '''blue''': (default=0,0,0) the color to display the text in. Values vary from 0-255. You may find it convenient to use the {COLOR_HARM} or {COLOR_HEAL} macro instead. (Use {COLOR_HARM} or {COLOR_HEAL} instead of the whole red,green,blue= line.)
** '''advance''': if the XP has been modified then there will be tried to advance the unit, default true.
* '''[allow_recruit]''': allows a side to recruit units it couldn't previously recruit.
** '''type''': the types of units that the side can now recruit.
** '''side''': (default=1) the number of the side that is being allowed to recruit the units.
* '''[disallow_recruit]''': prevents a side from recruiting units it could previously recruit.
** '''type''': the types of units that the side can no longer recruit.
** '''side''': (default=1) the number of the side that may no longer recruit the units.
* '''[set_recruit]''': sets the units a side can recruit.
** '''recruit''': the types of units that the side can now recruit.
** '''side''': (default=1) the number of the side that is having its recruitment set.
* '''[modify_side]''': modifies some details of a given side in the middle of a scenario. '''The following listed properties are the only properties that [modify_side] can affect!'
** '''side''': (default=1) the number of the side that is to be changed.
** '''income''': the income given at the begining of each turn.
** '''team_name''': the team in which the side plays the scenario.
** '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Defaults to ''team_name''.
** '''gold''': the amount of gold the side owns.
** '''village_gold''': the income setting per village for the side.
** '''controller''': the identifier string of the side's controller. Uses the same syntax of the ''controller'' key in the [[SideWML|[side]]] tag.
** '''fog''': a boolean string (yes/no) describing the status of Fog for the side.
** '''shroud''': a boolean string describing the status of Shroud for the side.
** {{DevFeature}} '''[ai]''': replaces a side's AI parameters with the new specified ones. Uses the same syntax described in [[AiWML]].
* '''[modify_turns]''': modifies the turn limit in the middle of a scenario.
** '''value''': the new turn limit.
** '''add''': if used instead of ''value'', specifies the number of turns to add to the current limit (can be negative).
* '''[capture_village]''': changes the ownership of a village.
** '''side''': the side that takes control of the village. If not given, the village will become neutral.
** '''x, y''': the location of the village.
* '''[kill]''': Removes all units (including units in a recall list) that match the filter from the game.
** [[StandardUnitFilter]]: selection criterion
** '''animate''': if 'yes', displays the unit dying (fading away).
** '''fire_event''': if 'yes', triggers any appropriate 'die' events (See [[EventWML]]). Note that any 'die' events triggered by this are executed immediately, interrupting the current event and thus causing the x1, y1, x2, and y2 variables to be reset for that 'die' event, which in turn causes those variables to be invalid for the remainder of this event.
* '''[unstone]''': Unstones all units that match the filter.
** '''[filter]''': [[StandardUnitFilter]] all units matching the filter will be unstoned. If no unit matches the filter, then nothing happens (probably). If absent, all units on the map are unstoned.
* '''[object]''': gives some unit an object and removes all items on the tile the unit is on.
** '''id''': when the object is picked up, a flag is set for ''id''. The object cannot be picked up if a flag for ''id'' has been set. This means that any object with an id can only be used once, even if first_time_only=no is set for the event. This restriction is per level. In a campaign objects with the same id can be assigned once per level.
** '''[effect]''': one or more effect elements may be listed. See [[EffectWML]] for a description of [effect].
** '''duration''': if 'level', effects only last until the end of the level (note : 'level' is the scenario, so this doesn't mean it last until the unit levels-up).
** '''[filter]''': [[StandardUnitFilter]] the first unit found that matches the filter will be given the object. If no unit matches the filter, then a message is displayed and the object is not removed.
** '''[then]''': a subtag that lets you execute actions if the filter conditions are met. The most common action that should be inside here is a '''[removeitem]''' tag, but you could probably put any tags that otherwise work in a [then] tag.
** '''silent''': whether or not messages should be suppressed. Default is "no".
** '''image''': the displayed image of the object.
** '''name''': (translatable) displayed as a caption of the image.

** '''user_description''': {{DevFeature}} (translatable) displayed as a message of the image. In 1.4 and older versions this is just '''description'''; that will still be expected for compatibility.
** '''cannot_use_message''': (translatable) displayed instead of '''description''' if no unit passes the filter test.
** If you do not supply a filter, the object action will be applied to a unit at the location of the moveto event. Currently this isn't recommended as it is not clear that this will continue working this way. Instead it is better to explicitly include a location filter.
** The object action does not act on units in the recall list. There is a feature request in to allow this, but it is not clear whether or not it will be accepted.
* '''[remove_shroud]''': removes some shroud from the map for a certain side (only relevant for sides that have shroud=yes).
** '''side''': (default=1) the side for which to remove shroud.
** [[StandardLocationFilter]]: the range of tiles for which shroud should be removed.
* '''[place_shroud]''': places some shroud on the map for a certain side (only relevant for sides that have shroud=yes).
** '''side''': (default=1) the side for which to place shroud.
** [[StandardLocationFilter]]: the range of tiles on which shroud should be placed.
* '''[allow_undo]''': allows the player to undo the event that this tag is inside. Has an effect only inside moveto events. If the move is undone, only the position of the unit will be restored; any altered variables or changes to the game will remain changed after the move is undone. It is up to the scenario designer to avoid abusing this command.
** Technically, if '''[allow_undo]''' is inside an '''[event]''' with ''first_time_only=yes'' (the default setting), and the user undoes the event, then the state of the game has changed in this way: the event will not fire a second time, even though the user undid the move the first time.
* {{DevFeature}} '''[heal_unit]''': heal a unit. The variable '''$heal_amount''' will be set to the exact number of points healed (i.e can be lesser than the parameter '''amount''' if the unit is fully healed).
** '''[filter]''': [[StandardUnitFilter]] the first unit matching the filter will be healed.
** '''[secondary_unit_filter]''': [[StandardUnitFilter]] all the units matching the filter ''and'' having the ''heals'' ability will have their animation played (if ''animate'' is set to true).
** '''amount''': the maximum points the unit will be healed.
** '''animate''': a boolean which indicate if the healing animations must be played.

== Useful Macros ==
There are some predefined macros that you find useful for direct actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].
* '''{MOVE_UNIT}''': Moves a unit to another location in the map and the player sees the movement (unlike [teleport])
* '''{FULL_HEAL}''': Brings a unit to full HP
* '''{LOYAL_UNIT}''': Create a loyal unit
* '''{MODIFY_TERRAIN_MASK}''': Modify an area of terrain

== See Also ==

* [[InternalActionsWML]]
* [[InterfaceActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

TerrainMacros

2008-04-29T17:15:12Z

Mog: New page: !!!Work in progress!!! NOTE: This document describes the new terrain macros currently in 1.5 SVN (which will become 1.5.1). For a deeper understanding of the terrain engine, have a look a...

!!!Work in progress!!!

NOTE: This document describes the new terrain macros currently in 1.5 SVN (which will become 1.5.1). For a deeper understanding of the terrain engine, have a look at [TerrainGraphicsTutorial] and [TerrainGraphicsReference].

==General concepts==

===Optional parameters===

There are several parameters in most macros that are not required. If they are not specified, they are assigned a default value, that may depend on the macro. Those parameters are:

* PROB: The probability that this macro is executed. This is used to make random variations possible. The default value is 100 (i.e. the macro will apply always). See here on how to use it correctly: [TerrainGraphicsTutorial#Cumulative_Probabilities]
* LAYER: Specifies the ordering of images. Images with a higher layer are always above images with a lower layer. The default value for base terrains is -1000, the one for transitions between base terrains is -500 and the one for overlay terrain is 0.
* FLAG: Usually, each type of macro is only applied once, i.e. if there is already a base terrain/a base transition to the tile on the north/ overlay/ overlay transition on one tile, no rule after that will apply. Sometimes you might want to layer several graphics on top of each other, in which case you can specify another flag, as macros with different flags can apply to one tile.

For example:

MACRO_PLF TERRAIN1 ... TERRAIN{n} PROB LAYER FLAG IMAGE

The "PLF" suffix means that the macro takes the PROB, LAYER and FLAG parameters. A macro with a suffix like "PF" takes only the parameters PROB and FLAG, macros without suffix take none.

==Simple tiles==

These macros just draw an image onto a tile

TERRAIN_BASE TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as base terrain for a tile with TERRAIN. IMAGE should be a 72x72 image, parts that overlap the hex are cut off.

It's commonly used for "flat" terrains like grassland, water but also hills.

OVERLAY TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as an overlay for a tile with TERRAIN. The image is centeres on that tile and can overlap the hex.

It's used together with TERRAIN_BASE for terrains that have a height an can overlap each other depending on their position.

VILLAGE TERRAIN [PROB] IMAGE

This macro is just a shorthand to place a village on a tile with TERRAIN. Otherwise is works just like OVERLAY.

TERRAIN_BASE_RANDOM TERRAIN [LAYER] [FLAG] IMAGE

The TERRAIN_BASE_RANDOM macro is a easy way to have several variants of the same terrain. It uses the images IMAGE.png, IMAGE2.png ... IMAGE9.png and places them with equal probabiltiy. You don't need ten images for every terrain, the macro will also handle all smaller numbers as long as they exist in the correct order (if they are not in order, i.e. IMAGE.png, IMAGE2.png, IMAGE8.png, they will still display, but not with equal probability).
Each image is placed in the same way as in TERRAIN_BASE

OVERLAY_RANDOM TERRAIN [LAYER] [FLAG] IMAGE

Works like TERRAIN_BASE_RANDOM, but places images as the OVERLAY macro.

VILLAGE_RANDOM TERRAIN IMAGE

Works like OVERLAY_RANDOM, but with the same layer/flag as the VILLAGE macro.

==Transitions and more complex terrains==

TRANSITION_BASE TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Creates a "flat" transition between tiles with TERRAIN and ADJACENT. Depending on the number of ADJACENT tiles around the base tile, IMAGE is suffixed with -@R0-@R1-@R2-@R3, -@R0-@R1-@R2, -@R0-@R1 or -@R0. If images with more sides don't exist, the transition will be drawn using images with fewer sides (e.g. a 4-sided transition can also be drawn with one 3-sided and one 1-sided, two 2-sided or four 1-sided images).

Flags on the tiles will be set so that only one transition will be drawn per edge. So a X-Y transition on the south side of the X-tile will prevent a later Y-X transition on the north side of the Y-tile (unless you set a different flag on one of the transitions).

User:Mog/TerrainReorg

2008-04-20T13:37:01Z

Mog: /* Parameter ordering */

==Terrain macro overhaul==

The terrain macros are currently a mess. There are lots of inconsitencies and often several different ways to do the same thing.

I found the following issues. Feel free to add/comment to the list.

===Issues===
* Inconsistent ordering of parameters

* Inconsistent naming of macros

* Two ways of naming rotations. Most terrains have (n,ne,se,s,sw,nw), i.e. rotations are named according to the edges of the hex. Castles/chasm/etc. have the rotations (ne,e,se,sw,w,nw) i.e. named for the corners of the hex.

===Proposed changes===
* Have a consistent naming scheme. E.g. all macros that have a flag parameter end with _F, macros with a probability parameter with _P, layer with _L. Ideally, these suffixes are ordered the same way as the coresponding parameters.

* Most macros have a similar structure, so i suggest the following parameter ordering:
MACRO_NAME IDS1 [,IDS2, [IDS3, ...]] [LAYER] [PROB] [FLAG] IMAGE

There may be macros where this scheme will not work, but for the majority it should.

* I suggest renaming the castle tiles to use the more common naming method. This means renaming a corner direction to two edge directions (e.g. ne-> n-ne, e->ne-se, etc.). This also makes clear if the hexes around the corner are ordered clockwise or counterclockwise (another current inconsitency btw.)

==Macro-proposal==

===General===
====Parameter ordering====
The general parameter ordering is:
MACRO TERRAIN [ADJACENT1 [ADJACENT2 [...]]] [PROB] [LAYER] [BASE] [FLAG] IMAGE

Explanation:
* TERRAIN: The "center tile" on which the majority of the terrain is drawn, or -- in the case of some transitions -- the terrain which is the center of the rotation
* ADJACENT1 ... ADJACENTn: Adjacent tiles, depends on the exact macro. If more than one, ordered clockwise around the center tile.
* PROB: Probability
* LAYER: Layer on which the terrain is drawn (higher layers cover lower ones)
* BASE: For overlay terrains, defines the z-ordering among terrains on the same layer
* FLAG: Macros usually make sure that each type of transition occurs only once per tile. Default flags are "transition" for base terrains and "overlay" for overlays. Override the default flag if you need more than one transition stacked on the same tile.
* IMAGE: The basename of the image. Will be appended with a suffix depending on the macro

As the parameter number of each macro is fixed, variants of each macro exist for various combinations of optional parameters. The scheme is as follows:

MACRO_P for macros taking PROB as a parameter
MACRO_L for macros taking LAYER as a parameter
MACRO_B for macros taking BASE as a parameter
MACRO_F for macros taking FLAG as a parameter

and combinations thereof.

e.g.
MACRO_PF takes PROB and FLAG parameters

For parameters that don't occur, default values are used as follows:
* PROB: 100
* LAYER: Depends on macro, but generally -500 for transitions, 0 for overlays
* BASE: Depends on macro, but doesn't need to be overridden except in the most unusual circumstances. So I don't create macro-alternatives which take BASE as parameter (except the most general _PLBF macro)
* FLAG: Depends on macro, "transition" for base transitions, "overlay" for overlays

====Rotations====
For edge-based transitions, the rotations are n,ne,se,s,sw,nw

For corner-based transitions, the rotations are tr,r,br,bl,l,tl (for top-right, right, bottom-right, etc...)

Rotations are always specified in clockwise orientation.

===Basic macros===
Low level macros that are as flexible as possible to do almost everything without extra macros.

Things that can't be done with them are complex multihex-terrains (like mountains) and crazy stuff like bridges.

====Basic terrains====
These are simple terrain definitions that don't depend on the neighbouring tiles.

TERRAIN_BASE TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as base terrain for a tile with TERRAIN. IMAGE should be a 72x72 image, parts that overlap the hex are cut off.
* Default LAYER: -1000
* Default FLAG: "base"

OVERLAY TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as an overlay for a tile with TERRAIN. IMAGE should be a 180x252 image, The center of the tile is at (90,144) in the image (NOTE: This is an annoying restriction. The center of the image should be the center of the tile, no matter the size. This needs some code changes and the existing images need to be cropped. I'll probably do this at another time.) The image can overlap the hex.
* Default LAYER: 0
* Default FLAG: "overlay"

====Transitions====

TRANSITION_BASE TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Creates a "flat" transition between tiles with TERRAIN and ADJACENT. Depending on the number of ADJACENT tiles around the base tile, IMAGE is suffixed with -@R0-@R1-@R2-@R3, -@R0-@R1-@R2, -@R0-@R1 or -@R0. If images with more sides don't exist, the transition will be drawn using images with fewer sides (e.g. a 4-sided transition can also be drawn with one 3-sided and one 1-sided, two 2-sided or four 1-sided images).

Flags on the tiles will be set so that only one transition will be drawn per edge. So a X-Y transition on the south side of the X-tile will prevent a later Y-X transition on the north side of the Y-tile (unless you set a different flag on one of the transitions).

* Default LAYER: -500
* Default FLAG: "transiton"

(This macro is actually a combination of four TRANSITION{n}_BASE macros. But I can't imagine a case where you would actually need those, so they should be treated as implementation details.)

TRANSITION3_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
TRANSITION2_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
TRANSITION1_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Places an overlay image on the tile TERRAIN if there are at least {3,2,1} tiles of ADJECENT next to each other around it.IMAGE is suffixed with -@R0-@R1-@R2, -@R0-@R1 or -@R0. The image is placed in the same manner as in the OVERLAY macro.

Flags on the center tile will be set so that only one overlay will be drawn. (unless you set a different flag).

* Default LAYER: 0
* Default FLAG: "overlay"

(I'm not really happy with that name as it is basically the opposite of the TRANSITION_BASE macro. It's used for e.g. forest to draw smaller overlays when adjacent to terrains like castles.)

ADJACENT3_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
ADJACENT2_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
ADJACENT1_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Places an overlay image on the tile TERRAIN if there are at least {3,2,1} tiles of ADJECENT around it. In contrast to the TRANSITIONn_OVERLAY macros, those don't need to be next to each other, and IMAGE does not get any direction suffixes. The image is placed in the same manner as in the OVERLAY macro.

Flags on the center tile will be set so that only one overlay will be drawn. (unless you set a different flag).

* Default LAYER: 0
* Default FLAG: "overlay"

(used for the same case as TRANSITIONn_OVERLAY, but without rotating the image.)

CORNER_OVERLAY TERRAIN ADJACENT1 ADJACENT2 [PROB] [LAYER] [FLAG] IMAGE

Defines a transition between three terrains TERRAIN, ADJACENT1 and ADJACENT2 (ordered clockwise around the corner). IMAGE is suffixed with -@R0 and should be a 126x180 image. The corner of the three tiles is at (72,108) in the image (NOTE: The same applies here as in OVERLAY. Except it is not nearly as annoying and it would require more work to change, so I'll most likely keep it as it is).

Flags on the tiles will be set so that only one transition will be drawn per corner. (unless you set a different flag on one of the transitions). This works similar to the way TRANSITION_BASE works, just with three tiles.

* Default LAYER: 0
* Default FLAG: "overlay"

(I'm thinking of a macro EDGE_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE that would work like CORNER_OVERLAY but on two terrains only. It's easy to add but I only could think of quite hypothetical usecases)

====Misc macros====

DISABLE_TRANSITIONS TERRAIN [FLAG]

Sets the flags for this and all neighbouring tiles so that TRANSITION_BASE won't draw any transition on the edges of the center tile.

When setting a different flag, transitions will be disabled for all TRANSITION_BASE macros using that flag.

* Default FLAG: "transition"

===Higher level macros===
These are usually compound macros that combine frequently used patterns of low level macros.

A frequent restriction of these macros is usually, that they don't work well with probabilities. We could include some macros that try to place alternative images if they exist (at least for some common cases).

I don't know if all parameter combinations are necessary here. Probably not, but depending on practical use, I might include them.

SIMPLE_OVERLAY_TERRAIN TERRAIN RESTRICTING IMAGE

Draws forest-like overlays. Places the overlay in the following manner (always assuming the image variant exists, otherwise it will just go to the next case):
* If there are more than 2 RESTRICTING tiles around the center, place IMAGE-small
* If there are 2 RESTRICTING tiles next to each other, and IMAGE-@R0-@R1 exists, place it
* If there are 2 RESTRICTING tiles *not* next to each other, place IMAGE-small
* If there is 1 RESTRICTING arund the center, place IMAGE-@R0
* Else, place IMAGE

WALL_TRANSITION TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Draws a castle-like transition between TERRAIN and ADJACENT tiles.
Uses the images IMAGE-convex-@R0 and IMAGE-concave-@R0

WALL_TRANSITION_CORNER TERRAIN ADJACENT1 ADJACENT2 [PROB] [LAYER] [FLAG] IMAGE

Draws a castle-like transition between TERRAIN, ADJACENT1 and ADJACENT2 tiles.
Uses the images IMAGE-cw-@R0 and IMAGE-ccw-@R0

You usually only want to do this if you have different WALL_TRANSITION macros for ADJACENT1 and ADJACENT2.

===Convenience macros===
Simple macros that usually just set some commonly used parameters for you

VILLAGE_P TERRAIN [PROB] IMAGE

Draws an overlay with the "village" flag set.

User:Mog/TerrainReorg

2008-04-20T12:53:32Z

Mog:

==Terrain macro overhaul==

The terrain macros are currently a mess. There are lots of inconsitencies and often several different ways to do the same thing.

I found the following issues. Feel free to add/comment to the list.

===Issues===
* Inconsistent ordering of parameters

* Inconsistent naming of macros

* Two ways of naming rotations. Most terrains have (n,ne,se,s,sw,nw), i.e. rotations are named according to the edges of the hex. Castles/chasm/etc. have the rotations (ne,e,se,sw,w,nw) i.e. named for the corners of the hex.

===Proposed changes===
* Have a consistent naming scheme. E.g. all macros that have a flag parameter end with _F, macros with a probability parameter with _P, layer with _L. Ideally, these suffixes are ordered the same way as the coresponding parameters.

* Most macros have a similar structure, so i suggest the following parameter ordering:
MACRO_NAME IDS1 [,IDS2, [IDS3, ...]] [LAYER] [PROB] [FLAG] IMAGE

There may be macros where this scheme will not work, but for the majority it should.

* I suggest renaming the castle tiles to use the more common naming method. This means renaming a corner direction to two edge directions (e.g. ne-> n-ne, e->ne-se, etc.). This also makes clear if the hexes around the corner are ordered clockwise or counterclockwise (another current inconsitency btw.)

==Macro-proposal==

===General===
====Parameter ordering====
The general parameter ordering is:
MACRO TERRAIN [ADJACENT1 [ADJACENT2 [...]]] [PROB] [LAYER] [BASE] [FLAG] [IMAGE]

Explanation:
* TERRAIN: The "center tile" on which the majority of the terrain is drawn, or -- in the case of some transitions -- the terrain which is the center of the rotation
* ADJACENT1 ... ADJACENTn: Adjacent tiles, depends on the exact macro. If more than one, ordered clockwise around the center tile.
* PROB: Probability
* LAYER: Layer on which the terrain is drawn (higher layers cover lower ones)
* BASE: For overlay terrains, defines the z-ordering among terrains on the same layer
* FLAG: Macros usually make sure that each type of transition occurs only once per tile. Default flags are "transition" for base terrains and "overlay" for overlays. Override the default flag if you need more than one transition stacked on the same tile.
* IMAGE: The basename of the image. Will be appended with a suffix depending on the macro

As the parameter number of each macro is fixed, variants of each macro exist for various combinations of optional parameters. The scheme is as follows:

MACRO_P for macros taking PROB as a parameter
MACRO_L for macros taking LAYER as a parameter
MACRO_B for macros taking BASE as a parameter
MACRO_F for macros taking FLAG as a parameter

and combinations thereof.

e.g.
MACRO_PF takes PROB and FLAG parameters

For parameters that don't occur, default values are used as follows:
* PROB: 100
* LAYER: Depends on macro, but generally -500 for transitions, 0 for overlays
* BASE: Depends on macro, but doesn't need to be overridden except in the most unusual circumstances. So I don't create macro-alternatives which take BASE as parameter (except the most general _PLBF macro)
* FLAG: Depends on macro, "transition" for base transitions, "overlay" for overlays

====Rotations====
For edge-based transitions, the rotations are n,ne,se,s,sw,nw

For corner-based transitions, the rotations are tr,r,br,bl,l,tl (for top-right, right, bottom-right, etc...)

Rotations are always specified in clockwise orientation.

===Basic macros===
Low level macros that are as flexible as possible to do almost everything without extra macros.

Things that can't be done with them are complex multihex-terrains (like mountains) and crazy stuff like bridges.

====Basic terrains====
These are simple terrain definitions that don't depend on the neighbouring tiles.

TERRAIN_BASE TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as base terrain for a tile with TERRAIN. IMAGE should be a 72x72 image, parts that overlap the hex are cut off.
* Default LAYER: -1000
* Default FLAG: "base"

OVERLAY TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as an overlay for a tile with TERRAIN. IMAGE should be a 180x252 image, The center of the tile is at (90,144) in the image (NOTE: This is an annoying restriction. The center of the image should be the center of the tile, no matter the size. This needs some code changes and the existing images need to be cropped. I'll probably do this at another time.) The image can overlap the hex.
* Default LAYER: 0
* Default FLAG: "overlay"

====Transitions====

TRANSITION_BASE TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Creates a "flat" transition between tiles with TERRAIN and ADJACENT. Depending on the number of ADJACENT tiles around the base tile, IMAGE is suffixed with -@R0-@R1-@R2-@R3, -@R0-@R1-@R2, -@R0-@R1 or -@R0. If images with more sides don't exist, the transition will be drawn using images with fewer sides (e.g. a 4-sided transition can also be drawn with one 3-sided and one 1-sided, two 2-sided or four 1-sided images).

Flags on the tiles will be set so that only one transition will be drawn per edge. So a X-Y transition on the south side of the X-tile will prevent a later Y-X transition on the north side of the Y-tile (unless you set a different flag on one of the transitions).

* Default LAYER: -500
* Default FLAG: "transiton"

(This macro is actually a combination of four TRANSITION{n}_BASE macros. But I can't imagine a case where you would actually need those, so they should be treated as implementation details.)

TRANSITION3_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
TRANSITION2_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
TRANSITION1_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Places an overlay image on the tile TERRAIN if there are at least {3,2,1} tiles of ADJECENT next to each other around it.IMAGE is suffixed with -@R0-@R1-@R2, -@R0-@R1 or -@R0. The image is placed in the same manner as in the OVERLAY macro.

Flags on the center tile will be set so that only one overlay will be drawn. (unless you set a different flag).

* Default LAYER: 0
* Default FLAG: "overlay"

(I'm not really happy with that name as it is basically the opposite of the TRANSITION_BASE macro. It's used for e.g. forest to draw smaller overlays when adjacent to terrains like castles.)

ADJACENT3_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
ADJACENT2_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
ADJACENT1_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Places an overlay image on the tile TERRAIN if there are at least {3,2,1} tiles of ADJECENT around it. In contrast to the TRANSITIONn_OVERLAY macros, those don't need to be next to each other, and IMAGE does not get any direction suffixes. The image is placed in the same manner as in the OVERLAY macro.

Flags on the center tile will be set so that only one overlay will be drawn. (unless you set a different flag).

* Default LAYER: 0
* Default FLAG: "overlay"

(used for the same case as TRANSITIONn_OVERLAY, but without rotating the image.)

CORNER_OVERLAY TERRAIN ADJACENT1 ADJACENT2 [PROB] [LAYER] [FLAG] IMAGE

Defines a transition between three terrains TERRAIN, ADJACENT1 and ADJACENT2 (ordered clockwise around the corner). IMAGE is suffixed with -@R0 and should be a 126x180 image. The corner of the three tiles is at (72,108) in the image (NOTE: The same applies here as in OVERLAY. Except it is not nearly as annoying and it would require more work to change, so I'll most likely keep it as it is).

Flags on the tiles will be set so that only one transition will be drawn per corner. (unless you set a different flag on one of the transitions). This works similar to the way TRANSITION_BASE works, just with three tiles.

* Default LAYER: 0
* Default FLAG: "overlay"

(I'm thinking of a macro EDGE_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE that would work like CORNER_OVERLAY but on two terrains only. It's easy to add but I only could think of quite hypothetical usecases)

====Misc macros====

DISABLE_TRANSITIONS TERRAIN [FLAG]

Sets the flags for this and all neighbouring tiles so that TRANSITION_BASE won't draw any transition on the edges of the center tile.

When setting a different flag, transitions will be disabled for all TRANSITION_BASE macros using that flag.

* Default FLAG: "transition"

===Higher level macros===
These are usually compound macros that combine frequently used patterns of low level macros.

A frequent restriction of these macros is usually, that they don't work well with probabilities. We could include some macros that try to place alternative images if they exist (at least for some common cases).

I don't know if all parameter combinations are necessary here. Probably not, but depending on practical use, I might include them.

SIMPLE_OVERLAY_TERRAIN TERRAIN RESTRICTING IMAGE

Draws forest-like overlays. Places the overlay in the following manner (always assuming the image variant exists, otherwise it will just go to the next case):
* If there are more than 2 RESTRICTING tiles around the center, place IMAGE-small
* If there are 2 RESTRICTING tiles next to each other, and IMAGE-@R0-@R1 exists, place it
* If there are 2 RESTRICTING tiles *not* next to each other, place IMAGE-small
* If there is 1 RESTRICTING arund the center, place IMAGE-@R0
* Else, place IMAGE

WALL_TRANSITION TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Draws a castle-like transition between TERRAIN and ADJACENT tiles.
Uses the images IMAGE-convex-@R0 and IMAGE-concave-@R0

WALL_TRANSITION_CORNER TERRAIN ADJACENT1 ADJACENT2 [PROB] [LAYER] [FLAG] IMAGE

Draws a castle-like transition between TERRAIN, ADJACENT1 and ADJACENT2 tiles.
Uses the images IMAGE-cw-@R0 and IMAGE-ccw-@R0

You usually only want to do this if you have different WALL_TRANSITION macros for ADJACENT1 and ADJACENT2.

===Convenience macros===
Simple macros that usually just set some commonly used parameters for you

VILLAGE_P TERRAIN [PROB] IMAGE

Draws an overlay with the "village" flag set.

User:Mog/TerrainReorg

2008-04-20T12:48:28Z

Mog:

==Terrain macro overhaul==

The terrain macros are currently a mess. There are lots of inconsitencies and often several different ways to do the same thing.

I found the following issues. Feel free to add/comment to the list.

===Issues===
* Inconsistent ordering of parameters

* Inconsistent naming of macros

* Two ways of naming rotations. Most terrains have (n,ne,se,s,sw,nw), i.e. rotations are named according to the edges of the hex. Castles/chasm/etc. have the rotations (ne,e,se,sw,w,nw) i.e. named for the corners of the hex.

===Proposed changes===
* Have a consistent naming scheme. E.g. all macros that have a flag parameter end with _F, macros with a probability parameter with _P, layer with _L. Ideally, these suffixes are ordered the same way as the coresponding parameters.

* Most macros have a similar structure, so i suggest the following parameter ordering:
MACRO_NAME IDS1 [,IDS2, [IDS3, ...]] [LAYER] [PROB] [FLAG] IMAGE

There may be macros where this scheme will not work, but for the majority it should.

* I suggest renaming the castle tiles to use the more common naming method. This means renaming a corner direction to two edge directions (e.g. ne-> n-ne, e->ne-se, etc.). This also makes clear if the hexes around the corner are ordered clockwise or counterclockwise (another current inconsitency btw.)

==Macro-proposal==

===General===
====Parameter ordering====
The general parameter ordering is:
MACRO TERRAIN [ADJACENT1 [ADJACENT2 [...]]] [PROB] [LAYER] [BASE] [FLAG] [IMAGE]

Explanation:
* TERRAIN: The "center tile" on which the majority of the terrain is drawn, or -- in the case of some transitions -- the terrain which is the center of the rotation
* ADJACENT1 ... ADJACENTn: Adjacent tiles, depends on the exact macro. If more than one, ordered clockwise around the center tile.
* PROB: Probability
* LAYER: Layer on which the terrain is drawn (higher layers cover lower ones)
* BASE: For overlay terrains, defines the z-ordering among terrains on the same layer
* FLAG: Macros usually make sure that each type of transition occurs only once per tile. Default flags are "transition" for base terrains and "overlay" for overlays. Override the default flag if you need more than one transition stacked on the same tile.
* IMAGE: The basename of the image. Will be appended with a suffix depending on the macro

As the parameter number of each macro is fixed, variants of each macro exist for various combinations of optional parameters. The scheme is as follows:

MACRO_P for macros taking PROB as a parameter
MACRO_L for macros taking LAYER as a parameter
MACRO_B for macros taking BASE as a parameter
MACRO_F for macros taking FLAG as a parameter

and combinations thereof.

e.g.
MACRO_PF takes PROB and FLAG parameters

For parameters that don't occur, default values are used as follows:
* PROB: 100
* LAYER: Depends on macro, but generally -500 for transitions, 0 for overlays
* BASE: Depends on macro, but doesn't need to be overridden except in the most unusual circumstances. So I don't create macro-alternatives which take BASE as parameter (except the most general _PLBF macro)
* FLAG: Depends on macro, "transition" for base transitions, "overlay" for overlays

====Rotations====
For edge-based transitions, the rotations are n,ne,se,s,sw,nw

For corner-based transitions, the rotations are tr,r,br,bl,l,tl (for top-right, right, bottom-right, etc...)

Rotations are always specified in clockwise orientation.

===Basic macros===
Low level macros that are as flexible as possible to do almost everything without extra macros.

Things that can't be done with them are complex multihex-terrains (like mountains) and crazy stuff like bridges.

====Basic terrains====
These are simple terrain definitions that don't depend on the neighbouring tiles.

TERRAIN_BASE TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as base terrain for a tile with TERRAIN. IMAGE should be a 72x72 image, parts that overlap the hex are cut off.
* Default LAYER: -1000
* Default FLAG: "base"

TERRAIN_BASE_DEFAULT IMAGE

Sets the default base terrain. Should be the last macro in the terrain definitions.

OVERLAY TERRAIN [PROB] [LAYER] [FLAG] IMAGE

Sets IMAGE as an overlay for a tile with TERRAIN. IMAGE should be a 180x252 image, The center of the tile is at (90,144) in the image (NOTE: This is an annoying restriction. The center of the image should be the center of the tile, no matter the size. This needs some code changes and the existing images need to be cropped. I'll probably do this at another time.) The image can overlap the hex.
* Default LAYER: 0
* Default FLAG: "overlay"

====Transitions====

TRANSITION_BASE TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Creates a "flat" transition between tiles with TERRAIN and ADJACENT. Depending on the number of ADJACENT tiles around the base tile, IMAGE is suffixed with -@R0-@R1-@R2-@R3, -@R0-@R1-@R2, -@R0-@R1 or -@R0. If images with more sides don't exist, the transition will be drawn using images with fewer sides (e.g. a 4-sided transition can also be drawn with one 3-sided and one 1-sided, two 2-sided or four 1-sided images).

Flags on the tiles will be set so that only one transition will be drawn per edge. So a X-Y transition on the south side of the X-tile will prevent a later Y-X transition on the north side of the Y-tile (unless you set a different flag on one of the transitions).

* Default LAYER: -500
* Default FLAG: "transiton"

(This macro is actually a combination of four TRANSITION{n}_BASE macros. But I can't imagine a case where you would actually need those, so they should be treated as implementation details.)

TRANSITION3_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
TRANSITION2_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
TRANSITION1_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Places an overlay image on the tile TERRAIN if there are at least {3,2,1} tiles of ADJECENT next to each other around it.IMAGE is suffixed with -@R0-@R1-@R2, -@R0-@R1 or -@R0. The image is placed in the same manner as in the OVERLAY macro.

Flags on the center tile will be set so that only one overlay will be drawn. (unless you set a different flag).

* Default LAYER: 0
* Default FLAG: "overlay"

(I'm not really happy with that name as it is basically the opposite of the TRANSITION_BASE macro. It's used for e.g. forest to draw smaller overlays when adjacent to terrains like castles.)

ADJACENT3_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
ADJACENT2_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE
ADJACENT1_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Places an overlay image on the tile TERRAIN if there are at least {3,2,1} tiles of ADJECENT around it. In contrast to the TRANSITIONn_OVERLAY macros, those don't need to be next to each other, and IMAGE does not get any direction suffixes. The image is placed in the same manner as in the OVERLAY macro.

Flags on the center tile will be set so that only one overlay will be drawn. (unless you set a different flag).

* Default LAYER: 0
* Default FLAG: "overlay"

(used for the same case as TRANSITIONn_OVERLAY, but without rotating the image.)

CORNER_OVERLAY TERRAIN ADJACENT1 ADJACENT2 [PROB] [LAYER] [FLAG] IMAGE

Defines a transition between three terrains TERRAIN, ADJACENT1 and ADJACENT2 (ordered clockwise around the corner). IMAGE is suffixed with -@R0 and should be a 126x180 image. The corner of the three tiles is at (72,108) in the image (NOTE: The same applies here as in OVERLAY. Except it is not nearly as annoying and it would require more work to change, so I'll most likely keep it as it is).

Flags on the tiles will be set so that only one transition will be drawn per corner. (unless you set a different flag on one of the transitions). This works similar to the way TRANSITION_BASE works, just with three tiles.

* Default LAYER: 0
* Default FLAG: "overlay"

(I'm thinking of a macro EDGE_OVERLAY TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE that would work like CORNER_OVERLAY but on two terrains only. It's easy to add but I only could think of quite hypothetical usecases)

====Misc macros====

DISABLE_TRANSITIONS TERRAIN [FLAG]

Sets the flags for this and all neighbouring tiles so that TRANSITION_BASE won't draw any transition on the edges of the center tile.

When setting a different flag, transitions will be disabled for all TRANSITION_BASE macros using that flag.

* Default FLAG: "transition"

===Higher level macros===
These are usually compound macros that combine frequently used patterns of low level macros.

A frequent restriction of these macros is usually, that they don't work well with probabilities. We could include some macros that try to place alternative images if they exist (at least for some common cases).

I don't know if all parameter combinations are necessary here. Probably not, but depending on practical use, I might include them.

SIMPLE_OVERLAY_TERRAIN TERRAIN RESTRICTING IMAGE

Draws forest-like overlays. Places the overlay in the following manner (always assuming the image variant exists, otherwise it will just go to the next case):
* If there are more than 2 RESTRICTING tiles around the center, place IMAGE-small
* If there are 2 RESTRICTING tiles next to each other, and IMAGE-@R0-@R1 exists, place it
* If there are 2 RESTRICTING tiles *not* next to each other, place IMAGE-small
* If there is 1 RESTRICTING arund the center, place IMAGE-@R0
* Else, place IMAGE

WALL_TRANSITION TERRAIN ADJACENT [PROB] [LAYER] [FLAG] IMAGE

Draws a castle-like transition between TERRAIN and ADJACENT tiles.
Uses the images IMAGE-convex-@R0 and IMAGE-concave-@R0

WALL_TRANSITION_CORNER TERRAIN ADJACENT1 ADJACENT2 [PROB] [LAYER] [FLAG] IMAGE

Draws a castle-like transition between TERRAIN, ADJACENT1 and ADJACENT2 tiles.
Uses the images IMAGE-cw-@R0 and IMAGE-ccw-@R0

You usually only want to do this if you have different WALL_TRANSITION macros for ADJACENT1 and ADJACENT2.

===Convenience macros===
Simple macros that usually just set some commonly used parameters for you

VILLAGE_P TERRAIN [PROB] IMAGE

Draws an overlay with the "village" flag set.

TerrainWML

2008-04-05T11:43:01Z

Mog: remove no_overlay and adjacent_image descriptions

{{WML Tags}}
== the toplevel [terrain] tag ==

The [terrain] tag describes a terrain in WML.
Terrains are usually described in the terrain.cfg file

the [terrain] tag has the following keys and subtags
* '''symbol_image''': an image used for this terrain in the minimap
* '''editor_image''': an image used for this terrain in the map editor if not defined uses symbol_image
* '''name''': the name of the terrain
* '''string''': this is the string that represents the terrain in maps and scenarions
* '''unit_height_adjust''': how much the unit graphic should be moved up or down when on that terrain
* '''submerge''': float, between 0 and 1: stems how much of the unit graphic should be submerged by the terrain
* '''light''': signed value: this will modified local light level on that hex by that amount for gameplay
* '''heals''': signed value: this value is the amount of HP an unit will be healed at the start of every turn. (If set to true a unit on that terrain will be healed 8 HP at the start of every turn, this notation is deappriciated and support might stop at some point.)
* '''gives_income''': if set to true, this terrain will give income every turn when flagged as if it were a village
* '''recruit_onto''': if set to true, it is possible to recruit or recall on that terrain
* '''recruit_from''': if set to true it is possible to recruit when a unit that can recruit is on that terrain
* '''aliasof''': comma separated string representing terrains that this terrain will be an alias of. This is a list of characters, with the + and - signs having special meanings. the string is read left to right taking the best value. when a minus sign is encountered, it starts taking the worst instead. the plus sign reverts it back to the best (note after a + or - a comma is also required. In order to include a + sign the entire line must be placed between double quotes.)
* '''def_alias''': like ''aliasof'' but overides it for defense calculation only
* '''mvt_alias''': like ''aliasof'' but overides it for movement calculation only
* '''income_description''': for terrains with ''gives_income'' and owned by nobody this text is shown in the terrain description in the top bar before the brackets. This tag is optional, if not supplied Wesnoth will assume the terrain is a village and sets an appropriate message.
* '''income_description_ally''': like ''income_description'' but if owned by an ally
* '''income_description_enemy''': like ''income_description'' but if owned by an enemy
* '''income_description_own''': like ''income_description'' but if owned by yourself
* '''editor_group''': a comma separated list of editor_group ids to which this terrain belongs.

== See Also ==

* [[ReferenceWML]]
* [[TerrainCodesWML]]
* [[EditorGroupWML]]

[[Category: WML Reference]]

User:Mog/TerrainReorg

2008-04-05T09:32:25Z

Mog:

User:Mog/TerrainReorg

2008-04-05T09:31:52Z

Mog: New page: ==Terrain macro overhaul== The terrain macros are currently a mess. There are lots of inconsitencies and often several different ways to do the same thing. I found the following issues. ...

User:Mog

2007-03-27T19:16:34Z

Mog:

== Suggested changes for multilayer terrain ==
=== certain changes ===
Changes that shouldn't be disputed as there are no disadvantages

Old New
Bww* Ww^Bw* wooden bridge "bridge, over wadeable, wooden"
Bwo* Wo^Bw* wooden bridge "bridge, over ocean, wooden"
Bss* Ss^Bw* wooden bridge "bridge, over swamp, wooden"

Fa Aa^Fa forest (snow) "forest arctic"
Fet Gg^Fet great Elven tree
Ff Gg^Ff forest
Ft Gs^Ft forest (tropical)
Uf Uu^Uf mushroom grove "underground forest"

Dc Dd^Dc UtbS desert crater (may need graphics changes)
Do Dd^Do desert oasis (may need graphics changes)
Dr Dd^Dr UtbS sand rubble

Rfvs Re^Gvs Farmer's Fields

Vda Dd^Vda desert village (adobe)
Vdt Dd^Vdt desert village (tent)
Vea Aa^Vea elven (snow) village
Veg Gg^Veg elven village "village elven grassland"
Vha Aa^Vha snow village (tundra, village)
Vhg Gg^Vhg human village (village)
Vhh Hh^Vhh human hill village
Vhha Ha^Vhha human (snow) hill village
Vhm Mm^Vhh human mountain village
Vht Gs^Vht tropical village (savanna, village)
Vu Uu^Vu underground village (cave, village)
Vud Uu^Vud dwarven village
Vwm Ww^Vm mermen village (shallow water)
Vs Ss^Vhs swamp village (swamp, village)
Vsm Ss^Vm mermen village (swamp)

=== Possible changes ===

Xm Mm^Xm impassable moutains
This one is nice for WML, but having the impassable string als overlay only might

=== Problematic changes ===

Chs Chs^Sr human ruin (swamp)
Ss Ss^Sr swamp
I'd like it, so you could add reed easily to other terrains, but it has some problems with the t-g WML (especially interacting with castle walls). If I can solve those, I'd like to make these changes.

User:Mog

2006-10-29T14:57:33Z

Mog:

=== proposal for new terrain strings ===
<table border="1"><tr>
<th>Letter</th>
<th>String</th>
<th>Theme</th>
<th>Description</th>
</tr>
<tr>
<td>A</td>
<td>Vhhs</td>
<td>village, snow, hill</td>
<td>human (snow) hill village</td>

</tr><tr>
<td>a</td>
<td>Vhh</td>
<td>village, hill</td>
<td>human hill village</td>

</tr><tr>
<td>B</td>
<td>Vda</td>
<td>village, desert</td>
<td>desert village (adobe)</td>

</tr><tr>
<td>b</td>
<td>Vhm</td>
<td>village, mountain</td>
<td>human mountain village</td>

</tr><tr>
<td>C</td>
<td>Ch</td>
<td>castle</td>
<td>human castle</td>

</tr><tr>
<td>c</td>
<td>Ws</td>
<td>water, common</td>
<td>shallow water, "coast"</td>

</tr><tr>
<td>D</td>
<td>Vu</td>
<td>village, cave</td>
<td>underground village (cave, village), "dungeon village"</td>

</tr><tr>
<td>d</td>
<td>Ds</td>
<td>plain, desert</td>
<td>sand, (old desert)</td>

</tr><tr>
<td>E</td>
<td>Rd</td>
<td>road, desert</td>
<td>desert road</td>

</tr><tr>
<td>e</td>
<td>Ves</td>
<td>village, snow</td>
<td>elven (snow) village</td>

</tr><tr>
<td>F</td>
<td>Fs</td>
<td>forest, snow</td>
<td>forest (snow)</td>

</tr><tr>
<td>f</td>
<td>F</td>
<td>forrest, common</td>
<td>forest</td>

</tr><tr>
<td>G</td>
<td>Gs</td>
<td>plain</td>
<td>savanna (grass)</td>

</tr><tr>
<td>g</td>
<td>G</td>
<td>plain, common</td>
<td>grass</td>

</tr><tr>
<td>H</td>
<td>Hs</td>
<td>hill, snow</td>
<td>hills (snow)</td>

</tr><tr>
<td>h</td>
<td>H</td>
<td>hill, common</td>
<td>hills</td>

</tr><tr>
<td>I</td>
<td>D</td>
<td>plain, desert</td>
<td>desert</td>

</tr><tr>
<td>i</td>
<td>Pi</td>
<td>plain</td>
<td>ice (tundra)</td>

</tr><tr>
<td>J</td>
<td>Hd</td>
<td>hill, desert</td>
<td>desert hills</td>

</tr><tr>
<td>j</td>
<td>Ms</td>
<td>mountain, snow</td>
<td>-nothing- (will be snowy mountains)</td>

</tr><tr>
<td>K</td>
<td>K</td>
<td>misc</td>
<td>keep (castle)</td>

</tr><tr>
<td>k</td>
<td>Wf</td>
<td>water</td>
<td>river ford (grass, shallow water)</td>

</tr><tr>
<td>L</td>
<td>Vtf/Vt</td>
<td>village, forest</td>
<td>tropical forest village (savanna, village)</td>

</tr><tr>
<td>l</td>
<td>Ql</td>
<td>misc</td>
<td>lava (canyon)</td>

</tr><tr>
<td>M</td>
<td>Md</td>
<td>mountain, desert</td>
<td>desert mountains</td>

</tr><tr>
<td>m</td>
<td>M</td>
<td>mountain, common</td>
<td>mountain</td>

</tr><tr>
<td>N</td>
<td>Chr</td>
<td>castle</td>
<td>ruined human castle</td>

</tr><tr>
<td>n</td>
<td>Ce</td>
<td>castle, common</td>
<td>encampment (castle)</td>

</tr><tr>
<td>O</td>
<td>Co</td>
<td>castle</td>
<td>-nothing- ( will probably be an Orc Castle one day )</td>

</tr><tr>
<td>o</td>
<td>Cd</td>
<td>castle</td>
<td>dwarven castle (castle)</td>

</tr><tr>
<td>P</td>
<td>Do</td>
<td>desert</td>
<td>desert oasis</td>

</tr><tr>
<td>p</td>
<td>Vud</td>
<td>village</td>
<td>dwarven village</td>

</tr><tr>
<td>Q</td>
<td>Chw</td>
<td>castle, water</td>
<td>sunken human ruin</td>

</tr><tr>
<td>q</td>
<td>Chs</td>
<td>castle, water</td>
<td>human ruin (swamp)</td>

</tr><tr>
<td>R</td>
<td>Rs</td>
<td>plain, common</td>
<td>stone road</td>

</tr><tr>
<td>r</td>
<td>R</td>
<td>plain</td>
<td>dirt road</td>

</tr><tr>
<td>S</td>
<td>Pt</td>
<td>plain</td>
<td>tundra</td>

</tr><tr>
<td>s</td>
<td>Wd</td>
<td>water, common</td>
<td>deep water</td>

</tr><tr>
<td>T</td>
<td>Ft</td>
<td>forest</td>
<td>forest (tropical)</td>

</tr><tr>
<td>t</td>
<td>Ve</td>
<td>village, common??</td>
<td>elven village</td>

</tr><tr>
<td>U</td>
<td>Vdt</td>
<td>village desert</td>
<td>desert village (tent)</td>

</tr><tr>
<td>u</td>
<td>U</td>
<td>cave, plain</td>
<td>cave</td>

</tr><tr>
<td>V</td>
<td>Vhs</td>
<td>village, snow</td>
<td>human snow village</td>

</tr><tr>
<td>v</td>
<td>Vh</td>
<td>village, common</td>
<td>human village (village)</td>

</tr><tr>
<td>W</td>
<td>Xc</td>
<td>cave, impassable</td>
<td>cavewall</td>

</tr><tr>
<td>w</td>
<td>S</td>
<td>water</td>
<td>swamp</td>

</tr><tr>
<td>X</td>
<td>Qc</td>
<td>misc</td>
<td>canyon (replaced by chasm in trunk)</td>

</tr><tr>
<td>x</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>Y</td>
<td>Vws</td>
<td>village, water</td>
<td>swamp village (swamp, village)</td>

</tr><tr>
<td>y</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>Z</td>
<td>Vwm</td>
<td>Village, water</td>
<td>mermen village (shallow water)</td>

</tr><tr>
<td>z</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>/</td>
<td>Bw/</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>|</td>
<td>Bw|</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>\</td>
<td>Bw\</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>~</td>
<td></td>
<td></td>
<td>fog, can this be used in game?</td>

</tr><tr>
<td> </td>
<td></td>
<td></td>
<td>void/shroud (it uses the "space" character), can this be used in game?</td>

</tr><tr>
<td>[</td>
<td>Ur</td>
<td>plain, cave</td>
<td>rockbound cave</td>

</tr><tr>
<td>]</td>
<td>Fu (Uf?)</td>
<td>forrest, cave</td>
<td>mushroom grove</td>

</tr><tr>
<td>'</td>
<td>Ui</td>
<td>plain, cave</td>
<td>illuminated cave </td>

</tr><tr>
<td>?</td>
<td>Fe(t?)</td>
<td>forrest, misc</td>
<td>great Elven tree</td>

</tr><tr>
<td>&</td>
<td>Mi</td>
<td>mountain</td>
<td>impassable moutains</td>
</tr></table>

=== new terrains ordered ===
Bw/ misc wooden bridge
Bw| misc wooden bridge
Bw\ misc wooden bridge
Cd castle dwarven castle (castle)
Ce castle, common encampment (castle)
Ch castle human castle
Chr castle ruined castle
Chs castle, water human ruin (swamp)
Chw castle, water human sunken ruin
Co castle -nothing- ( will probably be an Orc Castle one day )
D plain, desert desert
Do desert desert oasis
Ds plain, desert sand, (old desert)
F forrest, common forest
Fe(t) forrest, misc great Elven tree
Fs forest, snow forest (snow)
Ft forest forest (tropical)
Fu/Uf forrest, cave mushroom grove
G plain, common grass
Gs plain savanna (grass)
H hill, common hills
Hd hill, desert desert hills
Hs hill, snow hills (snow)
K misc keep (castle)
M mountain, common mountain
Md mountain, desert desert mountains
Mi/Xm mountain impassable moutains
Ms mountain, snow snowy mountains
Pi plain ice (tundra)
Pt plain tundra
Qc misc canyon/chasm
Ql misc lava
R plain dirt road
Rd road, desert desert road
Rs plain, common stone road
S water swamp
U cave, plain cave
Ui plain, cave illuminated cave
Ur plain, cave rockbound cave
Vda village, desert desert village (adobe)
Vdt village, desert desert village (tent)
Ve village, common?? village
Ves village, snow elven (snow) village
Vh village, common human village (village)
Vhh village, hill human hill village
Vhhs village, snow, hill human (snow) hill village
Vhm village, mountain human mountain village
Vhs village, snow snow village (tundra, village)
Vt(f) village, forest tropical forest village (savanna, village)
Vu village, cave underground village (cave, village), "dungeon village"
Vud village dwarven village
Vwm Village, water mermen village (shallow water)
Vws village, water swamp village (swamp, village)
Wd water, common deep water
Wf water river ford (grass, shallow water)
Wu water, common shallow water, "coast"
Xc cave, impassable cavewall

User:Mog

2006-10-29T14:55:02Z

Mog:

=== proposal for new terrain strings ===
<table border="1"><tr>
<th>Letter</th>
<th>String</th>
<th>Theme</th>
<th>Description</th>
</tr>
<tr>
<td>A</td>
<td>Vhhs</td>
<td>village, snow, hill</td>
<td>human (snow) hill village</td>

</tr><tr>
<td>a</td>
<td>Vhh</td>
<td>village, hill</td>
<td>human hill village</td>

</tr><tr>
<td>B</td>
<td>Vda</td>
<td>village, desert</td>
<td>desert village (adobe)</td>

</tr><tr>
<td>b</td>
<td>Vhm</td>
<td>village, mountain</td>
<td>human mountain village</td>

</tr><tr>
<td>C</td>
<td>Ch</td>
<td>castle</td>
<td>human castle</td>

</tr><tr>
<td>c</td>
<td>Ws</td>
<td>water, common</td>
<td>shallow water, "coast"</td>

</tr><tr>
<td>D</td>
<td>Vu</td>
<td>village, cave</td>
<td>underground village (cave, village), "dungeon village"</td>

</tr><tr>
<td>d</td>
<td>Ds</td>
<td>plain, desert</td>
<td>sand, (old desert)</td>

</tr><tr>
<td>E</td>
<td>Rd</td>
<td>road, desert</td>
<td>desert road</td>

</tr><tr>
<td>e</td>
<td>Ves</td>
<td>village, snow</td>
<td>elven (snow) village</td>

</tr><tr>
<td>F</td>
<td>Fs</td>
<td>forest, snow</td>
<td>forest (snow)</td>

</tr><tr>
<td>f</td>
<td>F</td>
<td>forrest, common</td>
<td>forest</td>

</tr><tr>
<td>G</td>
<td>Gs</td>
<td>plain</td>
<td>savanna (grass)</td>

</tr><tr>
<td>g</td>
<td>G</td>
<td>plain, common</td>
<td>grass</td>

</tr><tr>
<td>H</td>
<td>Hs</td>
<td>hill, snow</td>
<td>hills (snow)</td>

</tr><tr>
<td>h</td>
<td>H</td>
<td>hill, common</td>
<td>hills</td>

</tr><tr>
<td>I</td>
<td>D</td>
<td>plain, desert</td>
<td>desert</td>

</tr><tr>
<td>i</td>
<td>Pi</td>
<td>plain</td>
<td>ice (tundra)</td>

</tr><tr>
<td>J</td>
<td>Hd</td>
<td>hill, desert</td>
<td>desert hills</td>

</tr><tr>
<td>j</td>
<td>Ms</td>
<td>mountain, snow</td>
<td>-nothing- (will be snowy mountains)</td>

</tr><tr>
<td>K</td>
<td>K</td>
<td>misc</td>
<td>keep (castle)</td>

</tr><tr>
<td>k</td>
<td>Wf</td>
<td>water</td>
<td>river ford (grass, shallow water)</td>

</tr><tr>
<td>L</td>
<td>Vtf/Vt</td>
<td>village, forest</td>
<td>tropical forest village (savanna, village)</td>

</tr><tr>
<td>l</td>
<td>Ql</td>
<td>misc</td>
<td>lava (canyon)</td>

</tr><tr>
<td>M</td>
<td>Md</td>
<td>mountain, desert</td>
<td>desert mountains</td>

</tr><tr>
<td>m</td>
<td>M</td>
<td>mountain, common</td>
<td>mountain</td>

</tr><tr>
<td>N</td>
<td>Chr</td>
<td>castle</td>
<td>ruined human castle</td>

</tr><tr>
<td>n</td>
<td>Ce</td>
<td>castle, common</td>
<td>encampment (castle)</td>

</tr><tr>
<td>O</td>
<td>Co</td>
<td>castle</td>
<td>-nothing- ( will probably be an Orc Castle one day )</td>

</tr><tr>
<td>o</td>
<td>Cd</td>
<td>castle</td>
<td>dwarven castle (castle)</td>

</tr><tr>
<td>P</td>
<td>Do</td>
<td>desert</td>
<td>desert oasis</td>

</tr><tr>
<td>p</td>
<td>Vud</td>
<td>village</td>
<td>dwarven village</td>

</tr><tr>
<td>Q</td>
<td>Chw</td>
<td>castle, water</td>
<td>sunken human ruin</td>

</tr><tr>
<td>q</td>
<td>Chs</td>
<td>castle, water</td>
<td>human ruin (swamp)</td>

</tr><tr>
<td>R</td>
<td>Rs</td>
<td>plain, common</td>
<td>stone road</td>

</tr><tr>
<td>r</td>
<td>R</td>
<td>plain</td>
<td>dirt road</td>

</tr><tr>
<td>S</td>
<td>Pt</td>
<td>plain</td>
<td>tundra</td>

</tr><tr>
<td>s</td>
<td>Wd</td>
<td>water, common</td>
<td>deep water</td>

</tr><tr>
<td>T</td>
<td>Ft</td>
<td>forest</td>
<td>forest (tropical)</td>

</tr><tr>
<td>t</td>
<td>Ve</td>
<td>village, common??</td>
<td>elven village</td>

</tr><tr>
<td>U</td>
<td>Vdt</td>
<td>village desert</td>
<td>desert village (tent)</td>

</tr><tr>
<td>u</td>
<td>U</td>
<td>cave, plain</td>
<td>cave</td>

</tr><tr>
<td>V</td>
<td>Vhs</td>
<td>village, snow</td>
<td>human snow village</td>

</tr><tr>
<td>v</td>
<td>Vh</td>
<td>village, common</td>
<td>human village (village)</td>

</tr><tr>
<td>W</td>
<td>Xc</td>
<td>cave, impassable</td>
<td>cavewall</td>

</tr><tr>
<td>w</td>
<td>S</td>
<td>water</td>
<td>swamp</td>

</tr><tr>
<td>X</td>
<td>Qc</td>
<td>misc</td>
<td>canyon (replaced by chasm in trunk)</td>

</tr><tr>
<td>x</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>Y</td>
<td>Vws</td>
<td>village, water</td>
<td>swamp village (swamp, village)</td>

</tr><tr>
<td>y</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>Z</td>
<td>Vwm</td>
<td>Village, water</td>
<td>mermen village (shallow water)</td>

</tr><tr>
<td>z</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>/</td>
<td>Bw/</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>|</td>
<td>Bw|</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>\</td>
<td>Bw\</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>~</td>
<td></td>
<td></td>
<td>fog, can this be used in game?</td>

</tr><tr>
<td> </td>
<td></td>
<td></td>
<td>void/shroud (it uses the "space" character), can this be used in game?</td>

</tr><tr>
<td>[</td>
<td>Ur</td>
<td>plain, cave</td>
<td>rockbound cave</td>

</tr><tr>
<td>]</td>
<td>Fu (Uf?)</td>
<td>forrest, cave</td>
<td>mushroom grove</td>

</tr><tr>
<td>'</td>
<td>Ui</td>
<td>plain, cave</td>
<td>illuminated cave </td>

</tr><tr>
<td>?</td>
<td>Fe(t?)</td>
<td>forrest, misc</td>
<td>great Elven tree</td>

</tr><tr>
<td>&</td>
<td>Mi</td>
<td>mountain</td>
<td>impassable moutains</td>
</tr></table>

=== new terrains ordered ===
Bw/ misc wooden bridge
Bw| misc wooden bridge
Bw\ misc wooden bridge
Cd castle dwarven castle (castle)
Ce castle, common encampment (castle)
Ch castle human castle
Co castle -nothing- ( will probably be an Orc Castle one day )
Chr castle ruined castle
Chs castle, water human ruin (swamp)
Chw castle, water human sunken ruin
D plain, desert desert
Do desert desert oasis
Ds plain, desert sand, (old desert)
F forrest, common forest
Fe(t) forrest, misc great Elven tree
Fs forest, snow forest (snow)
Ft forest forest (tropical)
Fu/Uf forrest, cave mushroom grove
G plain, common grass
Gs plain savanna (grass)
H hill, common hills
Hd hill, desert desert hills
Hs hill, snow hills (snow)
K misc keep (castle)
M mountain, common mountain
Md mountain, desert desert mountains
Mi/Xm mountain impassable moutains
Ms mountain, snow snowy mountains
Pi plain ice (tundra)
Pt plain tundra
Qc misc canyon/chasm
Ql misc lava
R plain dirt road
Rd road, desert desert road
Rs plain, common stone road
S water swamp
U cave, plain cave
Ui plain, cave illuminated cave
Ur plain, cave rockbound cave
Vda village, desert desert village (adobe)
Vdt village, desert desert village (tent)
Ve village, common?? village
Ves village, snow elven (snow) village
Vh village, common human village (village)
Vhh village, hill human hill village
Vhhs village, snow, hill human (snow) hill village
Vhm village, mountain human mountain village
Vhs village, snow snow village (tundra, village)
Vt(f) village, forest tropical forest village (savanna, village)
Vu village, cave underground village (cave, village), "dungeon village"
Vud village dwarven village
Vwm Village, water mermen village (shallow water)
Vws village, water swamp village (swamp, village)
Wd water, common deep water
Wf water river ford (grass, shallow water)
Wu water, common shallow water, "coast"
Xc cave, impassable cavewall

User:Mog

2006-10-29T14:54:00Z

Mog:

=== proposal for new terrain strings ===
<table border="1"><tr>
<th>Letter</th>
<th>String</th>
<th>Theme</th>
<th>Description</th>
</tr>
<tr>
<td>A</td>
<td>Vhhs</td>
<td>village, snow, hill</td>
<td>human (snow) hill village</td>

</tr><tr>
<td>a</td>
<td>Vhh</td>
<td>village, hill</td>
<td>human hill village</td>

</tr><tr>
<td>B</td>
<td>Vda</td>
<td>village, desert</td>
<td>desert village (adobe)</td>

</tr><tr>
<td>b</td>
<td>Vhm</td>
<td>village, mountain</td>
<td>human mountain village</td>

</tr><tr>
<td>C</td>
<td>Ch</td>
<td>castle</td>
<td>human castle</td>

</tr><tr>
<td>c</td>
<td>Ws</td>
<td>water, common</td>
<td>shallow water, "coast"</td>

</tr><tr>
<td>D</td>
<td>Vu</td>
<td>village, cave</td>
<td>underground village (cave, village), "dungeon village"</td>

</tr><tr>
<td>d</td>
<td>Ds</td>
<td>plain, desert</td>
<td>sand, (old desert)</td>

</tr><tr>
<td>E</td>
<td>Rd</td>
<td>road, desert</td>
<td>desert road</td>

</tr><tr>
<td>e</td>
<td>Ves</td>
<td>village, snow</td>
<td>elven (snow) village</td>

</tr><tr>
<td>F</td>
<td>Fs</td>
<td>forest, snow</td>
<td>forest (snow)</td>

</tr><tr>
<td>f</td>
<td>F</td>
<td>forrest, common</td>
<td>forest</td>

</tr><tr>
<td>G</td>
<td>Gs</td>
<td>plain</td>
<td>savanna (grass)</td>

</tr><tr>
<td>g</td>
<td>G</td>
<td>plain, common</td>
<td>grass</td>

</tr><tr>
<td>H</td>
<td>Hs</td>
<td>hill, snow</td>
<td>hills (snow)</td>

</tr><tr>
<td>h</td>
<td>H</td>
<td>hill, common</td>
<td>hills</td>

</tr><tr>
<td>I</td>
<td>D</td>
<td>plain, desert</td>
<td>desert</td>

</tr><tr>
<td>i</td>
<td>Pi</td>
<td>plain</td>
<td>ice (tundra)</td>

</tr><tr>
<td>J</td>
<td>Hd</td>
<td>hill, desert</td>
<td>desert hills</td>

</tr><tr>
<td>j</td>
<td>Ms</td>
<td>mountain, snow</td>
<td>-nothing- (will be snowy mountains)</td>

</tr><tr>
<td>K</td>
<td>K</td>
<td>misc</td>
<td>keep (castle)</td>

</tr><tr>
<td>k</td>
<td>Wf</td>
<td>water</td>
<td>river ford (grass, shallow water)</td>

</tr><tr>
<td>L</td>
<td>Vtf/Vt</td>
<td>village, forest</td>
<td>tropical forest village (savanna, village)</td>

</tr><tr>
<td>l</td>
<td>Ql</td>
<td>misc</td>
<td>lava (canyon)</td>

</tr><tr>
<td>M</td>
<td>Md</td>
<td>mountain, desert</td>
<td>desert mountains</td>

</tr><tr>
<td>m</td>
<td>M</td>
<td>mountain, common</td>
<td>mountain</td>

</tr><tr>
<td>N</td>
<td>Chr</td>
<td>castle</td>
<td>ruined human castle</td>

</tr><tr>
<td>n</td>
<td>Ce</td>
<td>castle, common</td>
<td>encampment (castle)</td>

</tr><tr>
<td>O</td>
<td>Co</td>
<td>castle</td>
<td>-nothing- ( will probably be an Orc Castle one day )</td>

</tr><tr>
<td>o</td>
<td>Cd</td>
<td>castle</td>
<td>dwarven castle (castle)</td>

</tr><tr>
<td>P</td>
<td>Do</td>
<td>desert</td>
<td>desert oasis</td>

</tr><tr>
<td>p</td>
<td>Vud</td>
<td>village</td>
<td>dwarven village</td>

</tr><tr>
<td>Q</td>
<td>Chw</td>
<td>castle, water</td>
<td>sunken human ruin</td>

</tr><tr>
<td>q</td>
<td>Chs</td>
<td>castle, water</td>
<td>human ruin (swamp)</td>

</tr><tr>
<td>R</td>
<td>Rs</td>
<td>plain, common</td>
<td>stone road</td>

</tr><tr>
<td>r</td>
<td>R</td>
<td>plain</td>
<td>dirt road</td>

</tr><tr>
<td>S</td>
<td>Pt</td>
<td>plain</td>
<td>tundra</td>

</tr><tr>
<td>s</td>
<td>Wd</td>
<td>water, common</td>
<td>deep water</td>

</tr><tr>
<td>T</td>
<td>Ft</td>
<td>forest</td>
<td>forest (tropical)</td>

</tr><tr>
<td>t</td>
<td>Ve</td>
<td>village, common??</td>
<td>elven village</td>

</tr><tr>
<td>U</td>
<td>Vdt</td>
<td>village desert</td>
<td>desert village (tent)</td>

</tr><tr>
<td>u</td>
<td>U</td>
<td>cave, plain</td>
<td>cave</td>

</tr><tr>
<td>V</td>
<td>Vhs</td>
<td>village, snow</td>
<td>human snow village</td>

</tr><tr>
<td>v</td>
<td>Vh</td>
<td>village, common</td>
<td>human village (village)</td>

</tr><tr>
<td>W</td>
<td>Xc</td>
<td>cave, impassable</td>
<td>cavewall</td>

</tr><tr>
<td>w</td>
<td>S</td>
<td>water</td>
<td>swamp</td>

</tr><tr>
<td>X</td>
<td>Qc</td>
<td>misc</td>
<td>canyon (replaced by chasm in trunk)</td>

</tr><tr>
<td>x</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>Y</td>
<td>Vws</td>
<td>village, water</td>
<td>swamp village (swamp, village)</td>

</tr><tr>
<td>y</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>Z</td>
<td>Vwm</td>
<td>Village, water</td>
<td>mermen village (shallow water)</td>

</tr><tr>
<td>z</td>
<td></td>
<td></td>
<td>reserved for UMCs</td>

</tr><tr>
<td>/</td>
<td>Bw/</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>|</td>
<td>Bw|</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>\</td>
<td>Bw\</td>
<td>misc</td>
<td>wooden bridge</td>

</tr><tr>
<td>~</td>
<td></td>
<td></td>
<td>fog, can this be used in game?</td>

</tr><tr>
<td> </td>
<td></td>
<td></td>
<td>void/shroud (it uses the "space" character), can this be used in game?</td>

</tr><tr>
<td>[</td>
<td>Ur</td>
<td>plain, cave</td>
<td>rockbound cave</td>

</tr><tr>
<td>]</td>
<td>Fu (Uf?)</td>
<td>forrest, cave</td>
<td>mushroom grove</td>

</tr><tr>
<td>'</td>
<td>Ui</td>
<td>plain, cave</td>
<td>illuminated cave </td>

</tr><tr>
<td>?</td>
<td>Fe(t?)</td>
<td>forrest, misc</td>
<td>great Elven tree</td>

</tr><tr>
<td>&</td>
<td>Mi</td>
<td>mountain</td>
<td>impassable moutains</td>
</tr></table>

=== new terrains ordered ===
Bw/ misc wooden bridge
Bw| misc wooden bridge
Bw\ misc wooden bridge
Cd castle dwarven castle (castle)
Ce castle, common encampment (castle)
Ch castle human castle
Co castle -nothing- ( will probably be an Orc Castle one day )
Chr castle ruined castle
Chs castle, water human ruin (swamp)
Chw castle, water human sunken ruin
D plain, desert desert
Do desert desert oasis
Ds plain, desert sand, (old desert)
F forrest, common forest
Fe(t) forrest, misc great Elven tree
Fs forest, snow forest (snow)
Ft forest forest (tropical)
Fu/Uf forrest, cave mushroom grove
G plain, common grass
Gs plain savanna (grass)
H hill, common hills
Hd hill, desert desert hills
Hs hill, snow hills (snow)
K misc keep (castle)
M mountain, common mountain
Md mountain, desert desert mountains
Mi mountain impassable moutains
Ms mountain, snow snowy mountains
Pi plain ice (tundra)
Pt plain tundra
Qc misc canyon/chasm
Ql misc lava
R plain dirt road
Rd road, desert desert road
Rs plain, common stone road
S water swamp
U cave, plain cave
Ui plain, cave illuminated cave
Ur plain, cave rockbound cave
Vda village, desert desert village (adobe)
Vdt village, desert desert village (tent)
Ve village, common?? village
Ves village, snow elven (snow) village
Vh village, common human village (village)
Vhh village, hill human hill village
Vhhs village, snow, hill human (snow) hill village
Vhm village, mountain human mountain village
Vhs village, snow snow village (tundra, village)
Vt(f) village, forest tropical forest village (savanna, village)
Vu village, cave underground village (cave, village), "dungeon village"
Vud village dwarven village
Vwm Village, water mermen village (shallow water)
Vws village, water swamp village (swamp, village)
Wd water, common deep water
Wf water river ford (grass, shallow water)
Wu water, common shallow water, "coast"
Xc cave, impassable cavewall