TerrainMacrosWML - Revision history

Egallager: additional links

2023-05-07T17:44:26Z

additional links

Pentarctagon at 07:18, 16 May 2020

2020-05-16T07:18:01Z

Iceiceice at 04:36, 7 April 2014

2014-04-07T04:36:26Z

Crendgrim: Cleaning up documentation for 1.10

2012-01-29T16:11:43Z

Cleaning up documentation for 1.10

Boucman: /* DISABLE_BASE_TRANSITIONS_F TERRAINLIST FLAG */

2010-07-10T17:28:21Z

‎DISABLE_BASE_TRANSITIONS_F TERRAINLIST FLAG

Boucman: /* Terrain Specific */

2010-07-10T17:05:02Z

‎Terrain Specific

Boucman: /* Terrain Specific */

2010-07-10T17:04:44Z

‎Terrain Specific

Boucman: /* Flag Management */

2010-06-24T14:24:30Z

‎Flag Management

Boucman: /* Flag Management */

2010-06-18T17:50:01Z

‎Flag Management

Boucman: /* Image Names */

2010-06-18T15:22:45Z

‎Image Names

← 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]]

@@ Line 53: / Line 53: @@
 * '''TERRAIN''' : the type of terrain to put the image on
 * '''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
 * '''FLAG''' : ''only for _F'' A flag to test and set on the tile

← 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]]

← 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 ==

← 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

← 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 ==~~

← 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~~

@@ Line 8: / Line 8: @@
 * '''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
-* '''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...

@@ Line 8: / Line 8: @@
 * '''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
-* '''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.
-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 ==

@@ 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
-* 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
 * 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
 * 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
@@ Line 267: / Line 267: @@
      {BORDER_RESTRICTED_RANDOM_LFB   ({TERRAIN})  ({ADJACENT}) {LAYER} {FLAG} {BUILDER} {IMAGESTEM}}
      {BORDER_RESTRICTED_RANDOM_LFB   ({TERRAIN})  ({ADJACENT}) {LAYER} {FLAG} {BUILDER} {IMAGESTEM}}
   #enddef