Terrain macros overhaul
Moderator: Forum Moderators
Re: Terrain macros overhaul
Looks good, from what I can tell .
A few minor things:
I have some macros to disable corner terrains, but I'll just fit them in after this is mostly in place, if they add anything useful.
I don't particularly like the use of "WALL" to denote corner terrains. Partially because my indoor wall terrain doesn't use the same system, and partially because not all corner terrains are necessarily walls. I've been using "FENCE" as a generic specifier (as corner terrains always enclose an area), but then that's only slightly better in that it doesn't conflict with indoor walls .
For the TRANSITION3_OVERLAY and ADJACENT3_OVERLAY etc. macros you could name them with something like "RESTRICT_ADJACENT" and "RESTRICT" in stead. Especially as I think "adjacent" makes more sense for the first macro which applies to other terrains being adjacent . To clarify: TRANSITION3 could be RESTRICT_ADJACENT3 and ADJACENT3 could be RESTRICT3 etc..
I think I'd also specify DISABLE_TRANSITIONS as DISABLE_BASE_TRANSITIONS just to clarify that it doesn't affect overlays etc..
A few minor things:
I have some macros to disable corner terrains, but I'll just fit them in after this is mostly in place, if they add anything useful.
I don't particularly like the use of "WALL" to denote corner terrains. Partially because my indoor wall terrain doesn't use the same system, and partially because not all corner terrains are necessarily walls. I've been using "FENCE" as a generic specifier (as corner terrains always enclose an area), but then that's only slightly better in that it doesn't conflict with indoor walls .
For the TRANSITION3_OVERLAY and ADJACENT3_OVERLAY etc. macros you could name them with something like "RESTRICT_ADJACENT" and "RESTRICT" in stead. Especially as I think "adjacent" makes more sense for the first macro which applies to other terrains being adjacent . To clarify: TRANSITION3 could be RESTRICT_ADJACENT3 and ADJACENT3 could be RESTRICT3 etc..
I think I'd also specify DISABLE_TRANSITIONS as DISABLE_BASE_TRANSITIONS just to clarify that it doesn't affect overlays etc..
Re: Terrain macros overhaul
Having a way to disable corner transitions is a good idea. I'll add a macro for that. I'll also rename the DISABLE_TRANSITIONS macro. I think I'll keep the name for the WALLS_* macros.
In my current version, I changed the wall-macros a bit to
where WALL_TRANSITION3 is the previous WALL_TRANSITION_CORNER and WALL_TRANSITION2 is a macro that creates concave/convex AND cw/ccw transitions.
The human castle can thus be specified with
Quite an improvement I think.
I also added some XXX_RANDOM_n macros which draw n tiles with equal probability.
I might remove the versions for different numbers and just use one macro which drawn up to ~8 tiles if the images exist, but I want to check the performance impact of having lots more rules and checking for lots of missing images first (though it should not affect runtime performance, just startup).
In general, I managed to reduce the line-count of _final.cfg by more than 50% (no, I did *not* remove whitespaces and comments...), especially the overlay-transitions are vastly more comprehensible.
Unfortunately, the same cannot be said for the base transitions: there is a inherent complexity in the way the order of rules and especially the layering affect the outcome. So getting good looking transitions for the ~8000 combinations of tiles without resorting to excessive special-casing will remain non-trivial.
The "problem" is that TRANSITION_OVERLAY and ADJACENT_OVERLAY do almost the same, just with and without rotation. I think RESTRICT_ADJACENT is a bit ambiguous, as it sound like it restricts the adjacent tiles. But I like the name RESTRICT for this type of transition in general, so I'll think of something.mesilliac wrote: For the TRANSITION3_OVERLAY and ADJACENT3_OVERLAY etc. macros you could name them with something like "RESTRICT_ADJACENT" and "RESTRICT" in stead. Especially as I think "adjacent" makes more sense for the first macro which applies to other terrains being adjacent . To clarify: TRANSITION3 could be RESTRICT_ADJACENT3 and ADJACENT3 could be RESTRICT3 etc..
In my current version, I changed the wall-macros a bit to
Code: Select all
WALL_TRANSITION, WALL_TRANSITION2, WALL_TRANSITION3
The human castle can thus be specified with
Code: Select all
{WALL_TRANSITION Ch (!,Ch*,Kh*) castle/castle}
{WALL_TRANSITION2 Kh Ch* (!,Ch*,Kh*) castle/keep-castle}
{WALL_TRANSITION Kh (!,Kh*) castle/keep}
I also added some XXX_RANDOM_n macros which draw n tiles with equal probability.
I might remove the versions for different numbers and just use one macro which drawn up to ~8 tiles if the images exist, but I want to check the performance impact of having lots more rules and checking for lots of missing images first (though it should not affect runtime performance, just startup).
In general, I managed to reduce the line-count of _final.cfg by more than 50% (no, I did *not* remove whitespaces and comments...), especially the overlay-transitions are vastly more comprehensible.
Unfortunately, the same cannot be said for the base transitions: there is a inherent complexity in the way the order of rules and especially the layering affect the outcome. So getting good looking transitions for the ~8000 combinations of tiles without resorting to excessive special-casing will remain non-trivial.
Aurë entuluva!
Re: Terrain macros overhaul
The changes are *committed*
Campaign-specific terrains are not yet converted but I left the old macros in place for compatibility. I'll do that conversion when I've recovered from this one.
Campaign-specific terrains are not yet converted but I left the old macros in place for compatibility. I'll do that conversion when I've recovered from this one.
Aurë entuluva!
Re: Terrain macros overhaul
I just committed another change to the terrain macros:
All overlay images (though not in corner transitions) are now centered on the center tile. So from now on you just have to make sure that the image is centred on the canvas. Everything else is done by the engine.
All overlay images (though not in corner transitions) are now centered on the center tile. So from now on you just have to make sure that the image is centred on the canvas. Everything else is done by the engine.
Aurë entuluva!
Re: Terrain macros overhaul
very nice .
I think simply changing the taller corner images to the same size as the smaller ones would be fine. i.e.: to I realize this isn't actually centered on anything useful, but it's probably the most intuitive option for by far the most common usage.
I think simply changing the taller corner images to the same size as the smaller ones would be fine. i.e.: to I realize this isn't actually centered on anything useful, but it's probably the most intuitive option for by far the most common usage.