Eleazar wrote:What to do with the ford is open to debate. Maybe it should just be called "Ford". I'm not even sure the dual alias thing is a good idea. (on the other hand i failed to notice that it was dual for months, so it must have been intuitive.)

Bridges also work like fords. Listing the aliases might be helpful (e.g. "Flat / Water" for fords and bridges, "Village / Swamp" for swamp village).

I think this is a great idea, in any case.

Spent about 10 minutes trying to come up with something better than "un-walkable" and failed .

Noyga wrote:Something like this ?
This is (very) quickly and badly drawn, but it shows the idea.
.....
If someone good at graphics can try to make icons around 20x20 pixels (or wider) we could have something great

Using icons isn't really a replacement for having terrain archetype names, there will have to be a tooltip on mouseover.
I'm not against the use of icons per se, i do think they would be hard to make well.
Icons could be added once it's determined that ingame terrains should only be described by their archetype name.

yes, i'm shooting for BWH inclusion here.

Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.-> What i might be working onAttempting Lucidity

OK, i sloppily implemented my proposal:
To see what my proposal would be like in-game, replace data/terrain.cfg with the attached file.
Also ignore anything in parenthesis: ( )
That text is automatically provided by the game. If my proposal was fully implemented, it wouldn't.

I was suprized how many villages were "dual" terrain types. I'm not entirely happy with that especially because the game doesn't make the duality clear. The game apparently ignores how individual village terrains are named in the terrain.cfg, so the attached file won't change that either.

How about mouse over + certain key pressed? Or even better, a "survey" mode enabled/disabled with F[something]. Once on, it could provide very detailed information about terrain type, movement costs, etc. Once off, only the most basic and vital info would be seen on screen.

Eleazar wrote:
Using icons isn't really a replacement for having terrain archetype names, there will have to be a tooltip on mouseover.

That wouldn't work - you must move mouse away from the hex to the info bar!

Good point. In that case, i don't think un-tooltip-able icons can function as well on their own as archetype names.
The idea of a special terrain view may be valuable, but i don't think, it directly effect this proposal. The basic info on a hex is important enough to always display, weather or not there's more detailed into available.

I introduced the subject of terrain archetypes to this other terrain thread. It turned out to be off-topic, and the alias idea should be discussed here.

But a couple minor advantages were brought up:

eleazar wrote:the terrain.cfg IMHO would be easier to work on if there's wasn't a chain of aliases running between terrains. All terrains "aliasing" to one or two predefined terrain archetypes seems harder to break.

skeleton crew wrote:This would make the code a bit cleaner, since at the moment terrain c can be an alias of b which is an alias of a which is an alias of c. The code will handle this infinite recursion but with the archtypes no recursion is needed.

Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.-> What i might be working onAttempting Lucidity

You missed one advantage, there is somebody who want to work on coding this project
I want to start this after the terrain aliassing is finished, the main reasons for doing it after the other systems are:
1) these are separate projects, related but separate.
2) I have enough work on the terrain system as it is and I like to keep my projects a bit small. (and the terrain system is not small )

SkeletonCrew wrote:...You missed one advantage, there is somebody who want to work on coding this project
I want to start this after the terrain aliassing is finished, the main reasons for doing it after the other systems are:
1) these are separate projects, related but separate.
2) I have enough work on the terrain system as it is and I like to keep my projects a bit small. (and the terrain system is not small )

That's more an advantage for the idea rather than from the idea. Still i realize the value of it.

You should work on what you want to, in the manner your chooseÃ¢â‚¬â€ that's been the way Wesnoth Development works. You get positive appreciate points when you can contribute something, but no negative points if you don't do something else. Sometimes good ideas lay dormant for a whileÃ¢â‚¬â€ i'm just glad somebody in a position to implement this idea is interested.

Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.-> What i might be working onAttempting Lucidity

I want to start to work on this idea, the biggest advantage is that the aliasing can be rewritten to no longer allow aliases to aliases which would clean up some code and source for potential problems. I want the archtypes to have the same id as the current "base terrains" that way the unit files don't need to be changed at all. I still want to allow best or worst from the alias list.

There has been some discussion of displaying how to display the terrains, do we wish to use text or symbols? On smaller resolutions an icon would be gain since it takes less place.

Not quite true. Sunken villages act as villages for the purpose of capturing but do not have the village archetype and don't seem likely to get it. Similarly, the Castle and Keep overlays only provide recruiting capabilities, they don't gain the other attributes.

So there's still a need to provide information not present in the archetype. And providing an extra name in only some cases turns out to generate bug reports (http://gna.org/bugs/?19411) as users expect it to always be present.

Now that I think of it, it would probably also be a good idea to label terrain that heals units there as well - the only way to discover that an oasis or UMC terrain heals right now is to move a unit on to it.

Alarantalara wrote:Not quite true. Sunken villages act as villages for the purpose of capturing but do not have the village archetype and don't seem likely to get it. Similarly, the Castle and Keep overlays only provide recruiting capabilities, they don't gain the other attributes.

I'm just saying that we don't need distinguishing labels for terrain graphics that are functionally identical. As i use the term, a hex can partake of multiple archetypes (like a hill forest). If there is a functional difference, yes, i agree it's appropriate to label it distinctly.

Alarantalara wrote:And providing an extra name in only some cases turns out to generate bug reports (http://gna.org/bugs/?19411) as users expect it to always be present.

That doesn't seem too alarming. Any change risks generating bug reports, even when it works as intended.

Alarantalara wrote:Now that I think of it, it would probably also be a good idea to label terrain that heals units there as well - the only way to discover that an oasis or UMC terrain heals right now is to move a unit on to it.

Makes sense.

Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.-> What i might be working onAttempting Lucidity

Alarantalara wrote:Now that I think of it, it would probably also be a good idea to label terrain that heals units there as well - the only way to discover that an oasis or UMC terrain heals right now is to move a unit on to it.

Or an icon could be displayed when moving the mouse over a healing terrain (or a hex that matches a regenerates ability filter) when applicable units are selected, like it’s currently done for the ambush ability and variants thereof.