Merge of the new terrain system - new map changes

[SkeletonCrew]

For the 1.3 branch that wouldn't make sense at this point in time. 1.3 is development which means things can change rapidly. Some changes will introduce a new syntax making the older syntax deprecated and thus the content broken. Eg the terrain syntax will be changed again and might break already converted WML, I'm not happy with that but it makes the terrain-graphics WML much simpler.

We've been discussing on irc about better ways to inform the original author about broken content so that they're aware of the problem.

For 1.2 this might be a good idea, but honestly I'm not interested in doing that. If somebody wants to make such a list and maintain it, I'll sticky it in that forum.

[ivanovic]

Might be a nice idea to start a thread in the Campaign Scenario&Development Forum pointing out which UMCs are broken.
Wish Scott were around, I think he'd have started one already...

I would say that all are broken until they switch to the new syntax. That is why I did wipe the 1.3.1 campaign server from all content. In general I can not recommend using 1.2.x content with 1.3.1, it is likely to lead to problems. We won't even start testing if any campaigns *might* work in 1.3.1.

[SkeletonCrew]

With 1.3.2 with the final version of the terrain system out, I slowly start to drop the backwards compatibility. This cleans up the source and give some speed improvements (which the terrain system really can use).

1.3.2
* Enable the new format (after that the letters won't change anymore
so UMC can really start to convert, adding can of course still happen)
* Not converted to 1.3.1 format UMC's should be removed from the
campaign server
* Enable automatic translation from 1.3.1 to 1.3.2 format on load
this means that the new letter is saved upon saving

1.3.3
* Remove support for 1.2 format
* Not converted to 1.3.2 format UMC's should be removed from the
campaign server
* Enable automatic translation from old keep to human keep
this is required for automatic translated scenarios and savegames
on saving the new letter is saved
* Remove the old human keep from the terrain.cfg's
* Allow wildcard matching and, ! as not, in all terrain filters
Sapient wants to do store_location since there are some more things
he wants to change

These changes mean that 1.2 savegames can no longer be opened in trunk

1.3.4
* Remove support for automatic translation from 1.3.1 to 1.3.2 format

That means that 1.3.1 savegames can no longer be opened in trunk

1.3.5
* Remove support for automatic translation of old human keep

1.5.1
* remove the old letters from the configs and remove the convert
options this means 1.4 will ship with the conversion tools but
the support in trunk will be removed after branching

[Blarumyrran]

that upconvert thingy, is there any place i can download it? (i dont see it in 134 data/tools -_-)

[Sapient]

It got renamed to wmllint, because WML is like lint; it's ugly, but if you have enough of it you can make a sweater.

[doctored]

The terrain branch has been merged and thus the trunk is thawed again.

The only MP map I haven't tested in the team survival map, so if people want to test it and post their findings here I'd be happy.

that map is basically impossible as whoever made it admits when you beat it.

[SkeletonCrew]

For 1.3.10 there are some new map changes, the wiki [1] is already updated.

The basic change is that the campaign designer can now determine the terrains shown at the border.
UMC can be updated with wmllint.
External tools need to be adapted to the new format (parsing the header and ignore the border tiles).

[1] http://www.wesnoth.org/wiki/BuildingMaps

[Quensul]

Just to make sure I didn't miss anything, the only change to the map file format is the addition of the three-line header, right? The wiki description of the file proper appears to be the same as before.

[SkeletonCrew]

And if border_size is 1 the outer tiles are part of the border instead of the map. So the first and last row and the first and last column of a row are part of the border instead of the map. Not sure whether it really matters for wescator.

[Quensul]

Right -- Wercator will just treat the border as part of the map for rendering purposes. Thanks!

[turin]

So... why are .map and .mask two different extensions now? Masks ARE maps, or at least they used to be. And it was very useful to have them the same file type, since it meant you could re-use maps as masks on other scenarios instead of essentially duplicating a file with just a different extension.

[Noyga]

Now there is a difference between masks and maps : maps also have a header for the map border...

[turin]

Now there is a difference between masks and maps : maps also have a header for the map border...

Fine, so why was that change made? It seems like it would be pretty simple to have map files be usable as masks (either include or ignore the border, either one would work), and the current implementation breaks a useful feature.

[torangan]

It's because that way tools can differntiate between them and act accordingly.

[SkeletonCrew]

Now there is a difference between masks and maps : maps also have a header for the map border...

Fine, so why was that change made? It seems like it would be pretty simple to have map files be usable as masks (either include or ignore the border, either one would work), and the current implementation breaks a useful feature.

There was a feature request that the map designer can also define the tiles at the border. The difference between the formats was wanted so I can implement some other features in the future (allow to draw fog in a mask).

For what reason do you use that feature, to revert a map to it's initial state?
It might be possible to add a feature to use a map file as mask as well.