Terrain macros overhaul
Moderator: Forum Moderators
Terrain macros overhaul
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.
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!
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
Re: Terrain macros overhaul
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.
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.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.
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
-> What i might be working on
Attempting Lucidity
-
- Retired Terrain Art Director
- Posts: 1113
- Joined: November 29th, 2003, 11:40 pm
- Location: Norway
Re: Terrain macros overhaul
Indeed, this is a very good initiative.Eleazar wrote:But in general the whole thing is sorely lacking in mere-mortal comprehensibility.
Re: Terrain macros overhaul
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).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.
Aurë entuluva!
Re: Terrain macros overhaul
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. 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:
into
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.
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. 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}
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}
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.
Re: Terrain macros overhaul
I'd like to take this moment to applaud these efforts. Hear, hear!
Play Frogatto & Friends - a finished, open-source adventure game!
Re: Terrain macros overhaul
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: Because this can be confusing to visualize, here's a diagram of the situation with 2- and 3-way mixed keep-castle walls.
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
My suggestion would be: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
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\_/
\_/
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.
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 main thing was that it let me make the castle macros a lot easier to define. Currently It's changed:intoCode: 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}
The convex and concave parts are just separate because keep-castle uses the same concave graphics as keep-everything else.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}
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).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
About the other suggestions from the wiki:
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.Move the macros to data/core/terrain-graphics/macros, and modify data/core/_main.cfg slightly to load all macros in this directory first.
Generalized random macro: good idea for some common cases (base tile/ simple overlays).
Aurë entuluva!
Re: Terrain macros overhaul
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?
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.
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).
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.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.
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.
Re: Terrain macros overhaul
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: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 agree in principle. The reason I sugested it the way I did is because of implementation. The order of the directions is defined inmesilliac 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?
Code: Select all
rotations=n,ne,se,s,sw,nw
[image]
layer={LAYER}
base={BASE}
name={IMAGE}-@R0-@R1
[/image]
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!
Re: Terrain macros overhaul
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.mog wrote:I agree in principle. The reason I sugested it the way I did is because of implementation. The order of the directions is defined inmesilliac 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?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.Code: Select all
rotations=n,ne,se,s,sw,nw [image] layer={LAYER} base={BASE} name={IMAGE}-@R0-@R1 [/image]
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 ... i.e.
Code: Select all
map="
3
, 2
1"
Re: Terrain macros overhaul
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.
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.
Re: Terrain macros overhaul
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).
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.
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
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.
Re: Terrain macros overhaul
That suggestion might work. There are some cases where I'd like to have a more general solution, but you can't have everything.
I will post a complete proposal here when I'm (reasonably) done.
Please don't. Or if you do, create a branch. Otherwise you'll conflict with the changes in my local copy.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.
I will post a complete proposal here when I'm (reasonably) done.
Aurë entuluva!
Re: Terrain macros overhaul
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: 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.
Which are contained here: 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.
Re: Terrain macros overhaul
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...
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!