Custom Terrain Tutorial planning

The place to post your WML questions and answers.

Moderators: Forum Moderators, Developers

Forum rules
  • Please use [code] BBCode tags in your posts for embedding WML snippets.
  • To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
User avatar
Alarantalara
Art Contributor
Posts: 784
Joined: April 23rd, 2010, 8:17 pm
Location: Canada

Re: Custom Terrain Tutorial planning

Post by Alarantalara »

Image path functions are supported (mainline uses recolouring and I've used CROP). I suspect that all paths may be relative to image/terrain though, so you have to change the blit paths too.

User avatar
doofus-01
Art Director
Posts: 3908
Joined: January 6th, 2008, 9:27 pm
Location: USA

Re: Custom Terrain Tutorial planning

Post by doofus-01 »

Alarantalara wrote:Image path functions are supported (mainline uses recolouring and I've used CROP). I suspect that all paths may be relative to image/terrain though, so you have to change the blit paths too.
I think it's that (at least most) mainline macros use "IMAGESTEMs" that truncate the image paths, so folder/image.png is passed to the macro as folder/image, and sticking ".png~IPFs" on the end of an IMAGESTEM gives folder/image.png~IPF().png. Combine that with potential confusion from multiple parentheses and quotes in macro calls, and it's not surprising tekelili gets strange results.

There are a couple terrains in Archaic Resources that use copies of mainline macros that allow an IPF argument, and everything worked fine. So [terrain_graphics] can handle IPFs just fine, like Alarantalara said. I don't know about the "symbol_image", but how important is that, really?
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects

User avatar
Alarantalara
Art Contributor
Posts: 784
Joined: April 23rd, 2010, 8:17 pm
Location: Canada

Re: Custom Terrain Tutorial planning

Post by Alarantalara »

Right, if you wanted to use image path functions with a macro you'd have to use the builder versions of them.

Something like (not tested)

Code: Select all

#define BALE_BUILDER IMAGESTEM POSTFIX
{IMAGESTEM}{POSTFIX}.png~BLIT(items/straw-bale2.png~CROP(24,15,48,57))~BLIT(items/straw-bale1.png~CROP(0,9,72,63))#enddef

{OVERLAY_B *^Vxsa BALE_BUILDER (../misc/blank-hex)}

User avatar
tekelili
Posts: 1038
Joined: August 19th, 2009, 9:28 pm

Re: Custom Terrain Tutorial planning

Post by tekelili »

Thank you dofus-01 and Alarantalara, terrain macros are quite complicated to uderstand and you saved me lot of time to understand my problem. I am slowly improving my knowledge about them, but as my main propose trying to create those terrains, was fix this bug; I wonder if Alantalara could give it a try, as he looks have deep understanding about engine layer management :D

Edit: It is off topic, but I also would like remember one of my feature request: Having a emebellishment with misc/blank.png as image displayed, would give coders an usefull tool to "mark" terrains for filter proposes without "change" them.
Last edited by tekelili on July 19th, 2015, 5:06 pm, edited 1 time in total.
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II

User avatar
Alarantalara
Art Contributor
Posts: 784
Joined: April 23rd, 2010, 8:17 pm
Location: Canada

Macros (incomplete)

Post by Alarantalara »

There are at least two sets of macros defined in core/terrain-graphics.

The first set attempts to be very generic and covers many situations that are unlikely to come up. As a result they are defined as macros that call macros that call macros that call... You can even define your own macros as pass them as parameters to add even more complexity.

The second set mostly starts with the prefix NEW:. These macros are generally single layer macros that neither take nor call additional macros and are thus simpler and have fewer parameters. As a result, however, they don't address common desires like terrain that mostly uses image A with only a few using B, or drawing a base terrain that has 2 or more layers like the swamp.

Both sets do not expose the full power of the terrain_graphics tag and should be primarily regarded as a way to reduce the amount of typing you need to do if you're making a terrain like one in core.

The first set includes the following macros that you might use and a large pile they call that you should ignore:
  • TERRAIN_BASE - use for base terrains. You need this or a similar macro (like NEW:BASE) for basically every terrain that is not an overlay. It sets the base flag and draws at layer -1000 by default.
  • OVERLAY - use for simple overlay terrains. It sets the overlay flag and draws at layer 0 by default.
  • TRANSITION_COMPLETE - Covers every possible transition between a tile and any number of adjacent tiles that match a second type. Should almost always be called with the layer parameter, see the discussion of transitions.
  • WALL_TRANSITION
  • WALL_TRANSITION2
  • WALL_TRANSITION3
Others that are more specialized:
  • OVERLAY_RESTRICTED - An overlay that is drawn only when it has a neighbour of a second terrain type.
  • OVERLAY_ROTATION_RESTRICTED - As overlay restricted but with a different image depending on which side the neighbour is on.
  • OVERLAY_RESTRICTED2 - An overlay that is drawn only when there are two neighbours of a second terrain type.
  • OVERLAY_RESTRICTED3 - An overlay that is drawn only when there are three neighbours of a second terrain type.
  • OVERLAY_COMPLETE - An overlay that has alternate images for 0, 1, 2, and 3 neighbours of a second terrain type. The base image name from the macro is used for 0, and small + the sides the neighbouring terrain is on is appended for 1, 2 and 3 neighbours.
All of these take the PLFB optional parameters in any combination. The RANDOM variant is also available for many of these.

The second set includes the following macros you may want to use:
  • NEW:BASE - alternative for base terrains. Always at layer -1000 and includes the base flag. Behaves much like TERRAIN_BASE_RANDOM.
  • NEW:FOREST - Draws forests in core. Essentially an overlay macro that takes a list of terrains for which an alternative image set should be used when the second list is adjacent. The second image set has a -small suffix added to the name of the first. This gives it the same behaviour as the pair of macros OVERLAY_RESTRICTED followed by OVERLAY from the first set.
  • NEW:WALL
  • NEW:WALL2
  • NEW:WALL2_P
  • NEW:VILLAGE - Another overlay macro that draws at layer 0. This one only supports 4 variations and uses the village flag instead of overlay. The change of swamp to not use overlay in 1.9.9 means this macro could safely be replaced with OVERLAY from the first set everywhere.
  • NEW:VILLAGE_A3 - As above but with a three frame animation.
  • NEW:VILLAGE_A4 - As above but with a four frame animation.
It also includes some very specialized macros you're unlikely to use.
  • NEW:WAVES
  • NEW:BEACH
  • NEW:FENCE - The core fence macro.
Other than as explicitly mentioned, none of the macros includes any of the optional parameter variants.

Some special macros that don't fit neatly into the sets above.
  • EDITOR_OVERLAY - A macro that draws an overlay image only when using the editor. Use for terrain overlays that modify the behaviour of terrain but don't have visible side-effects like the castle overlay in core.
TODO: finish descriptions of above, cover mountains, the disabling macros, bridges and tracks

User avatar
Alarantalara
Art Contributor
Posts: 784
Joined: April 23rd, 2010, 8:17 pm
Location: Canada

Re: Custom Terrain Tutorial planning

Post by Alarantalara »

tekelili wrote:Edit: It is off topic, but I also would like remember one of my feature request: Having a emebellishment with misc/blank.png as image displayed, would give coders an usefull tool to "mark" terrains for filter proposes without "change" them.
It's an interesting idea, but I suspect that anyone who would understand what such a terrain in the editor is for would also be capable of making it. It's also probably not the best solution to your problem—it can't be used to mark spaces on top of forests, for example. Instead, I'd suggest looking into the find_in key for the standard location filter. Essentially it lets you use the result of a store_location call as a restriction for any SLF. You can even add and remove items since it's just a normal WML array.

If you did still want the overlay option, just define an overlay terrain that aliases to base and use the EDITOR_OVERLAY macro to give it an appearance in the editor. Don't bother using misc/blank.png, you'll just make the map take longer to load.

User avatar
tekelili
Posts: 1038
Joined: August 19th, 2009, 9:28 pm

Re: Custom Terrain Tutorial planning

Post by tekelili »

Alarantalara wrote:
tekelili wrote:Edit: It is off topic, but I also would like remember one of my feature request: Having a emebellishment with misc/blank.png as image displayed, would give coders an usefull tool to "mark" terrains for filter proposes without "change" them.
It's an interesting idea, but I suspect that anyone who would understand what such a terrain in the editor is for would also be capable of making it. It's also probably not the best solution to your problem—it can't be used to mark spaces on top of forests, for example. Instead, I'd suggest looking into the find_in key for the standard location filter. Essentially it lets you use the result of a store_location call as a restriction for any SLF. You can even add and remove items since it's just a normal WML array.

If you did still want the overlay option, just define an overlay terrain that aliases to base and use the EDITOR_OVERLAY macro to give it an appearance in the editor. Don't bother using misc/blank.png, you'll just make the map take longer to load.
I could easyly create such terrain, but my add on would lose compatibility in multiplayer. I suggested it as looked very cheap resource wise add it to mainline. note that map editor is not only way to create maps, when using [geneartor] you can not store locations to use find_in=

I had several situations were my code becomed longer, dirtier and more confusing, than if i could have used such "null embellishment". To mention one: you want some zones become grassland at [generator] level, but you want mark zones with diferent temperatures to change some of them at [scenario] level with a [terrain] tag.

It is not a universal solution, you are right in it wouldnt work for forest... but as I said, it look cheap for the engine allow such shortcut when coder need it.
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II

Post Reply