On further modifications of the terrain system

[mog]

Yeah, but bridges over different types of water don't interact properly. Somebody with greater WML skills should take a look.

The bridge wml is quite complex, but I will take a look.

By the way: You used Bwo* and Bss* for deep water and swamp bridges. You probably did this as an analogy to Bww*, but the ww was meant to stand for wooden/water (or water/wooden).

I suggest we use B(Base type)(Bridge type)(Direction) as strings, this makes the wml easier.

So I'd like to change the new bridges to Bow* and Bsw* (They should not yet be used by many people)

[Eleazar]

Yeah, but bridges over different types of water don't interact properly. Somebody with greater WML skills should take a look.

The bridge wml is quite complex, but I will take a look.

By the way: You used Bwo* and Bss* for deep water and swamp bridges. You probably did this as an analogy to Bww*, but the ww was meant to stand for wooden/water (or water/wooden).

I suggest we use B(Base type)(Bridge type)(Direction) as strings, this makes the wml easier.

So I'd like to change the new bridges to Bow* and Bsw* (They should not yet be used by many people)

The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.

[Darth Fool]

Looking at the code a bit, it looks like it should not be hard to remove the 4-letter limit. SC correct me if I am wrong, but it looks like this was done for convenience: currently the code just takes the four chars and makes it into a single 4-byte integer. It ought to be possible to instead just keep a vector of strings and have the integer associated with it just be the index in the vector. When a new terrain string is encountered, it just gets pushed onto the back of the vector. This might be slightly slower, but I don't think that it would be a huge performance hit.

[torangan]

The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.

I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?

[SkeletonCrew]

[joke_mode]
4 letters should be enough for everybody
[/joke_mode]

but jokes aside yes it's possible to do that, some items need have a fixed letter (the consts declared in the terrain_translation.cpp) other than that the code shouldn't make assumptions about what the numbers are.

Note that the builder code also does some special tricks it stores the map char read in byte 0 of the u32 and uses the other 3 bytes for the anchor number.

It might be wise to limit to some number so the alignment of the map file is a little bit readable.

Before you start also look at get_mask_ since the change makes the wildcard matching harder and it might slowdown the parsing of terrain-graphics.cfg much.

There's only 1 thing bugging me; I thought about doing it like that before but then I saw a big pitfall, but I can't remember what.

Maybe switching to an u64 might even be easier (and faster) since it keeps the wildcard matching simple. Once the old char support is dropped I want to allow the wildcard at all places where multiple terrains are allowed.

[mog]

The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.

I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?

You are right to some degree. If we added another swamp we could just use any free letter for the respective bridge.

On the other hand we should try to keep the strings somewhat mnemonic so the WML stays comprehensible (well... at least somewhat). So we could add another top-level letter for e.g. stone bridges, but I can't think of a free one that wouldn't be as arbitrary as using Bz* for a bridge on some swamp variation.

But as the new bridges are in svn already, we should leave it as it is. Whoever commits the first stone bridge will have to think of something.

[Eleazar]

The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.

I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?

The problem where is we're actually putting two terrains on top of each other, and that were trying to make the terrain codes meaningful.
These dual-layer terrains (villages, bridges, forests) can reasonably have quite a few types when you multiply the number of top layer variants, with the number of reasonable under-layers.

The most flexible (and probably hardest to implement) is to allow the assignment of both layers separately. The Wooden bridge would default to having shallow water beneath (defined by the terrain.cfg) but the map could specify something else instead: "Bw/+SS," for a wooden bridge over standard swamp.

Yes, this sort of thing could make the columns wider, but so would adding length to the terrain code. On a tangent, the maps might be maximumly human-readable, if the padding between columns was the difference between the longest and shortest code in that map + 2.

On the other hand we should try to keep the strings somewhat mnemonic so the WML stays comprehensible (well... at least somewhat). So we could add another top-level letter for e.g. stone bridges, but I can't think of a free one that wouldn't be as arbitrary as using Bz* for a bridge on some swamp variation.

This sort of issue isn't unique to the bridges, placing various types of swamps under various swamp villages etc, would cause the same type of problem.

We can cope for a while, since additional kinds of bridges etc, are so-far theoretical.

[SkeletonCrew]

I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?

You are right to some degree. If we added another swamp we could just use any free letter for the respective bridge.

On the other hand we should try to keep the strings somewhat mnemonic so the WML stays comprehensible (well... at least somewhat). So we could add another top-level letter for e.g. stone bridges, but I can't think of a free one that wouldn't be as arbitrary as using Bz* for a bridge on some swamp variation.

But as the new bridges are in svn already, we should leave it as it is. Whoever commits the first stone bridge will have to think of something.

You're right that they're in svn but they're not documented here http://www.wesnoth.org/wiki/TerrainLettersWML#Bridges yet. That same page reserved Bsw for the swamp bridge. So I'd say if you prefer Bsw and Bow change it now, since it's very probably unused. Once 1.3.1 is released we shouldn't change it anymore.

@torangan yes every letter allows as much options at the entire previous system.

[torangan]

So the problem isn't that we've not got enough combinations now, it's that you want to keep them rather readable. Good luck, this will only work if you go for much more then 4 letters like Darth Fool described. This will allow therotically 2^32 combinations which is enough for everyone. The only problem is that the map won't be easy to read anymore because the columns are very wide.

[Eleazar]

You're right that they're in svn but they're not documented here http://www.wesnoth.org/wiki/TerrainLettersWML#Bridges yet. That same page reserved Bsw for the swamp bridge. So I'd say if you prefer Bsw and Bow change it now, since it's very probably unused. Once 1.3.1 is released we shouldn't change it anymore.

I agree that we should have these things settled before a release.

However, the bridge designations on the wiki are lousy. (which is probably my fault) If "B" stands for all bridges, the second letter should probably indicate the type of bridge to allow for wild-carding.

[torangan]

Good point, I think it's better to have good support for wildcards then readable strings. With a growing number of variants the latter won't be possible for long most likely anyway but easy matching improves the performance.

[mog]

You're right that they're in svn but they're not documented here http://www.wesnoth.org/wiki/TerrainLettersWML#Bridges yet. That same page reserved Bsw for the swamp bridge. So I'd say if you prefer Bsw and Bow change it now, since it's very probably unused. Once 1.3.1 is released we shouldn't change it anymore.

I agree that we should have these things settled before a release.

However, the bridge designations on the wiki are lousy. (which is probably my fault) If "B" stands for all bridges, the second letter should probably indicate the type of bridge to allow for wild-carding.

You're probably right. I wanted to use the second letter for the base terrain so you could use wildcards in the base terrain transitions, but as there will probably be more types of terrain than types of bridges, we should do it your way.

@torangan
I know how important wildcard support is. Fortunately internal consistency (which is required for efficient wildcard use) is usually good for readability.

[Eleazar]

Good point, I think it's better to have good support for wildcards then readable strings. With a growing number of variants the latter won't be possible for long most likely anyway but easy matching improves the performance.

Wild-card support and human-readability are complimentary not contradictory goals. The consistent naming conventions, required for wildcards support readability.

EDIT: replied the same thing, simultaneously with Mog.

[Darth Fool]

The only problem is that the map won't be easy to read anymore because the columns are very wide.

That is true, but everywhere else that terrain strings are used (terrain filters come to mind) will be a lot more readable. Even with 4 characters the maps are basically too big to be easily human readable.

[SkeletonCrew]

What length limit are you thinking of 8 characters or infinite? I really fear that the wildcard code gets much slower if it has to process strings instead of a integers. I already suspect the change to an u64 might slow down quite a bit. (A 64 bit processor will have less trouble with it.)
The usage of the t_match structure sped up the matching for the terrain graphics considerably (didn't measure but it was noticeable).