TerrainMacrosWML - Revision history

Egallager: additional links

2023-05-07T17:44:26Z

additional links

← Older revision		Revision as of 17:44, 7 May 2023
Line 314:		Line 314:

	'''TRACK_BORDER_RESTRICTED_RANDOM_''LF''''' similar, with random variations		'''TRACK_BORDER_RESTRICTED_RANDOM_''LF''''' similar, with random variations

			== See Also ==
			* [[Terrain]]
			* [[TerrainWML]]
			* [[TerrainGraphicsWML]]
			* [https://www.wesnoth.org/macro-reference.html WML Macros]

	[[Category:WML_Reference]]		[[Category:WML_Reference]]

Pentarctagon at 07:18, 16 May 2020

2020-05-16T07:18:01Z

← Older revision		Revision as of 07:18, 16 May 2020
Line 53:		Line 53:
	* '''TERRAIN''' : the type of terrain to put the image on		* '''TERRAIN''' : the type of terrain to put the image on
	* '''ADJACENT''' : ''only for restricted'' the type of neighbours to test for		* '''ADJACENT''' : ''only for restricted'' the type of neighbours to test for
	* '''PROB''' : ''only for _P'' The probability of the rules generated by the macros of being applied. ~~See the discussion in [[TerrainGraphicsTutorial#Cumulative_Probabilities]] for complications~~		* '''PROB''' : ''only for _P'' The probability of the rules generated by the macros of being applied.
	* '''LAYER''' : ''only for _L'' The layer that will be used for the generated rules		* '''LAYER''' : ''only for _L'' The layer that will be used for the generated rules
	* '''FLAG''' : ''only for _F'' A flag to test and set on the tile		* '''FLAG''' : ''only for _F'' A flag to test and set on the tile

Iceiceice at 04:36, 7 April 2014

2014-04-07T04:36:26Z

← Older revision		Revision as of 04:36, 7 April 2014
Line 314:		Line 314:

	'''TRACK_BORDER_RESTRICTED_RANDOM_''LF''''' similar, with random variations		'''TRACK_BORDER_RESTRICTED_RANDOM_''LF''''' similar, with random variations

			[[Category:WML_Reference]]

Crendgrim: Cleaning up documentation for 1.10

2012-01-29T16:11:43Z

Cleaning up documentation for 1.10

← Older revision		Revision as of 16:11, 29 January 2012
Line 1:		Line 1:
	~~{{DevFeature1.9}}~~
	~~This page is entirely base on the 1.9 macros, they are very close to the 1.8 macros, but no attempt has been done to document the difference~~

	== Flag Management ==		== Flag Management ==

Boucman: /* DISABLE_BASE_TRANSITIONS_F TERRAINLIST FLAG */

2010-07-10T17:28:21Z

DISABLE_BASE_TRANSITIONS_F TERRAINLIST FLAG

← Older revision		Revision as of 17:28, 10 July 2010
Line 279:		Line 279:
	'''Flag Management'''		'''Flag Management'''
	will set all <FLAG>-@R* on the TERRAINLIST tiles		will set all <FLAG>-@R* on the TERRAINLIST tiles

			== Track Type macros ==

			These macros handle anything that is layed in a connected way over multiple tiles (typically bridges and tiles)

			=== the TRACK macro ===

			'''TRACK_''LF'' <NWSEterrain> <NSterrain> <NESWterrain> <basename'''

			This macro will add the base terrain on the three terrains corresponding to the three directions.This macro will awlays take random variations, and defaults to layer -80 with flag=overlay

			The images used are named
			* base#-ns.png : non-connected on a north-south orientation,
			* base#-nesw.png : non connected on a north-east south-west orientation
			* base#-senw.png : non connected on a south-east north-west orientation
			* base#-<connections> : tile used when the bridge is connected on the corresponding sides (separated by '-', ordered clockwise starting with north)

			'''NOTE:''' the engine will use the straight tile when it doesn't find any fitting tile

			'''NOTE:''' if some connection tiles don't seem to be used properly, please post a screenshot from the editor with terrain names enabled and contact boucman

			'''NOTE''' you will notice that there is no builder. Builders are incompatible with bridges (in other word,the IMAGE_SINGLE builder is hardwired)

			=== Transition related macros ===
			Bridges are tricky because you usually don't want the same transitions depending if the bridge ends on a given edge or not.

			The following macros help

			'''TRACK_BORDER_RESTRICTED_''PLF'' <terrain> <adjacent> <IMAGE>'''

			Will match only if terrain is a bridge, on the side matching adjacent, and if the bridge does have a connection or ending on the given side.

			Note that adjacent can be a bridge too, but this macro won't check that adjacent exits on the corresponding side

			the image will be drawn on the <terrain> hex with the orientation appended to it

			'''TRACK_BORDER_RESTRICTED_RANDOM_''LF''''' similar, with random variations

Boucman: /* Terrain Specific */

2010-07-10T17:05:02Z

Terrain Specific

← Older revision		Revision as of 17:05, 10 July 2010
Line 279:		Line 279:
	'''Flag Management'''		'''Flag Management'''
	will set all <FLAG>-@R* on the TERRAINLIST tiles		will set all <FLAG>-@R* on the TERRAINLIST tiles

	~~== Terrain Specific ==~~

Boucman: /* Terrain Specific */

2010-07-10T17:04:44Z

Terrain Specific

← Older revision		Revision as of 17:04, 10 July 2010
Line 281:		Line 281:

	== Terrain Specific ==		== Terrain Specific ==
	~~=== SIMPLE_FOREST_TERRAIN TERRAINLIST ADJACENT IMAGESTEM ===~~

	~~will use an image IMAGESTEM-small# when next to adjacent and IMAGESTEM# anywhere else~~

	~~''' Images Used '''~~
	* IMAGESTEM-small
	* IMAGESTEM-small2
	* IMAGESTEM-small3
	* IMAGESTEM-small4
	* IMAGESTEM-small5
	* IMAGESTEM-small6
	* IMAGESTEM-small7
	* IMAGESTEM-small8
	* IMAGESTEM-small9
	* IMAGESTEM
	* IMAGESTEM2
	* IMAGESTEM3
	* IMAGESTEM4
	* IMAGESTEM5
	* IMAGESTEM6
	* IMAGESTEM7
	* IMAGESTEM8
	* IMAGESTEM9


	~~''' Parameters '''~~
	* '''ADJACENT''': regexp of terrains that will use -small images

	~~''' Flage management '''~~
	~~this is technically an overlay. It is drawn on layer 0 with other overlays and test/set the overlay flag~~

Boucman: /* Flag Management */

2010-06-24T14:24:30Z

Flag Management

← Older revision		Revision as of 14:24, 24 June 2010
Line 8:		Line 8:
	* '''village''': is set when a village is added on a tile.		* '''village''': is set when a village is added on a tile.
	* '''transition-@R*''': is set on a tile which has a transition on it's corresponding side set (i.e if there is a transition with the tile at its north, transition-n will be set) possible values: ''n,ne,nw,s,se,sw'' Also not that the macros handl it in a reciprocal way. in other word if a tile has transition-n set, it's northern neighbour should have transition-s set		* '''transition-@R*''': is set on a tile which has a transition on it's corresponding side set (i.e if there is a transition with the tile at its north, transition-n will be set) possible values: ''n,ne,nw,s,se,sw'' Also not that the macros handl it in a reciprocal way. in other word if a tile has transition-n set, it's northern neighbour should have transition-s set
	* '''overlay-@R*''' : used for bridges, the bridge on this tile. The bridge "actually has" an "exit direction" in the @R direction indicated.		* '''overlay-connect-@R*''' : used for bridges, the bridge on this tile. The bridge "actually has" an "exit direction" in the @R direction indicated.
	* '''overlay-away-@R*''' : used for bridges, the bridge does NOT have an exit on the given direction, but would be expected to...		* '''overlay-away-@R*''' : used for bridges, the bridge does NOT have an exit on the given direction, but would be expected to...

Boucman: /* Flag Management */

2010-06-18T17:50:01Z

Flag Management

← Older revision		Revision as of 17:50, 18 June 2010
Line 8:		Line 8:
	* '''village''': is set when a village is added on a tile.		* '''village''': is set when a village is added on a tile.
	* '''transition-@R*''': is set on a tile which has a transition on it's corresponding side set (i.e if there is a transition with the tile at its north, transition-n will be set) possible values: ''n,ne,nw,s,se,sw'' Also not that the macros handl it in a reciprocal way. in other word if a tile has transition-n set, it's northern neighbour should have transition-s set		* '''transition-@R*''': is set on a tile which has a transition on it's corresponding side set (i.e if there is a transition with the tile at its north, transition-n will be set) possible values: ''n,ne,nw,s,se,sw'' Also not that the macros handl it in a reciprocal way. in other word if a tile has transition-n set, it's northern neighbour should have transition-s set
	* '''~~angle_~~@R*''' : used for bridges, the bridge on this tile. The bridge "actually has" an "exit direction" in the @R direction indicated.		* '''overlay-@R*''' : used for bridges, the bridge on this tile. The bridge "actually has" an "exit direction" in the @R direction indicated.
	* '''~~angleaway_~~@R*''' : used for bridges, the bridge does NOT have an exit on the given direction, but would be expected to...		* '''overlay-away-@R*''' : used for bridges, the bridge does NOT have an exit on the given direction, but would be expected to...


	'''A note about ''~~angle_~~'' and ''~~angleaway_~~'' flags '''		'''A note about ''overlay-@R'' and ''overlay-away-@R'' flags '''

	Suppose we have a ''n->s'' bridge hex who's ''ne'' neighbour is a ''ne->sw'' bridge. This mean that the ''n->s'' is actually a turn in the bridge that should use a graphic depicting a ''s->ne'' corner.		Suppose we have a ''n->s'' bridge hex who's ''ne'' neighbour is a ''ne->sw'' bridge. This mean that the ''n->s'' is actually a turn in the bridge that should use a graphic depicting a ''s->ne'' corner.

	In that case the tile will have ''~~angle_s~~'' and ''~~angle_ne~~'' set (the directions where the bridge actually exits) and ''~~angleaway_n~~'' (the direction where the bridge would exit according to terrain codes, but doesnt because of overall layout)		In that case the tile will have ''overlay-s'' and ''overlay-ne'' set (the directions where the bridge actually exits) and ''overlay-away-n'' (the direction where the bridge would exit according to terrain codes, but doesnt because of overall layout)

	== Layer Management ==		== Layer Management ==

Boucman: /* Image Names */

2010-06-18T15:22:45Z

Image Names

← Older revision		Revision as of 15:22, 18 June 2010
Line 254:		Line 254:
	However, unlike all previous type of macros, they are related to a ''side'' instead of the whole hex. Thus the following rules		However, unlike all previous type of macros, they are related to a ''side'' instead of the whole hex. Thus the following rules

	* There are no ROTATION macros. Since they are always side related~~, they are always transition like~~		* There are no ROTATION macros. Since they are always side related.
	* All images are named as if they were ROTATION macros (since they are ~~painting on~~ a side		* All images are named as if they were ROTATION macros since they are all side related
			* There is no SINGLE variation since it doesn't make sense to have it (a side is always relative to two hex)
	* The flags are set and tested on a side related basis. i.e there can be more than one transition per tile, if they don't cover the same direction		* The flags are set and tested on a side related basis. i.e there can be more than one transition per tile, if they don't cover the same direction
	* the non-RESTRICTED variations don't exist, they don't really make sense
	* for RESTRICTED2 and RESTRICTED3, we only check for neighbouring hex of the ADJACENT type. This makes more sense for borders		* for RESTRICTED2 and RESTRICTED3, we only check for neighbouring hex of the ADJACENT type. This makes more sense for borders
	* the COMPLETE variant looks as follows		* the COMPLETE variant looks as follows
Line 267:		Line 267:
	{BORDER_RESTRICTED_RANDOM_LFB ({TERRAIN}) ({ADJACENT}) {LAYER} {FLAG} {BUILDER} {IMAGESTEM}}		{BORDER_RESTRICTED_RANDOM_LFB ({TERRAIN}) ({ADJACENT}) {LAYER} {FLAG} {BUILDER} {IMAGESTEM}}
	{BORDER_RESTRICTED_RANDOM_LFB ({TERRAIN}) ({ADJACENT}) {LAYER} {FLAG} {BUILDER} {IMAGESTEM}}		{BORDER_RESTRICTED_RANDOM_LFB ({TERRAIN}) ({ADJACENT}) {LAYER} {FLAG} {BUILDER} {IMAGESTEM}}
	~~{BORDER_SINGLE_RANDOM_LFB ({TERRAIN}) {LAYER} {FLAG} {BUILDER} {IMAGESTEM}}~~
	#enddef		#enddef