Custom Terrain Tutorial planning
Moderator: Forum Moderators
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.
- Alarantalara
- Art Contributor
- Posts: 786
- Joined: April 23rd, 2010, 8:17 pm
- Location: Canada
Re: Custom Terrain Tutorial planning
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.
Re: Custom Terrain Tutorial planning
I think it's that (at least most) mainline macros use "IMAGESTEMs" that truncate the image paths, soAlarantalara 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.
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
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
- Alarantalara
- Art Contributor
- Posts: 786
- Joined: April 23rd, 2010, 8:17 pm
- Location: Canada
Re: Custom Terrain Tutorial planning
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)
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)}
Re: Custom Terrain Tutorial planning
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
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.
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
World Conquest II
- Alarantalara
- Art Contributor
- Posts: 786
- Joined: April 23rd, 2010, 8:17 pm
- Location: Canada
Macros (incomplete)
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:
The second set includes the following macros you may want to use:
Some special macros that don't fit neatly into the sets above.
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
- 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.
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.
- NEW:WAVES
- NEW:BEACH
- NEW:FENCE - The core fence macro.
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.
- Alarantalara
- Art Contributor
- Posts: 786
- Joined: April 23rd, 2010, 8:17 pm
- Location: Canada
Re: Custom Terrain Tutorial planning
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.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.
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.
Re: Custom Terrain Tutorial planning
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=Alarantalara wrote: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.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.
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 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
World Conquest II