Idea to remove the limits of the current terrain system

[Dominikus]

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

That judgement is based upon what???

I got to with unicode-portation at work often. The most heavy part is converting the string-functions (search etc), but all ugly cases like single graphemes consisting of multiple characters should not occur with terrain-types, do they? - thus I concluded that it would be easy.

What do you do internal with the terrain-type that makes it not easy?!?

[Dominikus]

The main problem when using unicode is not the editor but the keyboard.

For things like entering a text I would fully agree. But for a map, simply open a character-table. This is not so different from clicking the desired type in the graphic editor.

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.

A nice decision few years ago - that makes it so easy to change to utf-8 now, because we have not the problem with ambigous meaning of the high 128 byte values in different charsets.

[Darth Fool]

That judgement is based upon what???

I got to with unicode-portation at work often. The most heavy part is converting the string-functions (search etc), but all ugly cases like single graphemes consisting of multiple characters should not occur with terrain-types, do they? - thus I concluded that it would be easy.

What do you do internal with the terrain-type that makes it not easy?!?

"Dear lord, we thank you for granting us the patience to deal with people who do not read the whole thread."

[SkeletonCrew]

"Dear lord, we thank you for granting us the patience to deal with people who do not read the whole thread."

Amen.

[SkeletonCrew]

I've been working on the system and slowly it starts to work again The branch still has glitches but making good progress at the moment. So it's time to look ahead to step 2 changing the single character based system to something new. I looked at the proposed idea's in this thread and there are 3 options to choose from. Since I'm not a major user of the system I'd like to hear the opion of the real users of the system. So I'll list the idea's with some comments and like to hear the options others have. If there's an idea to change the system not mentioned here then let me know.

Here's the list in order of appearance:
1. The orginal proposed idea with the lookup table
This idea is vetoed, since it removes the limit partial and the other ideas remove the limit totally.

2. Zookeeper's idea for UTF-8
PRO
- high backwards compability
- in the proper editor still 1 char is 1 tile
- unlimited terrains
CON
- glyphs are harder to enter
- glyphs can be harder to reconize
- maps can be screwed up when opened in not UTF-8 editor

3a. Jetryl's idea with the multiple letters in comma seperated lists
With this idea we can easily change the letters to a new letter and make them a bit easier to remember. This requires all letters to be at least 2. _If_ we choose for this idea we'll discuss which letters for what, no need to do that upfront.
PRO
- can redefine all letters so they are better to reconize
- unlimited terrains
CON
- harder to make backwards compatible, but has to be done
- the 1 letter is 1 tile no longer exists, still there will be the option to pad data with spaces so the map files still look 'good'

3b. Jetryl's idea with the multiple letters in comma seperated lists
We can keep the old letters but use a comma separated list. I'm not really if favor of this idea since it will get difficult to be backwards compatible. So unless somebody has good arguments for it this will also not be the winner.

These are the options, so have fun with them

[Darth Fool]

I am very happy to hear that you have got the internals working. Believe me when I say I understand what a major bit of work that is.

My preference would be a multi-character comma seperated map where spaces are collapsed (ie they can be used for visual cues but have no meaning) and where in the characters are restricted to letters and numbers. Convention might have it that the first letter be capitalized and symbolize the generic type, but this would not be enforced in the code. I dislike UTF-8 because we DO have people who use non UTF-8 editors, and it is a lot easier to come up with a convention that Vh is a human village than trying to figure out what an o with an accent is supposed to be or some random 4 digit number. Of course, that is subject to interpretation, but the key point is by restricting ourselves to a 26 character set it is still not hard to have as many terrains as we need and still have map that is readable in every editor outthere. I would also like to see numbers not used in the letter scheme, and made to be used exclusively for indicating starting sides. This way it would be possible to start a side on any type of terrain, and not force it to be a keep.

Assuming a comma seperated list, I think a reasonable convention for mainline terrain would be to use the proposed three letters with the first letter indicating the base terrain type (village, mountain, etc...) and the second two as modifiers. Heck, some basic terrains could still have no modifiers as long as trailing space is eliminated. This will require changing a little in the code to deal with shroud, but should be straightforward. A perl (or some other type) script will need to be written to convert old maps to new maps, but this is not difficult, and there are several people, myself included, that could do it once a convention is established. I would suggest that the script naturally makes makes the comma seperated list 1 extra space wide to allow for placing numbers, something like:

Code: Select all

Vha ,Gaa ,Mmm ,Kcc1,AAa ,asgg

two letters might be enough for mainline terrains as I think it unlikely that we will end up with more than 26 variety of villages, but of course by having a comma seperated list, it could be expanded later.

So I guess I am voting for 3A modified a bit.

[SkeletonCrew]

I am very happy to hear that you have got the internals working. Believe me when I say I understand what a major bit of work that is.

Yes now working on the fixing the last issues and starting to test.

Code: Select all

Vha ,Gaa ,Mmm ,Kcc1,AAa ,asgg

Personally I think trailing spaces shouldn't be allowed but only leading spaces.

Code: Select all

Vha, Gaa, Mmm, Kcc1, AAa, asgg

At least *I* think that's more readable, but still I'm not using this stuff a lot.

[mog]

I second Darth Fool's posting.

Additionally, I'd like to have some kind of wildcard in the WML terrain matching code, so you can use e.g. V* instead of Vha,Vhb,Vex,Vdy,... to match all villages. But if the rest of the code works, this should be quite easy to implement.

[edit]
Concerning leading/trailing spaces: I think spaces should have no syntactical meaning. While I agree that leading spaces are easier to read, this should not be enforced by code.
[/edit]

[SkeletonCrew]

Additionally, I'd like to have some kind of wildcard in the WML terrain matching code, so you can use e.g. V* instead of Vha,Vhb,Vex,Vdy,... to match all villages. But if the rest of the code works, this should be quite easy to implement.

I like the wildcard idea, not super easy to implant but I can really see the use for it.

[edit]
Concerning leading/trailing spaces: I think spaces should have no syntactical meaning. While I agree that leading spaces are easier to read, this should not be enforced by code.
[/edit]

Code technical it's no problem to allow them leading or trailing but it was meant to enforce uniform maps.

[Darth Fool]

Additionally, I'd like to have some kind of wildcard in the WML terrain matching code, so you can use e.g. V* instead of Vha,Vhb,Vex,Vdy,... to match all villages. But if the rest of the code works, this should be quite easy to implement.

I like the wildcard idea, not super easy to implant but I can really see the use for it.

[edit]
Concerning leading/trailing spaces: I think spaces should have no syntactical meaning. While I agree that leading spaces are easier to read, this should not be enforced by code.
[/edit]

Code technical it's no problem to allow them leading or trailing but it was meant to enforce uniform maps.

Actually, where I could imagine it being enforced would be if somebody decides later to make saved maps pretty, but that would only be an output thing. during input, spaces should be stripped completely. I don't care one way or the other on whether it should be trailing or leading.

As for the wildcard idea, that is something that would be very good. I have an idea to change the way the map builder handles probability to fix some bugs that is waiting on the new system. The wildcard would certainly fit in with that. Basically, the use of symbols as wildcards and other functional tools is one reason I would like to reserve the legal terrain characters in WML to be only 26 letters, allowing symbols to later be reserved for hardcoded effects like wild cards or something else.

[Eleazar]

Skeleton Crew, thanks for working on this.

So I guess I am voting for 3A modified a bit.

I strongly agree, with these additions:

* "/ | \" These symbols should be allowed for bridges. The direction indication is just so natural.

* Tabs should also be allowed as a "padding" character. Because in most fonts characters vary in width, with some editors tabs could create much more uniform columns.

I can't decide if a case-insensitive system would be overall better or not.

I'd probably come back from my hiatus to work on the WML side once this was ready. I don't believe much (other than this) has changed in terrain since i last was active.

[SkeletonCrew]

Skeleton Crew, thanks for working on this.

Eleazar, good to see you here (If you wouldn't have shown up I would have pm'ed you.)

So I guess I am voting for 3A modified a bit.

I strongly agree, with these additions:

* "/ | \" These symbols should be allowed for bridges. The direction indication is just so natural.

I agree, this is one of the things I had in mind, but I didn't want to start with these details before the decision was made which way to go. _If_ we go for 3a I'll post a proposal with the details. With mog's idea for wildcards I've got some new idea's

* Tabs should also be allowed as a "padding" character. Because in most fonts characters vary in width, with some editors tabs could create much more uniform columns.

I thought of them, but the tab distance can also differ per program, that's why I didn't post it. I don't have the font 'problem' with vim

I'd probably come back from my hiatus to work on the WML side once this was ready. I don't believe much (other than this) has changed in terrain since i last was active.

I don't know, guess Darth Fool knows whether something has changed. Would be nice to see you back

[freim]

Skeleton Crew, thanks for working on this.

So I guess I am voting for 3A modified a bit.

I strongly agree

Ditto

[Jetrel]

* Tabs should also be allowed as a "padding" character. Because in most fonts characters vary in width, with some editors tabs could create much more uniform columns.

I thought of them, but the tab distance can also differ per program, that's why I didn't post it. I don't have the font 'problem' with vim

I agree with SkeletonCrew, and disagree with Eleazar - tabs are very, very variable in size; so much so that most text/code-editing programs have a thing in the preferences to set just how many spaces a tab represents, and have utilities in them to convert tabs to spaces, and vice versa. Tabs have no clearly defined standard for computer screen width.

in most fonts characters vary in width

However, every operating system has a mechanism to use fixed-width characters in it's basic text editors. Most even default to this.

On a mac, you simply set your font to Monaco, or Courier. Poof - done.


I very strongly vote against using tabs; they are an extremely bad idea. Granted, they should just be collapsed like all other whitespace (except return/newline), which means that people could actually still use them , and we wouldn't be doing anything to stop people from using them, but... we should at least conventionally not use them.

[Eleazar]

Skeleton Crew:
If it's not too hard while you are working on this, see if you can get things to work with terrain files in multiple subfolders. The terrain folder is getting unmanagably large, and will certainly continue to grow once more terrain codes are allowed. I don't remember what the technical obstacle was to putting terrain in different folders, possibly it's no longer an issue.



Tabs:
In a decent text editor you should be able to set the width of tabs. It doesn't matter if everyone has the same amount of space between the terrain codes, as long as everyone can get the columns to line up. Maps that use spaces AND tabs would likely be bad.

If we had terrain codes of different lengths in a map (We used up too many of the readable 2 digit codes and need to start using 3 digits, for example) tabs would be more convenient than spaces because 1 tab character will create the right amount of space, even if you change the length of the terrain code. In other words with spaces you have to edit the terrain codes and the spaces in between, but using tabs you only have to edit the terrain codes. A minor but noticable advantage.