Make new tool for the editor to assign names to map regions

[astuur]

A map maker should be enabled to easily assign geographical names to specific regions of a map ("Rattlesnake Pass"; "Mirror Lake", "Misty Ridge")
These names could be referenced in campaignes, tutorial and could be made to appear in individualized names of buildings inside the game.
See ID: 2710481 add format string support for building info.
Creating such names should not be mandatory for the map maker.

[Sigra (sigra)]

XConq claims to have named geographical features: http://sources.redhat.com/xconq/manual/xconq_12.html

This was discussed at:
http://wl.widelands.org/forum/topic/35/

Here are some ideas. A region is a set of locations. Every location belongs to exactly 1 region. When a new map is created, every location belongs to a default region. A new file is created in the binary directory of the map. This file is an array with a 16-bit region ID for each location (just like the file binary/heights stores an 8-bit height value for each node).

One of the files in the map (maybe extra_data) should have a [regions] section:

[regions]
rocky_mountains=_Rocky Mountains
rattlesnake_pass=_Rattlesnake Pass
mirror_lake=_Mirror Lake
misty_ridge=_Misty Ridge

Each key in the section is the name of a region. This name can be referred to in other game data (for example triggers). The value of each key is the descname, which will be visible to the user (after translation). Then there can be a section with additional information about each region:

[rattlesnake_pass]
id=8 109
parent=rocky_mountains

This means that the ID-point for rattlesnake_pass is the node (6, 109). This is where a name label may be shown in the mapview. (This has nothing to do with the 16-big region ID-number in the binary file mentioned above.) The parent key means that the region rattlesnake_pass belongs to the region rocky_mountains. So if there is for example some trigger that reacts for something in the region rocky_mountains, it will also react to that thing in rattlesnake_pass.

The actual user interface in the editor is similar to the one for land usage plans described here:
http://wl.widelands.org/wiki/LandUsagePlans/#user_interface_issues

[Sigra (sigra)]

The main question is whether to implement node regions or triangle regions. It depends on which resolution is wanted. Triangle regions would have twice the resolution of node regions, and require twice as many region IDs stored in memory. Terrain is a property of triangles, so for triangle regions it is possible to say for example that a particular region has 12 wiese1, 8 steppe_kahl, 3 bergwiese and 1 berg1 (or let the editor tool select an area based on terrain and create a triangle region from it). It also depends on what the regions should be used for. Vision, Military Influence and Ownership are properties of nodes, so if regions should interact with these, they should be for nodes. But what if we find out in the future that ownership should be a triangle property in the future? The issue whether ownership should be on nodes or triangles has not been investigated thoroughly.

(But it would actually be possible to implement both independently.) I am currently leaning towards node regions. Then I would make some events and triggers capable of operating on regions, as an alternative to the point/radius that they support now. The events in question are conquer_area, move_view (to the region's ID-point) and unhide_area. The triggers in question are building, military_influence, ownership and vision.

[astuur (astuur)]

At the moment I cannot see much interaction for the region names with eiher triangle or node properties.
If "geographical" regions will always remain geographical - they are very likely to be comprised of similar terrain types. (mountain, water bodies etc.)
But names may also be given to political entities (kingdoms, realms etc) with different terrain. But neither way I see much of a problem, since all of these properties dont need to be referenced so far. Named regions would be quite useful already without this.
However at some point in time a tool for mapmakers could be useful that would compare the productivity of terrains in terms of wood producing, corn, fish etc. to help in evaluation of equal opportunities in starting positions. So yes, a link to the properties could be construed. But that is far off.
Nodes properties could be used for better (more detailed) statistics maybe.
Again it's hard to predict what might be more useful in the future.
I can't comment on the effect of the different amount of data for node and triangle. Do we need to be restrictive with that?

[Sigra (sigra)]

I think that I will leave the event types conquer_area and unhide_area unchanged because they can also be used in initializations (and compatibility with old savegames of scenarios).

Instead I will add the new event types conquer_region and reveal_region. All scenarios should use them instead of conquer_area and unhide_area.

The event type move_view does not really have to be changed. All that is needed is to allow giving a region name instead of a coordinate pair. But the region name is converted to a coordinate pair that is then stored in the event. (When writing, we could search for a region with the ID-point at the stored coordinates and write that name instead of the coordinates.)

All the trigger types (building, military_influence, ownership and vision) should be changed to only operate on regions (not point and radius). This breaks savegames, but only for the scenarios. People should just finish playing their tutorials with their current version. If they really want to keep a savegame, it can be fixed manually.

[SirVer (sirver)]

See also the corresponding blueprint.

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[SirVer (sirver)]

I think this would still be cool.

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/1782