On further modifications of the terrain system

[Eleazar]

In all the terrains we have (or that i can imaging) the top layer is the controlling layer. In the terrain.cfg, the bridge definition would declare that a unit gets best def/mov no matter what is underneath. A village would might generally have best def, worst mov. A forest might ignore what's underneath for mov/def.

I think this loses the ability to really define the move and defense rating which might not be an good idea. I'm not sure what's the best way to define snow hills for example is it easier to define snow on hills or hills on snow?

I don't see a reason to change how snow hills work. It's a hybrid terrain, but not a dual-layer one.
What i'm suggesting needn't change hybrid terrains, but could leverage it in a different way.

All in all I really like the concept of independent overlay terrains, but we really have to be careful not to complicate the game. Maybe we should start implementing layers for the terrain wml first. This is a prequisite for the other stuff, mostly independent from it and really useful by itself.

I'm not really interested in making new kinds of terrain (i.e. different move-types) but simply in making terrain look different, or in the case of hybrid terrains, switching out the lower component.

[SkeletonCrew]

In all the terrains we have (or that i can imaging) the top layer is the controlling layer. In the terrain.cfg, the bridge definition would declare that a unit gets best def/mov no matter what is underneath. A village would might generally have best def, worst mov. A forest might ignore what's underneath for mov/def.

So we would basically have three types of terrain:

• Base terrains: defined in terrain.cfg, uses base layer only. (e.g. grassland, water, roads)
• Combined terrains: defined in terrain.cfg, uses both layers for graphics.
• Overlay terrains: always placed upon a base terrain. movement/defence alias rules can reference base terrain. (e.g. Bridges, maybe forests)

I think overlays only need to exist for the terrain-graphics.cfg and the base and combined in the terrain.cfg. Thus the overlays don't need mvt/def ratio since it's stated in the combined terrain.

One could do without combined terrains, but they can be used for commonly used terrains (forests/villages). So one doesn't have place terrain twice for most of the terrains. They could also be implemented in the editor only by aliasing one base and one overlay terrain.

I'm not sure whether that's a good idea, IMHO the terrain system should only be used for terrains, WML already has the option to add these scenery items. Also if we would allow that the amount of terrains in the editor would explode.

I agree that this might be really nice to have. I'm not sure what's the best way to access the individual layer parts, but maybe mog has a suggestion.

I already suggestes some syntax in this thread. Briefly:
Match first layer: Abc*
Match second layer: +Xyz*
Match both layers: Abc*+Xyz*

This would keep backward compatibility for the most part, and if the maps use the proposed "Abcd+Xyzz" format it would be the most intuitive choice.
(The delimiter char can be anything not yet in use of course)

But for terrain-graphics.cfg wouldn't it be easier to access the separate layers directly eg letter_base and letter_overlay so the macro's are easier to define and you don't need to write down all the *'s every time?

[mog]

I think overlays only need to exist for the terrain-graphics.cfg and the base and combined in the terrain.cfg. Thus the overlays don't need mvt/def ratio since it's stated in the combined terrain.

[...]

I'm not sure whether that's a good idea, IMHO the terrain system should only be used for terrains, WML already has the option to add these scenery items. Also if we would allow that the amount of terrains in the editor would explode.

Well, as I said: *If* we want to do something like this, it should be for a later stage, after the WML work is done.

And the editor would certainly need some changes to manage the additional terrains. On the other hand, placing scenery items via WML is quite tedious, especially ones that have no gameplay value but only add flavour to the maps.
I'm sure that having them in the editor would make maps more varied.

But for terrain-graphics.cfg wouldn't it be easier to access the separate layers directly eg letter_base and letter_overlay so the macro's are easier to define and you don't need to write down all the *'s every time?

On the contrary. If there were two attributes for base and overlay terrain, one would have to rewrite most macros (and consequently, most terrain wml) to support both parameters, even though one of them would be almost always empty.

And you don't need the "*"s. They were only for example. Abc, +Xyz and Abc+Xyz would be equally possible. The only annoyance would be that you need to add the "+" for all overlay terrain, but compared to the alternatives, it's a minor issue.

[SkeletonCrew]

And the editor would certainly need some changes to manage the additional terrains. On the other hand, placing scenery items via WML is quite tedious, especially ones that have no gameplay value but only add flavour to the maps.
I'm sure that having them in the editor would make maps more varied.

I'll have a look at campgen soon to see whether it supports this.

And you don't need the "*"s. They were only for example. Abc, +Xyz and Abc+Xyz would be equally possible. The only annoyance would be that you need to add the "+" for all overlay terrain, but compared to the alternatives, it's a minor issue.

Oke, then I think it can be done quite easy, I'll look into it after 1.3.1 has been released. I want to give the current system a little bit more test coverage before I start to change it.

[SkeletonCrew]

I just noticed a small problem with the + and WML a + can only work between double quotes... I think I'll use the ^ as separator instead.

[Darth Fool]

I just noticed a small problem with the + and WML a + can only work between double quotes... I think I'll use the ^ as separator instead.

???
Out of curiosity what part of the code prevents the use of '+' in the terrain WML?

[SkeletonCrew]

I just noticed a small problem with the + and WML a + can only work between double quotes... I think I'll use the ^ as separator instead.

???
Out of curiosity what part of the code prevents the use of '+' in the terrain WML?

The part that changes the following WML (see commit 15655)
mvt_alias=+,Uu,Ql
to this WML as seen by the terrain code
mvt_alias=,Uu,Ql

It might be possible to fix this problem, but I've no idea how much code depends on this 'feature'. For strings it makes sense eg "foo" + "bar" = "foobar" but with other things not. So I'd rather avoid the + and thus the problem.

[SkeletonCrew]

I'll start with this somewhere next week, so here's a final proposal:

Terrain strings can be made out of 2 parts separated by a caret(^) these parts will be the same as the currently implanted terrain strings. If the second layer is not used it's not required to enter that layer. All terrains have a first layer.
The matching rules will be the following:
The * matches the following characters on a layer and if no layer separator is used it will match the following layers as well, so A* is the same as A*^*. This way backwards compatibility will work, also if we later decide that 3 layers are required.

eg

Code: Select all

A*       matches Abcd but also Abcd^Abcd
A*^*     matches Abcd but also Abcd^Abcd
A*^      matches Abcd but *not* Abcd^Abcd
A*^Abcd  does not match Abcd but matches Abcd^Abcd

^*       invalid since it will only match terrains with a second layer

The code will internally use 2 u32's so the matching filters can still be pretty much the same as they're now which will help the processing speed of the matching routines. Also if a third layer is required the code can easily be changed for the third layer.

[mog]

Just to make sure:

Code: Select all

*^Abcd  matches Abcd^Abcd and Xyz^Abcd

will be possible? Because this is the main usecase.

Otherwise it looks good.

[SkeletonCrew]

Just to make sure:

Code: Select all

*^Abcd  matches Abcd^Abcd and Xyz^Abcd

will be possible? Because this is the main usecase.

Yes

[SkeletonCrew]

I added support for the layers, not much tested yet
It enlarges the glitch that terrains at the edge of the screen don't get drawn properly. The top row no longer draws overlays eg villages and forest only have a base terrain. Since this problem is next on my todo list anyway I don't bother with it too much right now.

It uses a 64 bit datatype which might not be supported by all compilers so I added a compatibility header but can't test that since my compiler supports 64 bit integers.

[Eleazar]

very cool

i'll be all over testing this after i finish unpacking. (i moved last weekend.)

[mog]

It seems to work so far, but unfortunately it's also very slow (even when there are no rules using layers).

I'll try to port terrain.cfg/t-g.cfg to the layer system and post possible bugs here.

[SkeletonCrew]

Somebody else noticed the slowness as well, I'd like to see what's causing it, if it's the change to a 64 bit type we might have to revert it and look for another solution.

Does porting mean that existing terrains get new names, since that would break compatibility.

[mog]

Does porting mean that existing terrains get new names, since that would break compatibility.

Yes. Otherwise we could only use the features of the layer system for new terrain. Which would make it quite useless as we couldn't cleanly generalize the terrain in base/overlay. And the WML would become more complex instead of simpler.

I made a rough port of the terrain files, and apart from the bugs you mentioned it works extremely well. I made villages, forests and bridges overlays and it really makes the WML much simpler (especially the TERRAIN_ADJECENT lines).