On further modifications of the terrain system

[Eleazar]

What length limit are you thinking of 8 characters or infinite?

I'm fine with 4 characters per terrain.
I just want to be able to define the two parts of a dual-layered terrain separately.

Is my previously stated idea not clear? The discussion has seemed to have gone around it.

[SkeletonCrew]

What length limit are you thinking of 8 characters or infinite?

I'm fine with 4 characters per terrain.
I just want to be able to define the two parts of a dual-layered terrain separately.

Is my previously stated idea not clear? The discussion has seemed to have gone around it.

My previous reply was a reply to Darth Fool about increasing the number of letters in the system.

I've read your idea and it seems to be rather hard and a lot of work, but I want to look at it a little longer to see whether I get a good idea. As far as I can see now the code needs to be changed quite a lot to support that idea. I'm also not sure what the impact on the wildcard matching is, in both performance and working.

[mog]

My previous reply was a reply to Darth Fool about increasing the number of letters in the system.

I've read your idea and it seems to be rather hard and a lot of work, but I want to look at it a little longer to see whether I get a good idea. As far as I can see now the code needs to be changed quite a lot to support that idea. I'm also not sure what the impact on the wildcard matching is, in both performance and working.

I like the idea of that system. Currently for e.g. a snowy hill village, I can only match either the hill part or the snow part via wildcards. Having independent strings for base and overlay would solve that. Of course it means another terrain system switch, but it's the development version, isn't it?

Performance impact would probably depend on how many terrains use this new feature. If we encode every terrain as two integers, we would only need to match on the second part if one exists.

For dual layer terrains, the number of matching operations would double of course, but that might be countered by fewer rules/shorter matching strings. Or we could use a syntax for explicitly matching the first/second part only. We'd need a way for matching exactly one terrain (i.e. both layers) anyway. One could use "Xyz+Abc", "+Abc" and "Xyz+" for matching both, the second and the first layer. Or we could just make the default "Xyz" match the first layer only, as I don't see the need to match either foreground or background in a single rule.

It might be quite a bit of work. If SC doesn't want to do it, I might try it myself.

[SkeletonCrew]

The new system is less than 1 week old, so before I even consider to rework it we should have a good proposal how it should work. And also think what it should do in the future (are 2 layers enough or does there need to be an third layer for in the air with a certain transparency, etc).

Also changing it again would mean that the content in trunk and already converted UMC has to be changed again, which is quite a bit of work. (I have no idea how much UMC is already converted.) Or will it be an extension to the current system?

[Eleazar]

The new system is less than 1 week old, so before I even consider to rework it we should have a good proposal how it should work. And also think what it should do in the future (are 2 layers enough or does there need to be an third layer for in the air with a certain transparency, etc).

This idea in no way denigrates the work you've already done. But the idea of separately definable layers is more than a year old IIRC. I did bring it up during the brain-storming, stage of the current improvements, but the response was essentially, "One thing at a time..."

Certainly we need to think this out before breaking the trunk again.

I can't imagine a reason for 3 independent layers. Layers here are more significant than the number of graphics. The Impassible mountains are now made up of 3-4 layers. That's fine. We wouldn't need to define all those layers separately on a map.

Also changing it again would mean that the content in trunk and already converted UMC has to be changed again, which is quite a bit of work. (I have no idea how much UMC is already converted.) Or will it be an extension to the current system?

If Mog is thinking along the same lines as I am, this will not require a change of the content. As envisioned terrains that need an underlayer (like bridges) could define a default one. So the bridge would still appear over shallow water, unless the map-maker wanted to put something else underneath.

[Darth Fool]

I don't think that the proposal of multiple layers need necessarily break the current system if the code can reasonably handle arbitrary lengthed strings for terrain. SC is correct to worry about whether the underlying code that enables that would have issues when filtering on wildcards, but I think that with suitable optimizations, that could be handled. If it is possible to extend to arbitrary lengths, then a system of 'Aa+Bbx+xZy' would be easy to handle in the terrain definitions, although the permutations might get a little hairy if you want to have completely arbitrary layers of bridges. If it does get hairy, we could add something to automagically process such things, but I think that can be pushed further down the road until we have some more experience with the system.

Ugh. meeting. Will post more thoughts later.

[SkeletonCrew]

The new system is less than 1 week old, so before I even consider to rework it we should have a good proposal how it should work. And also think what it should do in the future (are 2 layers enough or does there need to be an third layer for in the air with a certain transparency, etc).

This idea in no way denigrates the work you've already done. But the idea of separately definable layers is more than a year old IIRC. I did bring it up during the brain-storming, stage of the current improvements, but the response was essentially, "One thing at a time..."

That 1 thing at a time was about the terrain archtypes which was unrelated to this issue, or I misread something. You have a pointer to the separate definable layers idea?

Certainly we need to think this out before breaking the trunk again.

That it's posted in the announcement gives a bit the impression that the whole thing is being rushed (at least to me). I'm also going to move this sub thread to ideas, this doesn't require another UMC change.

I can't imagine a reason for 3 independent layers. Layers here are more significant than the number of graphics. The Impassible mountains are now made up of 3-4 layers. That's fine. We wouldn't need to define all those layers separately on a map.

Also changing it again would mean that the content in trunk and already converted UMC has to be changed again, which is quite a bit of work. (I have no idea how much UMC is already converted.) Or will it be an extension to the current system?

If Mog is thinking along the same lines as I am, this will not require a change of the content. As envisioned terrains that need an underlayer (like bridges) could define a default one. So the bridge would still appear over shallow water, unless the map-maker wanted to put something else underneath.

No changes to the current content would be great, since that also gives us time to implant it a bit longer timeframe. (If it will break things UMC can stop converting their stuff.)

I've some ideas about how to implant this stuff but I'll rather see a more finalized idea, before I start to say it might be easy

[SkeletonCrew]

I don't think that the proposal of multiple layers need necessarily break the current system if the code can reasonably handle arbitrary lengthed strings for terrain. SC is correct to worry about whether the underlying code that enables that would have issues when filtering on wildcards, but I think that with suitable optimizations, that could be handled. If it is possible to extend to arbitrary lengths, then a system of 'Aa+Bbx+xZy' would be easy to handle in the terrain definitions, although the permutations might get a little hairy if you want to have completely arbitrary layers of bridges. If it does get hairy, we could add something to automagically process such things, but I think that can be pushed further down the road until we have some more experience with the system.

Ugh. meeting. Will post more thoughts later.

Again, once I finish replying somebody else has posted, 3 times in a row in this thread

I then reveal some of my idea's:
I want to give it a fixed amount of letter groups aka layers since then we can easily put in a struct and define operator== and most things are done. Every letter group can have a maximum of 4 characters.

I still want to use the same way of building masks so wildcard matching could be done on layer level and wouldn't suffer a translation back to string to match.

Of course expanding the struct can then also be done easily if another layer is required.

Once 1.3.1 has been released I want to look whether this idea can be done, it seems rather simple.

[mog]

I then reveal some of my idea's:
I want to give it a fixed amount of letter groups aka layers since then we can easily put in a struct and define operator== and most things are done. Every letter group can have a maximum of 4 characters.

I still want to use the same way of building masks so wildcard matching could be done on layer level and wouldn't suffer a translation back to string to match.

Of course expanding the struct can then also be done easily if another layer is required.

This is exactly what I had in mind.

[Darth Fool]

I don't think that the proposal of multiple layers need necessarily break the current system if the code can reasonably handle arbitrary lengthed strings for terrain. SC is correct to worry about whether the underlying code that enables that would have issues when filtering on wildcards, but I think that with suitable optimizations, that could be handled. If it is possible to extend to arbitrary lengths, then a system of 'Aa+Bbx+xZy' would be easy to handle in the terrain definitions, although the permutations might get a little hairy if you want to have completely arbitrary layers of bridges. If it does get hairy, we could add something to automagically process such things, but I think that can be pushed further down the road until we have some more experience with the system.

Ugh. meeting. Will post more thoughts later.

Again, once I finish replying somebody else has posted, 3 times in a row in this thread

I am quite familiar with the phenomenon

I then reveal some of my idea's:
I want to give it a fixed amount of letter groups aka layers since then we can easily put in a struct and define operator== and most things are done. Every letter group can have a maximum of 4 characters.

I still want to use the same way of building masks so wildcard matching could be done on layer level and wouldn't suffer a translation back to string to match.

Of course expanding the struct can then also be done easily if another layer is required.

Once 1.3.1 has been released I want to look whether this idea can be done, it seems rather simple.

That sounds reasonable. The one thing I would avoid doing, at least at first, is having the definition of the terrain properties automagically defined. In other words, I would still require an entry in the terrain.cfg for 'AAAA+BBBB' even if 'AAAA' and 'BBBB' are both already defined. I worry that an automated system might have issues in dealing with all the possible meanings of having A on top of B (movement and defense are the most obvious problems). I suppose one could decide on using different symbols for different versions, like AAAA+BBBB = best defense best movement, AAAA-BBBB = best defense worse movement, AAAA!BBBB = worst defense, best movement, and AAAA=BBBB = worst defense worst movement, and AAAA*BBBB = much strangeness. Actually, even if you don't implement this as an automatically generated terrain, such a standard might be useful. Another problem with fully automated definition of the 'multilayer' terrain is the question of automating how to do transitions, but that might be easier than I think.

[mog]

That sounds reasonable. The one thing I would avoid doing, at least at first, is having the definition of the terrain properties automagically defined. In other words, I would still require an entry in the terrain.cfg for 'AAAA+BBBB' even if 'AAAA' and 'BBBB' are both already defined. I worry that an automated system might have issues in dealing with all the possible meanings of having A on top of B (movement and defense are the most obvious problems).

Definately. Automatically combining terrains would only be trouble as there are lots of combinations that just don't make sense. And there are cases where you don't want the base terrain to influence movement/defence (e.g. Forests).

The layers should be confined to terrain matching.

I suppose one could decide on using different symbols for different versions, like AAAA+BBBB = best defense best movement, AAAA-BBBB = best defense worse movement, AAAA!BBBB = worst defense, best movement, and AAAA=BBBB = worst defense worst movement, and AAAA*BBBB = much strangeness. Actually, even if you don't implement this as an automatically generated terrain, such a standard might be useful.

I really don't see any use for that. The current syntax in terrain.cfg seems to be sufficient.

Another problem with fully automated definition of the 'multilayer' terrain is the question of automating how to do transitions, but that might be easier than I think.

That would be the easiest part. For the most part, base terrain and overlay transitions are independent. So adding e.g. a bridge over ice, a tropic village on water or mushrooms on dirt, can then be done without touching the terrain wml.

[SkeletonCrew]

That sounds reasonable. The one thing I would avoid doing, at least at first, is having the definition of the terrain properties automagically defined. In other words, I would still require an entry in the terrain.cfg for 'AAAA+BBBB' even if 'AAAA' and 'BBBB' are both already defined. I worry that an automated system might have issues in dealing with all the possible meanings of having A on top of B (movement and defense are the most obvious problems). I suppose one could decide on using different symbols for different versions, like AAAA+BBBB = best defense best movement, AAAA-BBBB = best defense worse movement, AAAA!BBBB = worst defense, best movement, and AAAA=BBBB = worst defense worst movement, and AAAA*BBBB = much strangeness. Actually, even if you don't implement this as an automatically generated terrain, such a standard might be useful. Another problem with fully automated definition of the 'multilayer' terrain is the question of automating how to do transitions, but that might be easier than I think.

Every terrain should have it's own entry in terrain.cfg the map code uses that to see whether all terrains are properly defined. For the aliases I want to implant the terrain archtypes as discussed here http://www.wesnoth.org/forum/viewtopic.php?t=8801.

[edit]
and this makes 4 in a row
[/edit]

[Eleazar]

Just to make sure everyone is on the same page.
Advantages in allowing the defining of two layers independantly:

• Terrain-graphics.cfg becomes much simpler.
When you put a village on-top of grassland, the grassland behaves exactly as it would without the village. There wouldn't be a need to add the village to each time grassland appears ing the t-g.cfg. Grassland as the default under-layer for a village would be stated in terrain.cfg.

• The map maker can create new visual variations on terrain.
While with more layers lots of combinations can be added, however some combinations would be too infrequently used to justify cluttering up the list. But if the scenario needed an elven tree on a sand-crater, the map-maker could easily add it.

• Terrain codes are more readable.
Four letters are plenty for any single terrain. But when trying to label two terrains over each other, both of which independently might normally use more than two letters, the readability is compromised.


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.

[SkeletonCrew]

Just to make sure everyone is on the same page.
Advantages in allowing the defining of two layers independantly:

• Terrain-graphics.cfg becomes much simpler.
When you put a village on-top of grassland, the grassland behaves exactly as it would without the village. There wouldn't be a need to add the village to each time grassland appears ing the t-g.cfg. Grassland as the default under-layer for a village would be stated in terrain.cfg.

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.

• The map maker can create new visual variations on terrain.
While with more layers lots of combinations can be added, however some combinations would be too infrequently used to justify cluttering up the list. But if the scenario needed an elven tree on a sand-crater, the map-maker could easily add it.

This might be tricky since wesnoth seeds to know every terrain variation and that means the terrain must be known in terrain.cfg.

• Terrain codes are more readable.
Four letters are plenty for any single terrain. But when trying to label two terrains over each other, both of which independently might normally use more than two letters, the readability is compromised.

If we're splitting the string for the layers it would be easy to allow 4 letters for every layer.

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 personally think the best way might be to look at the advantage for terrain-graphics.cfg and adjust that code accordingly. The rest of the code won't be changed and just uses the "letter" and that the "letter" exists of 2 parts is unknown. Once that's done we can see whether the other steps are also required, since I doubt that the rest of the code really benefits from these changes.

[mog]

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)

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.

Overlay terrains obviously need a way to reference the base terrain in its aliasof/mvt_alias attributes. Just using someting like "_base" should work.

Now that I think of it: overlay terrains seem to be a great method to place scenery objects on maps (at least for base terrain tiles). It would be trivial to implement (use aliasof=_base) and could greatly enhance the look of the maps.

Disadvantage of all this would be of course a greater complexity of the map editor and a huge number of possible terrains (whose meaning might be unclear to the player.).

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.

Overlay terrains would then require bigger changes in at least the editor and probably terrain handling code.

[edit]

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)