On further modifications of the terrain system

[SkeletonCrew]

I added code support in trunk which should allow the automatic wildcard extension. I haven't tested it much but it should work.

@mog do you already have a (partial) converted t-g.cfg which I can use to test?

[Eleazar]

for some reason i can't commit to the terrain branch.

Somebody please add the attached to that branch. It adds an off-map texture as a terrain more-or-less. It should make further coding easier with something to see.

[SkeletonCrew]

for some reason i can't commit to the terrain branch.

Somebody please add the attached to that branch. It adds an off-map texture as a terrain more-or-less. It should make further coding easier with something to see.

Done

[Eleazar]

What doesn't work yet is sensible merging of movement/defence/etc... of base and overlay terrains. But it should be easy to implement when we decide how to handle it. And even if we simply left the properties of the base terrain intact it would still be a great way to implement scenery object in a saner way.

As my changes won't affect current behaviour without changing the WML, I'd like to commit this. Except if the majority thinks that this feature is completely unnecessary.

I think this would be rather useful.

For handling the MV/Def of base and overlays, i believe "control" should be given to the overlay terrain. Overlays like bridges, may allow the MV/Def of the base to have some effect, while overlays like Impassable mountains have MV/Def unaffected by the base. It's hard to think of a situation where the base should have control.

[mog]

It's hard to think of a situation where the base should have control.

Illumination is now an overlay terrain, so it would be an example.

Anyway, the "base only" and "overlay only" cases are easy to implement. It's the mixed case that requires some thought (especially when the base terrain has already a combined movetype). I'll post some concrete suggestions on how to handle movement in the next days.

[Eleazar]

It's hard to think of a situation where the base should have control.

Illumination is now an overlay terrain, so it would be an example.

Anyway, the "base only" and "overlay only" cases are easy to implement. It's the mixed case that requires some thought (especially when the base terrain has already a combined movetype).

That's not what i mean by "control." I mean the overlay determines what role, if any, the base has in the MV/Def. The illumination overlay changes the ToD, but leaves the rest to the base.

To look at it another way, consider the basic cave-floor. It may have a village, fungus, or illuminated overlay. In these various circumstances the cave-floor has partial, none, and full effect on the MV/Def. The simplest way to look at it: the overlay controls how much effect the base has.

As for combining overlays with hybrid terrains, that too seems simple (conceptually, not necessarily code-wise). It's just as easy to find the Best or Worst MV/Def out of 3 as it is out of 2.

I'll post some concrete suggestions on how to handle movement in the next days.

i look forward to reading that.

[mog]

As I mentioned here, I ported my "overlay only" terrain to our current codebase. The cliffs are an obvious use case for this feature, so I'd like to see it done.

I implemented automatic terrain merging as follows:

Automatic merging for terrain base^overlay will only occur if both "base" and "^overlay" are defined in terrain.cfg. If base^overlay is already defined in terrain.cfg, the code will of course use this definition.

If terrain is merged, the following rules are applied:

If base OR overlay are a village, castle or keep, so is the combined terrain.
heals: the maximum of the values of base and overlay.
light: the sum of the values of base and overlay.
submerge/unit_height_adjust: the values of the overlay.

name: name of the overlay
id: base id^overlay id

The minimap graphics is created by overlaying base and overlay images.

For movement/defence aliases, the lists from overlay and base are combined as follows:
The value of the overlay is used and if the special terrain "_bas" is encountered, it's replaced with the aliases from base with the following additions:
If there was a "-" somewhere before _bas, insert a "+" before and a "-" after the base aliases.
Else, insert a "+" after the base aliases.

This will combine the aliases in a natural way if _bas is placed at the front of the list.
So the usual cases are:

• Xy, Yz = don't use base aliases at all
• _bas = use base aliases
• -,_bas, Xy, Yz = smallest of base value, Xy, Yz
• _bas, Xy, Yz = highest of base value, Xy, Yz

In the editor, overlay terrains will simply add/replace the overlay to the terrain you draw over.

I converted the bridges to overlay terrains and everything seems to work in the editor and ingame. Is there anybody against committing this?

[mog]

I just *committed* the changes. For now I only converted the bridges to use the new feature.

Other terrains that could be converted to overlay terrains are the windmill, great tree, rubble and perhaps oasis and villages. But first I want some feedback on the way it works.

[SkeletonCrew]

I'm still not convinced it's the best way But there's only one way to find out (and I hope I'm wrong).

I just played a little bit with it in the editor and it seems to work nice.
I played the tutorial (scenario 1) and I see some glitches.

btw if you need some automatic changes best ask esr on IRC or file a FR for him.

[mog]

I just played a little bit with it in the editor and it seems to work nice.
I played the tutorial (scenario 1) and I see some glitches.

What kind of glitches? I noticed that the "Village" label is misplaced, but that's not due to my changes.

[mesilliac]

I didn't really notice any glitches in the new bridges, or my cliffs which I converted to use the overlay system.

I think the way it works is fine .

One thing I wanted to do when playing with it was to place a base terrain "under" an overlay in the map editor. But this is probably only for when you are making silly maps like http://www.wesnoth.org/forum/download/f ... &mode=view

I always thought the forest would be good to have on different bases. Forest hills for example. It's extraordinarily easy to use the system, anyway . =

One other small thing I noticed was when I put a bridge over lava it said "Bridge (Flat, Unwalkable)", which looks a bit odd.

I haven't played around with strange movement/defense mixes. Just enough to confirm that bridge movement/defense seems to work as it should.

[mog]

One thing I wanted to do when playing with it was to place a base terrain "under" an overlay in the map editor. But this is probably only for when you are making silly maps like http://www.wesnoth.org/forum/download/f ... &mode=view

That's on my todo list. It'll probably be: ALT+Click - replace base terrain only (if possible)

One other small thing I noticed was when I put a bridge over lava it said "Bridge (Flat, Unwalkable)", which looks a bit odd.

That's the way terrain aliasing works. One might remove "Unwalkable" in this case, but there could be cases where e.g. a unit has better defence on unwalkable than on flat terrain. Better leave it as it is.

[mog]

One thing I wanted to do when playing with it was to place a base terrain "under" an overlay in the map editor. But this is probably only for when you are making silly maps like http://www.wesnoth.org/forum/download/f ... &mode=view

This is now implemented.

[mog]

For those who care:

One can now change base and overlay separately in [terrain] and [terrain_mask] events: http://www.wesnoth.org/wiki/TerrainMaskWML ([terrain] syntax is identical)