On further modifications of the terrain system

[SkeletonCrew]

My main problem with the current rules is that you need to add wildcards for the second layer to most matching strings.

So I suggest making "Abcd" equivalent with "Abcd^*". The (much rarer) case of matching only base terrain without any overlay can still be achieved with "Abcde^"

I've to think about it, since adding wildcard to letters might cause a lot of other headaches. In general I'm not really happy to add magic since most of the time if will cause troubles later.

I want to change all the terrain WML matching to wildcard matching once the single letter format is no longer supported. With the current version changing to wildcard matching would cause no changes. With your proposal this would mean after such a conversion Gg suddenly would mean Gg^* so the WML is not compatible.

Also adding a * to everything would cause performance loss.

I'll think about what we can do about it, but I'd also like to hear the opinion from some more developers.

Stupid question; would it be possible to add the ^* in the macro and make a TERRAIN_BASE and a TERRAIN_BASE_W macro the first does no auto wildcard stuff and the second does and if it's possible would it solve your problem?

[mog]

I want to change all the terrain WML matching to wildcard matching once the single letter format is no longer supported. With the current version changing to wildcard matching would cause no changes. With your proposal this would mean after such a conversion Gg suddenly would mean Gg^* so the WML is not compatible.

Ok, that might be a problem outside the t-g.cfg. I didn't think of that. Having different behaviour for terrain WML and other WML would be a possibility, but I really don't like that.

Also adding a * to everything would cause performance loss.

We would need to add the ^* to a lot of rules anyway. If it is really a noticable slowdown, one can easlily optimize this special case.

Stupid question; would it be possible to add the ^* in the macro and make a TERRAIN_BASE and a TERRAIN_BASE_W macro the first does no auto wildcard stuff and the second does and if it's possible would it solve your problem?

No, you have to deal with strings like (Gg,H*,M*), so you can't simply append a ^*.

[mog]

Earlier in this thread we discussed the possibility of automatically generating new layered terrains, i.e. make it possible to place overlays on arbitrary base terrains without having to define each combination in terrain.cfg.

I had a look on how to implement this and it's for the most part quite easy. In fact, it took me about two hours for a working implementation.

The basics work well, so you can e.g. set the string for forest terrain to "^Ff" and paint forest over all base terrains (It wouldn't work out of the box currently because of the reasons one posting above this):

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.

[SkeletonCrew]

[edit] clicked on submit by accident, so finished it now[/edit]

I'd say before committing we'd better first think about how to inherit the properties. I already thought about this before, and did find some problems.

* How to show the terrain in the minimap? This could be done by making a transparent overlay and put that over the base terrain, but at the moment all symbol images are hardcoded combined.

* the terrain needs an unique id (not too hard to solve), this is one of the things I want to solve with the terrain archtypes.

* how does the map code detect whether the terrain is valid? Eg if Bb is undefined Gg^Bb is also undefined so the terrain is invalid.

* Defense and movement modifiers how to do them and the other properties in http://www.wesnoth.org/wiki/TerrainWML.

* How to show the terrains in the editor, I assume you don't want to show every possible combination, eg normal village over water won't be useful.

That's why I thought it would be easier to make it mandatory to add every entry in the terrain.cfg. I'm not sure whether all the problems I see can be solved and still keep things KISS.

I would also say if we do this then the entry in terrain.cfg is always used if defined, otherwise the engine will try to do a merge manually. That way if the automatic process fails it's still possible to do it proper manually.

[SkeletonCrew]

Also adding a * to everything would cause performance loss.

We would need to add the ^* to a lot of rules anyway. If it is really a noticable slowdown, one can easlily optimize this special case.

Stupid question; would it be possible to add the ^* in the macro and make a TERRAIN_BASE and a TERRAIN_BASE_W macro the first does no auto wildcard stuff and the second does and if it's possible would it solve your problem?

No, you have to deal with strings like (Gg,H*,M*), so you can't simply append a ^*.

Since the builder code is quite separate from the rest of the code, I don't mind that is uses other semantics (it already does that anyway). So I think I'll commit a change which does adds star and then we can see how it works. This means if there's no layer instead of 0xFFFFFFFF there will be 0x2A (*) inserted. I'll look at it this week, maybe tonight.

[mog]

* How to show the terrain in the minimap? This could be done by making a transparent overlay and put that over the base terrain, but at the moment all symbol images are hardcoded combined.

For most use cases using either the base or the overlay symbols should be enough. I doubt that combining symbols would be distinct enough in the minimap anyway.

* the terrain needs an unique id (not too hard to solve), this is one of the things I want to solve with the terrain archtypes.

I currently use id1_id2 for the new id. It might clash if it already exists, but using another delimiter char (e.g. ^) is easy.

* how does the map code detect whether the terrain is valid? Eg if Bb is undefined Gg^Bb is also undefined so the terrain is invalid.

When a invalid terrain is encountered (e.g. Ab^Xy), the map code checks if there exist both "Ab" and "^Xy". Only if they do, a new terrain is created.

* Defense and movement modifiers how to do them and the other properties in http://www.wesnoth.org/wiki/TerrainWML.

That's the main thing that needs to be discussed.

* How to show the terrains in the editor, I assume you don't want to show every possible combination, eg normal village over water won't be useful.

I only show the terrains which are defined in terrain.cfg. So in the forest example you still have only one forest, but when you paint with it, it won't replace the base terrain but simply put trees on top of it. Forest might not be the ideal example, but for bridges this would imho be sensible behaviour.

That's why I thought it would be easier to make it mandatory to add every entry in the terrain.cfg. I'm not sure whether all the problems I see can be solved and still keep things KISS.

As I mentioned, I'd like to use this to implement scenery objects, as the current implementation has its flaws (e.g. cannot overlap the hex). Having every combination in terrain.cfg would be impossible. We don't have to do this for all layered terrain, only for overlays that can be used on top of lots of base terrain.

I would also say if we do this then the entry in terrain.cfg is always used if defined, otherwise the engine will try to do a merge manually. That way if the automatic process fails it's still possible to do it proper manually.

Of course. That's the way it currently works.

[SkeletonCrew]

* How to show the terrain in the minimap? This could be done by making a transparent overlay and put that over the base terrain, but at the moment all symbol images are hardcoded combined.

For most use cases using either the base or the overlay symbols should be enough. I doubt that combining symbols would be distinct enough in the minimap anyway.

Not true, for example a bridge over water needs the distinction. Also most overlays are transparent and would get an ugly black background in the minimap.

* the terrain needs an unique id (not too hard to solve), this is one of the things I want to solve with the terrain archtypes.

I currently use id1_id2 for the new id. It might clash if it already exists, but using another delimiter char (e.g. ^) is easy.

I'd vote for the ^ pretty sure it's not used.

* how does the map code detect whether the terrain is valid? Eg if Bb is undefined Gg^Bb is also undefined so the terrain is invalid.

When a invalid terrain is encountered (e.g. Ab^Xy), the map code checks if there exist both "Ab" and "^Xy". Only if they do, a new terrain is created.

Ok

* Defense and movement modifiers how to do them and the other properties in http://www.wesnoth.org/wiki/TerrainWML.

That's the main thing that needs to be discussed.

I have no idea how to do this properly atm.

* How to show the terrains in the editor, I assume you don't want to show every possible combination, eg normal village over water won't be useful.

I only show the terrains which are defined in terrain.cfg. So in the forest example you still have only one forest, but when you paint with it, it won't replace the base terrain but simply put trees on top of it. Forest might not be the ideal example, but for bridges this would imho be sensible behaviour.

Ok, not really sure it would work easy but time should tell. I see some user confusion and also when you painted a forest on a wrong base there's no way to only change the base.

That's why I thought it would be easier to make it mandatory to add every entry in the terrain.cfg. I'm not sure whether all the problems I see can be solved and still keep things KISS.

As I mentioned, I'd like to use this to implement scenery objects, as the current implementation has its flaws (e.g. cannot overlap the hex). Having every combination in terrain.cfg would be impossible. We don't have to do this for all layered terrain, only for overlays that can be used on top of lots of base terrain.

IMHO the scenery objects shouldn't be a part of the terrain, since they don't change the terrain properties. Also this solution won't work in all cases. If you want to place an object on a bridge it's not possible. I'd say changing the code that a scenery object can spill out of the hex might be a better solution for that problem. What's the reason not to use a halo for these cases?

[mog]

Not true, for example a bridge over water needs the distinction. Also most overlays are transparent and would get an ugly black background in the minimap.

Okay, you're right.

* Defense and movement modifiers how to do them and the other properties in http://www.wesnoth.org/wiki/TerrainWML.

For movement/defence I thought of using the current alias system, but allow a "base" alias for overlay terrains. E.g.:
aliasof=base: Use base terrain properties
aliasof=base,Ff: Best of base terain and forest
aliasof=Ff: Treat as forest only

Village,castle,keep properties are easy, if base or overlay are a village/etc. the combined terrain is also.

heals: Either the sum or maximum of both values.
light: sum of both values?

submerge/unit_height_adjust: don't really know. Probably use the overlay value if defined, else fall back to base value.

I only show the terrains which are defined in terrain.cfg. So in the forest example you still have only one forest, but when you paint with it, it won't replace the base terrain but simply put trees on top of it. Forest might not be the ideal example, but for bridges this would imho be sensible behaviour.

Ok, not really sure it would work easy but time should tell. I see some user confusion and also when you painted a forest on a wrong base there's no way to only change the base.

One could mark overlay terrains in the palette or put them into their own group. Painting only base terrain could be implemented as a feature in the editor if deemed useful. Confusion would also depend on the kind of terrain. For often used terrain like forest it's probably a bad idea, but for bridges or the great tree I think it would be great.

IMHO the scenery objects shouldn't be a part of the terrain, since they don't change the terrain properties. Also this solution won't work in all cases. If you want to place an object on a bridge it's not possible.

This is also true for lots of terrains we currently have (roads, dirt, fields). And yes, it's limited to terrains without a second layer, but it's still an improvement.

I'd say changing the code that a scenery object can spill out of the hex might be a better solution for that problem. What's the reason not to use a halo for these cases?

Both were discussed here: http://wesnoth.org/forum/viewtopic.php?p=216556#216556

[SkeletonCrew]

For movement/defence I thought of using the current alias system, but allow a "base" alias for overlay terrains. E.g.:
aliasof=base: Use base terrain properties
aliasof=base,Ff: Best of base terain and forest
aliasof=Ff: Treat as forest only

That might be doable, but I'd rather implant the archtype system before that change.

Village,castle,keep properties are easy, if base or overlay are a village/etc. the combined terrain is also.

Seems sane

heals: Either the sum or maximum of both values.

I'd say maximum

light: sum of both values?

Might be the best

submerge/unit_height_adjust: don't really know. Probably use the overlay value if defined, else fall back to base value.

That one is tricky, water is a base terrain. Not sure what you want to do with hills and mountains.

I'd say changing the code that a scenery object can spill out of the hex might be a better solution for that problem. What's the reason not to use a halo for these cases?

Both were discussed here: http://wesnoth.org/forum/viewtopic.php?p=216556#216556

Ah I missed that thread, but allowing items to spill out of the hex might be a nice option anyway, and determining where the halo is drawn as well.

BTW I send a mail to the ml to see what other developers and artists think.

[mog]

Ok, so here is my proposal for the multilayer terrain strings:
http://www.wesnoth.org/wiki/User:Mog

If we implement these and convert the campaigns to the new format, we should be ready for 1.3.2.

"Overlay only" terrains also work in the terrain-layer branch, at least the graphical parts. We don't have to finish that before 1.3.2, as the new possible terrain combinations would be a superset of the current ones, so it will remain compatible.

[SkeletonCrew]

Do we need to port the auto wildcard part from the branch or can that be evaluated at a later time?

[mog]

Do we need to port the auto wildcard part from the branch or can that be evaluated at a later time?

I'd very much prefer it. I really don't want to port t-g.cfg without it.

[SkeletonCrew]

Oke I'll look into it later this week.

[Temuchin Khan]

Earlier in this thread we discussed the possibility of automatically generating new layered terrains, i.e. make it possible to place overlays on arbitrary base terrains without having to define each combination in terrain.cfg.

I had a look on how to implement this and it's for the most part quite easy. In fact, it took me about two hours for a working implementation.

The basics work well, so you can e.g. set the string for forest terrain to "^Ff" and paint forest over all base terrains....

Just an observation: While the examples given above look good, I can't help but wonder if the current mountains or hills overlaid with the current forests look as good. I suspect they would not. If we wanted forested hills or forested mountains, then new terrains would be needed and not just overlays.

[Eleazar]

Earlier in this thread we discussed the possibility of automatically generating new layered terrains, i.e. make it possible to place overlays on arbitrary base terrains without having to define each combination in terrain.cfg.

I had a look on how to implement this and it's for the most part quite easy. In fact, it took me about two hours for a working implementation.

The basics work well, so you can e.g. set the string for forest terrain to "^Ff" and paint forest over all base terrains....

Just an observation: While the examples given above look good, I can't help but wonder if the current mountains or hills overlaid with the current forests look as good. I suspect they would not. If we wanted forested hills or forested mountains, then new terrains would be needed and not just overlays.

You are right, those combinations would look bad. Most possible combinations would look bad.
But that's not the point, it's a more powerful/flexable system— which is movement in the right direction.