Idea to remove the limits of the current terrain system

[zookeeper]

The main reason why I like single-letter terrain symbols is that it allows me to look at and edit the raw map files easily. If I want to change the hex at 21,8 to grassland, I just open up the map file, go to line 8, column 21 and change the letter. Simple, convenient and far faster than opening the map editor and loading the map from there (and the map editor doesn't yet support opening maps with custom terrains either). However, if the terrain symbols consisted of multiple letters, I couldn't really do this anymore.

[Jetrel]

The main reason why I like single-letter terrain symbols is that it allows me to look at and edit the raw map files easily. If I want to change the hex at 21,8 to grassland, I just open up the map file, go to line 8, column 21 and change the letter. Simple, convenient and far faster than opening the map editor and loading the map from there (and the map editor doesn't yet support opening maps with custom terrains either). However, if the terrain symbols consisted of multiple letters, I couldn't really do this anymore.

What? How would that not be easy with this? That makes no sense to me:
(Here, we're assuming G1,G2 are grass, V1 is village, M1,M2 mountain, etc)

G2,G2,G2,G2,M1
G2,G1,G1,G1,M1
G2,G1,V1,H1,M2
G1,G1,W1,H2,H1

[zookeeper]

What? How would that not be easy with this? That makes no sense to me:
(Here, we're assuming G1,G2 are grass, V1 is village, M1,M2 mountain, etc)

G2,G2,G2,G2,M1
G2,G1,G1,G1,M1
G2,G1,V1,H1,M2
G1,G1,W1,H2,H1

Hmm...ok, it wouldn't be too bad. I for some reason didn't think of using comma-separation in the map format, even though it was mentioned.

Of course, a real map file would still usually be more like this:

G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1
G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1,G2,G2,G2,G2,M1
G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1,G2,G1,G1,G1,M1

...but even that wouldn't be unmanageable, I suppose. Argument withdrawn for now, for the most part.

[SkeletonCrew]

The only problem with multiple letters I can see so far is the terrain graphics map, which is not nice to start with. We could change the format to the following:
- Every bracket group is the same as the 4 character groups at the moment.
- Odd lines start with ().
- Terreain letters are comma separated and between brackets.
- Special chars *. are between brackes.
- Anchor numbers are between brackets.
- Spaces/tabs can be used for alignment, but only outside brackets.

Example

Code: Select all

map="
1
  1
*"
[tile]
    pos=1
    type=CK
[/tile]

becomes

Code: Select all

map="
(1)
()(1)
(*)"
[tile]
    pos=1
    type=CK
[/tile]

or

Code: Select all

map="
(C,K)
()   (C,K)
(*)"

Of course the C can be a multi-letter like Va.

[Darth Fool]

The only problem with multiple letters I can see so far is the terrain graphics map, which is not nice to start with. We could change the format to the following:
- Every bracket group is the same as the 4 character groups at the moment.
- Odd lines start with ().
- Terreain letters are comma separated and between brackets.
- Special chars *. are between brackes.
- Anchor numbers are between brackets.
- Spaces/tabs can be used for alignment, but only outside brackets.

Code: Select all

map="
(C,K)
()   (C,K)
(*)"

Of course the C can be a multi-letter like Va.

Yes, you clearly have been digging into the code. obviously numbered terrains have the same problem as the multilettered terrains here. When I proposed the comma seperated list originally, I didn't mention what I had thought to do about this, in part because I wasn't exactly sure (although I had some ideas that would work) and in part because 99% of the forum users have never dealt with it. The easiest thing to do would be to just continue with just using comma seperation, but I like your solution better.

[mog]

I just want to add that none of the official WML-Files use the following notation:

Code: Select all

map="
CK
  CK
*"

They only use numbers, "." and "*". So I don't think there are big changes needed. Just using the same syntax as the other WML terrain strings should be ok (as long as no whitespaces are inside these strings).

[SkeletonCrew]

I just want to add that none of the official WML-Files use the following notation:

Code: Select all

map="
CK
  CK
*"

They only use numbers, "." and "*". So I don't think there are big changes needed. Just using the same syntax as the other WML terrain strings should be ok (as long as no whitespaces are inside these strings).

Thanks for the info, that world make that part simpler. The only problem is we don't know how much user WML code uses it. I wouldn't expect much due to the complexity. If we're going to change it it might be wise to put a warning at http://www.wesnoth.org/wiki/TerrainGraphicsWML and related pages.

[Dominikus]

Why not make the maps UTF-8 ?

- This would change none of the existing maps
- It allowes for editing as usual (with an unicode-able editor)
- it increases the possible terrain-types by far enough
- it provides related letters (a good couple of villages can use v with different accents)

Of course we first should not use characters with problematic properties (like RTL), but there are plenty of accented latin letters, lowecase greek should be unproblematic etc, pp.

That the saved file codes some of the characters as multiple bytes doesn't matter at all (noone should open them with a non-unicode aware editor).
Ok, this requires several changes in the graphical editor, but anything else would be much more time consuming, so what?

[zaimoni]

(noone should open them with a non-unicode aware editor).

Except, of course, that many do open them with non-UNICODE-aware editors now....

[SkeletonCrew]

Why not make the maps UTF-8 ?

- This would change none of the existing maps
- It allowes for editing as usual (with an unicode-able editor)
- it increases the possible terrain-types by far enough
- it provides related letters (a good couple of villages can use v with different accents)

Of course we first should not use characters with problematic properties (like RTL), but there are plenty of accented latin letters, lowecase greek should be unproblematic etc, pp.

That the saved file codes some of the characters as multiple bytes doesn't matter at all (noone should open them with a non-unicode aware editor).
Ok, this requires several changes in the graphical editor, but anything else would be much more time consuming, so what?

Zookeeper already proposed an UTF-8 system, and I'll look into it later. That saved codes are multiple bytes is a big problem, the internal game engine can't handle it. I'm now working to make the internal game engine to work with an integer type instead of a char type. After that the external format can be changed.

[Dominikus]

(noone should open them with a non-unicode aware editor).

Except, of course, that many do open them with non-UNICODE-aware editors now....

But there is realy no need to - unicode editors are available for free for almost every system. And also most old editors supports this in newer versions.

And the internal handling - utf8 to utf32 converter is nearly trivial and also available in hundreds of versions, and chaning the internal terrain-type from char to int should be no problem either.

At least, I think this is the easiest way to go - especially because old maps need not be changed.

[Darth Fool]

At least, I think this is the easiest way to go - especially because old maps need not be changed.

This is undoubtedly because you are used to using UTF-8. People who are used to ascii editors do not have the same sense of what is common as you do.

[mog]

The main problem when using unicode is not the editor but the keyboard. For purposes other than user-visible text, one should IMHO restrict the used characters to 7 bit ascii. It's the least painful way for contributors.

[SkeletonCrew]

and chaning the internal terrain-type from char to int should be no problem either.

That judgement is based upon what??? As the person who is busy doing this I can say it's a royal PITA. Not that it stops me but don't assume it's easy .

[SkeletonCrew]

I created a new development branch at svn.gna.org/svn/wesnoth/branches/mordante_terrain
It's still a WIP. The internal changes are not ready yet so I haven't looked into what's the best external system yet.