Terrain macros overhaul

Production of artwork for the game by regular contributors takes place here.

Moderator: Forum Moderators

mog
Inactive Developer
Posts: 190
Joined: March 16th, 2006, 2:07 pm
Location: Germany
Contact:

Terrain macros overhaul

Post by mog »

I'm planning to do a major reorganisation of the terrain macros. I'd like to make them more consistent and remove a lot of the duplicated functionality we currently have (and if I'm doing that I can as well document the system, possibly making it comprehendable for mere mortals).

I made a list on the wiki with issues and possible solutions I found:
http://www.wesnoth.org/wiki/User:Mog/TerrainReorg

Feel free to add anything that made you slam your head on the keyboard when dealing with terrain wml.
Aurë entuluva!
User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Re: Terrain macros overhaul

Post by Eleazar »

mog wrote:I'm planning to do a major reorganisation of the terrain macros. I'd like to make them more consistent and remove a lot of the duplicated functionality we currently have (and if I'm doing that I can as well document the system, possibly making it comprehendable for mere mortals).

I made a list on the wiki with issues and possible solutions I found:
http://www.wesnoth.org/wiki/User:Mog/TerrainReorg

Feel free to add anything that made you slam your head on the keyboard when dealing with terrain wml.
mog on that wiki page wrote: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.
IIRC correctly these are two functionally distinct kinds of rotations. Castles, Chasms, and Cave walls have rotations named according to the corners, because the graphics are placed according to the corners.

But in general the whole thing is sorely lacking in mere-mortal comprehensibility.
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
freim
Retired Terrain Art Director
Posts: 1113
Joined: November 29th, 2003, 11:40 pm
Location: Norway

Re: Terrain macros overhaul

Post by freim »

Eleazar wrote:But in general the whole thing is sorely lacking in mere-mortal comprehensibility.
Indeed, this is a very good initiative.
mog
Inactive Developer
Posts: 190
Joined: March 16th, 2006, 2:07 pm
Location: Germany
Contact:

Re: Terrain macros overhaul

Post by mog »

Eleazar wrote: IIRC correctly these are two functionally distinct kinds of rotations. Castles, Chasms, and Cave walls have rotations named according to the corners, because the graphics are placed according to the corners.
I know, but a corner can as well be sprecified by the two edges. The current way it works gives me headaches every time I have to deal with both types at the same time. Especially if you have 3-terrain transitions (where we could get rid of the -cw and -ccw suffixes we currently use).
Aurë entuluva!
mesilliac
Developer
Posts: 81
Joined: November 18th, 2005, 8:09 am
Location: New Zealand

Re: Terrain macros overhaul

Post by mesilliac »

Making the macros and images more consistent and easy to use would be a very good thing.

It was giving me a headache too, I actually already messed around with castle image naming and castle macros on my local copy.

Because this can be confusing to visualize, here's a diagram of the situation with 2- and 3-way mixed keep-castle walls.
ex.png
ex.png (21.59 KiB) Viewed 8412 times
The current naming scheme for this is quite confusing :?. My local modifications aren't much better. My version curently would be: A) keep-castle-ccw-w B) keep-castle-cw-ne C) keep-concave-ne D) keep-castle-convex-se
The main thing was that it let me make the castle macros a lot easier to define. Currently It's changed:

Code: Select all

 # Elven castle
{TERRAIN_ADJACENT_CORNER       Cv               (!,Cv,Kv)         (!,Cv,Kv)        52,76 castle/elven/convex}
{TERRAIN_ADJACENT_CORNER       (!,Cv,Kv)        Cv                Cv               56,68 castle/elven/concave}
{TERRAIN_ADJACENT_CORNER       Kv               Cv                Cv               54,72 castle/elven/keep-inside}
{TERRAIN_ADJACENT_CORNER       Kv               (!,Cv,Kv)         (!,Cv,Kv)        52,76 castle/elven/keep-wall}
{TERRAIN_ADJACENT_CORNER       Kv               (!,Cv,Kv)         Cv               52,72 castle/elven/keep-wall-0}
{TERRAIN_ADJACENT_CORNER       Kv               Cv                (!,Cv,Kv)        56,76 castle/elven/keep-wall-1}
{TERRAIN_ADJACENT_CORNER       Kv               Kv                (!,Kv)           56,76 castle/elven/keep-keep}
into

Code: Select all

 # Elven castle
{TERRAIN_FENCE               Cv    (!,Cv,Kv)        castle/elven/castle}
{TERRAIN_FENCE_CONVEX        Kv    (!,Cv,Kv)        castle/elven/keep-convex}
{TERRAIN_FENCE_CONVEX        Kv    Cv               castle/elven/keep-castle-convex}
{TERRAIN_FENCE_CONCAVE       Kv    (!,Kv)           castle/elven/keep-concave}
{TERRAIN_FENCE_ADJACENT      Kv    Cv               castle/elven/keep-castle}
The convex and concave parts are just separate because keep-castle uses the same concave graphics as keep-everything else.

mog, would your naming scheme be something like: A) keep-castle-nw-sw B) keep-castle-n-ne C) keep-concave-n-ne D) keep-castle-convex-se-s ?

To get rid of concave/convex as well all I can think of is: A) keep-nw-castle-sw B) keep-n-castle-ne C) keep-n-ne (or keep-n-ne-castle) D) keep-castle-se-s

I guess the second one looks sensible to me. If one of these is what you were thinking of, I could change the naming scheme in the macros I have so far and commit them. (just the macros I mean, not change anything to use them yet)

The other thing I was planning to do, is create simple one-line macros for main terrain types. i.e. base terrain, simple overlay, castle-type walls, cliff/bridge-type directional overlays.

I've been jotting up ideas as I come across them on http://www.wesnoth.org/wiki/User:Mesilliac


Heh, sorry for the enormous post :?. I've been thinking about cleaning up terrain WML quite a bit lately.
User avatar
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Re: Terrain macros overhaul

Post by Jetrel »

:eng: I'd like to take this moment to applaud these efforts. Hear, hear!
Play Frogatto & Friends - a finished, open-source adventure game!
mog
Inactive Developer
Posts: 190
Joined: March 16th, 2006, 2:07 pm
Location: Germany
Contact:

Re: Terrain macros overhaul

Post by mog »

mesilliac wrote: Because this can be confusing to visualize, here's a diagram of the situation with 2- and 3-way mixed keep-castle walls.
Image
The current naming scheme for this is quite confusing :?. My local modifications aren't much better. My version curently would be: A) keep-castle-ccw-w B) keep-castle-cw-ne C) keep-concave-ne D) keep-castle-convex-se
That doesn't look very clear to me. Espcially the first two, as they basically use the unspecified tile as rotation reference (i.e. the west transition is the transition at the west of the "-" tile).
mesilliac wrote: mog, would your naming scheme be something like: A) keep-castle-nw-sw B) keep-castle-n-ne C) keep-concave-n-ne D) keep-castle-convex-se-s ?

To get rid of concave/convex as well all I can think of is: A) keep-nw-castle-sw B) keep-n-castle-ne C) keep-n-ne (or keep-n-ne-castle) D) keep-castle-se-s
My suggestion would be:
A) keep-castle-ccw-se-s B) keep-castle-cw-se-s C) keep-concave-n-ne D) keep-castle-convex-se-s

I thought about getting rid of the cw/ccw parts but that would require another complete set of macros. And it's much easier for a human to notice the cw/ccw than the order of the directions (e.g. ne-n/n-ne). For the same reason I want to keep the convex/concave suffixes.

To generalize the example above:

Code: Select all

._
/2\_
\_/3\
/1\_/
\_/
Filename would be something like: part1-part2-part3-cw/ccw-r0-r1
The first tile should be the one that defines the direction (i.e. the r0-r1 part).
The order of 1/2/3 around the tile corner should match the cw/ccw suffix.
So in the example above, both part1-part2-part3-cw-r0-r1 and part1-part3-part2-ccw-r0-r1 would be possible (though you should be consistant).
If one of the tiles is a wildcard, use part1-part2-cw-r0-r1 and part1-part3-ccw-r0-r1

Convex/Concave transitions would remain as they are (except for the change of the direction suffixes).

Hmm... I don't know if that was really clear.
mesilliac wrote: The main thing was that it let me make the castle macros a lot easier to define. Currently It's changed:

Code: Select all

 # Elven castle
{TERRAIN_ADJACENT_CORNER       Cv               (!,Cv,Kv)         (!,Cv,Kv)        52,76 castle/elven/convex}
{TERRAIN_ADJACENT_CORNER       (!,Cv,Kv)        Cv                Cv               56,68 castle/elven/concave}
{TERRAIN_ADJACENT_CORNER       Kv               Cv                Cv               54,72 castle/elven/keep-inside}
{TERRAIN_ADJACENT_CORNER       Kv               (!,Cv,Kv)         (!,Cv,Kv)        52,76 castle/elven/keep-wall}
{TERRAIN_ADJACENT_CORNER       Kv               (!,Cv,Kv)         Cv               52,72 castle/elven/keep-wall-0}
{TERRAIN_ADJACENT_CORNER       Kv               Cv                (!,Cv,Kv)        56,76 castle/elven/keep-wall-1}
{TERRAIN_ADJACENT_CORNER       Kv               Kv                (!,Kv)           56,76 castle/elven/keep-keep}
into

Code: Select all

 # Elven castle
{TERRAIN_FENCE               Cv    (!,Cv,Kv)        castle/elven/castle}
{TERRAIN_FENCE_CONVEX        Kv    (!,Cv,Kv)        castle/elven/keep-convex}
{TERRAIN_FENCE_CONVEX        Kv    Cv               castle/elven/keep-castle-convex}
{TERRAIN_FENCE_CONCAVE       Kv    (!,Kv)           castle/elven/keep-concave}
{TERRAIN_FENCE_ADJACENT      Kv    Cv               castle/elven/keep-castle}
The convex and concave parts are just separate because keep-castle uses the same concave graphics as keep-everything else.
Having such convenience macros are certainly possible, even with the current macros. Though I first want to make sure the general macros are well designed.

mesilliac wrote: The other thing I was planning to do, is create simple one-line macros for main terrain types. i.e. base terrain, simple overlay, castle-type walls, cliff/bridge-type directional overlays.

I've been jotting up ideas as I come across them on http://www.wesnoth.org/wiki/User:Mesilliac
Those simple macros might be a good idea, though I'll have to check if there are any major constraints on the ordering of rules (there shouldn't be).

About the other suggestions from the wiki:
Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.
I will definately clean up the number of files in t-g/. I'm not sure about the rest, but I will keep it in mind.

Generalized random macro: good idea for some common cases (base tile/ simple overlays).
Aurë entuluva!
mesilliac
Developer
Posts: 81
Joined: November 18th, 2005, 8:09 am
Location: New Zealand

Re: Terrain macros overhaul

Post by mesilliac »

Urr, this is definitely giving me a headache already :).

I do like the concave/convex, and don't find the cw/ccw bad. Ordering around the undefined "-" tile makes sense to me for 2-terrain corner transitions, as this is the tile that defines cw or ccw (similar to how the undefined tile defines the "concave" corner). But it doesn't extend to 3-way corner transitions.

So the only problem I have with your suggestion is A) keep-castle-ccw-se-s. It looks confusing that se-s is not in ccw order. AFAICT there would be nothing more complicated with keep-castle-ccw-s-se and that makes much more sense to me.

I think that's consistent with your generalised explaination too. So how is A) keep-castle-ccw-s-se B) keep-castle-cw-se-s C) D) as you said?
mog wrote: Those simple macros might be a good idea, though I'll have to check if there are any major constraints on the ordering of rules (there shouldn't be).
mog wrote: I will definately clean up the number of files in t-g/. I'm not sure about the rest, but I will keep it in mind.
My main motivation is to make it easier to add custom terrains. I've been playing around with defining things in different orders and haven't had many problems. What I was aiming for was that the main terrain macros would get loaded, then any custom terrain cfgs in a scenario/campaign would get loaded, then the main terrain definitions would get loaded (_final.cfg), in this order. This way custom terrains can use all the main terrain macros, and a mainline terrain can be copied easily as a base for a new terrain. But also, if they are not disabled explicitly (for example with the {DISABLE_TRANSITIONS} macro), mainline terrains will draw transitions as they would normally to this custom terrain.

To clarify: as I understand it the ordering is important when disabling or modifying other terrains. Hence my preferred ordering of main macros -> custom macros + terrains -> main terrains

Also it's not the number of files in t-g that bug me, it's the length and complexity of _final.cfg :). It's almost impossible to understand if you just want to add your own custom terrain to a campaign and are looking for something to base it on.
mog
Inactive Developer
Posts: 190
Joined: March 16th, 2006, 2:07 pm
Location: Germany
Contact:

Re: Terrain macros overhaul

Post by mog »

mesilliac wrote:I do like the concave/convex, and don't find the cw/ccw bad. Ordering around the undefined "-" tile makes sense to me for 2-terrain corner transitions, as this is the tile that defines cw or ccw (similar to how the undefined tile defines the "concave" corner). But it doesn't extend to 3-way corner transitions.
I see the 2-terrain corner transition as a special case of the 3-terrain transition, so it should use the same rules (i.e. the first tile is the center of the rotation). The concave transition is a special case, as one can't distinguish the two "first tiles", but I'd prefer one special case to two.
mesilliac wrote: So the only problem I have with your suggestion is A) keep-castle-ccw-se-s. It looks confusing that se-s is not in ccw order. AFAICT there would be nothing more complicated with keep-castle-ccw-s-se and that makes much more sense to me.

I think that's consistent with your generalised explaination too. So how is A) keep-castle-ccw-s-se B) keep-castle-cw-se-s C) D) as you said?
I agree in principle. The reason I sugested it the way I did is because of implementation. The order of the directions is defined in

Code: Select all

        rotations=n,ne,se,s,sw,nw
 
        [image]
            layer={LAYER}
            base={BASE}
            name={IMAGE}-@R0-@R1
        [/image]
So I'd have to define (and use) new macros for the ccw case. It's possible of course, but the gain is IMHO negligible.
mesilliac wrote: My main motivation is to make it easier to add custom terrains. I've been playing around with defining things in different orders and haven't had many problems. What I was aiming for was that the main terrain macros would get loaded, then any custom terrain cfgs in a scenario/campaign would get loaded, then the main terrain definitions would get loaded (_final.cfg), in this order. This way custom terrains can use all the main terrain macros, and a mainline terrain can be copied easily as a base for a new terrain. But also, if they are not disabled explicitly (for example with the {DISABLE_TRANSITIONS} macro), mainline terrains will draw transitions as they would normally to this custom terrain.

To clarify: as I understand it the ordering is important when disabling or modifying other terrains. Hence my preferred ordering of main macros -> custom macros + terrains -> main terrains

Also it's not the number of files in t-g that bug me, it's the length and complexity of _final.cfg :). It's almost impossible to understand if you just want to add your own custom terrain to a campaign and are looking for something to base it on.

Okay, that makes sense.
Aurë entuluva!
mesilliac
Developer
Posts: 81
Joined: November 18th, 2005, 8:09 am
Location: New Zealand

Re: Terrain macros overhaul

Post by mesilliac »

mog wrote:
mesilliac wrote: So the only problem I have with your suggestion is A) keep-castle-ccw-se-s. It looks confusing that se-s is not in ccw order. AFAICT there would be nothing more complicated with keep-castle-ccw-s-se and that makes much more sense to me.

I think that's consistent with your generalised explaination too. So how is A) keep-castle-ccw-s-se B) keep-castle-cw-se-s C) D) as you said?
I agree in principle. The reason I sugested it the way I did is because of implementation. The order of the directions is defined in

Code: Select all

        rotations=n,ne,se,s,sw,nw
 
        [image]
            layer={LAYER}
            base={BASE}
            name={IMAGE}-@R0-@R1
        [/image]
So I'd have to define (and use) new macros for the ccw case. It's possible of course, but the gain is IMHO negligible.
My issue is that IMO something like "keep-castle-ccw-se-s" is much more confusing than "keep-castle-ccw-se", even if the rotation names mean something different to what is usual.

I think defining the base macros twice is preferable to having a potentially confusing naming scheme.

In case it's not apparent, I'm proposing that ll do the dirty work on this ;), as I had to make some new corner macros to fix something unrelated anyway.

Tbh, the main thing that gave me headaches originally was simply that the macros are defined with ccw as default :annoyed: ... i.e.

Code: Select all

map="
3
,  2
1"
mesilliac
Developer
Posts: 81
Joined: November 18th, 2005, 8:09 am
Location: New Zealand

Re: Terrain macros overhaul

Post by mesilliac »

Of course the other option is just to name the rotations for corners to something different entirely.

For example top-right, right, bottom-right, bottom-left, left, top-left

Or tr, r, br, bl, l tl.

Or ur, r, dr, dl, l, ul (up/down, left/right)

Or something completely arbitrary.
mesilliac
Developer
Posts: 81
Joined: November 18th, 2005, 8:09 am
Location: New Zealand

Re: Terrain macros overhaul

Post by mesilliac »

After actually putting it into practice, this is what I ended up with for the most generic base macro for corners (pretty much everything else is derived from it).

Code: Select all

#define TERRAIN_CORNER_B_P_F BASE PROB FLAG TERRAIN1 TERRAIN2 TERRAIN3 IMAGESTEM
    [terrain_graphics]
        map="
2
,  3
1"
        [tile]
            pos=1
            type={TERRAIN1}
            no_flag={FLAG}-@R0
            set_flag={FLAG}-@R0
        [/tile]
        [tile]
            pos=2
            type={TERRAIN2}
        [/tile]
        [tile]
            pos=3
            type={TERRAIN3}
        [/tile]
        [image]
            base={BASE}
            name={IMAGESTEM}-@R0
        [/image]
        probability={PROB}
        rotations=ur,r,dr,dl,l,ul
    [/terrain_graphics]
#enddef
I just put base / prob / flag at the start of the macro line because I think it's a little neater to consistently keep the terain / imagestem variables together.

using ur,r,dr etc. does keep two different rotation naming conventions... but they no longer conflict :). I think they should be much easier to work with, once you get used to them.

I'll probably commit this, once I've finished testing it, so you can see how the sub-macros etc. are organised.

Renaming all the images might take a while. Some of the cw / ccw ones are inconsistent.
mog
Inactive Developer
Posts: 190
Joined: March 16th, 2006, 2:07 pm
Location: Germany
Contact:

Re: Terrain macros overhaul

Post by mog »

That suggestion might work. There are some cases where I'd like to have a more general solution, but you can't have everything.
mesilliac wrote:I'll probably commit this, once I've finished testing it, so you can see how the sub-macros etc. are organised.

Renaming all the images might take a while. Some of the cw / ccw ones are inconsistent.
Please don't. Or if you do, create a branch. Otherwise you'll conflict with the changes in my local copy.

I will post a complete proposal here when I'm (reasonably) done.
Aurë entuluva!
mesilliac
Developer
Posts: 81
Joined: November 18th, 2005, 8:09 am
Location: New Zealand

Re: Terrain macros overhaul

Post by mesilliac »

bleh, which is why I wanted to get onto this quicksmart. I want any change to be compatible with my additional corner macros.

Which are contained here:
castles.cfg
(10.5 KiB) Downloaded 619 times
The additional long-winded "static" macro is necessary to fix chasm-mountain layering. I didn't find a way to use the "rotations" shorthand for it, as the point of it is that the "base" coordinates don't get rotated with the rule.
mog
Inactive Developer
Posts: 190
Joined: March 16th, 2006, 2:07 pm
Location: Germany
Contact:

Re: Terrain macros overhaul

Post by mog »

How the time flies...

Well, here is my (mostly implemented) proposal:
http://www.wesnoth.org/wiki/User:Mog/TerrainReorg

I'd be most interested in feedback about the low level macros, but I'll also take suggestions for useful high-level macros.

The transition will be easy (if somewhat time consuming) as long as we only have to deal with the core data. I'm not sure what to do about external campaigns. We can obviously keep the old macros for a few versions (there are no conflicts, I think) and I will talk with esr about some automatic conversion, but that's really only feasible for some basic uses. I think I'll simply hope that no one was insane enough to include complex terrain macros in his campaign...
Aurë entuluva!
Post Reply