My crystal ball tells me you will find your very answer in the post above if you look closely enough!

Well, "Peter" was taken already in euIRC. Ironically, it's free again these days.

Basically since I changed it while optimizing runtime join data size. Here's the story: The old situation was that you could have a number of landscape modes - dynamic, static or exact. Saving would fix this to "exact", which would save a dump to Landscape.bmp that would later read in completely bypassing all the zooming code.

That's a workable idea as long as you're talking local game saves, but really bad for runtime joins. As the landscape probably hasn't changed much since the start of the game, ideally you'd want the joining client to regenerate the original landscape using the same process that the other clients used at the start of the game. Afterwards, it is just a matter of applying some small "diffs" to get up to speed.

For that, it is obiously a very bad idea to "switch" the landscape to exact mode, especially if it overwrites the map in the process. Therefore I changed the system to not switch over to "exact", but just have the savegame creating code put in a "diff" if requested (only case where we wouldn't is when saving as scenario).

Now this has lead to quite a bit of dead code and confusion on the GUI side: The user interface still looks like you could "switch" it over and CR-newbies always get confused when it doesn't work. What's actually happening is that you're working on different data: For "static" you're editing the map (which gets synchronized to the landscape) while for "exact" you're only editing the landscape with no effects on the map.

The patch now kills all the dead code (well, sections were using it, somebody should check sometime whether I've broken them), and disables the exact drawing tools until we find a clearer way of representing them in the user interface - as a start, I converted the drawing mode in C4Landscape::Draw* to a flag, and also made them write the landscape and map at the same time. So maybe we could make a checkbox out of it that warns that using "exact" drawing shows you more detail than saving as scenario will retain.

It's kind of a messy subject - I still think this is what should be done, but as it now involves breaking pretty much every developer mode out there, I thought we might want to discuss it first.

> A enum or flags argument or a separate function is a lot more readable.

I know the argument, but really? An experimental parameter to three functions that we don't even know wether we'd like to keep? You want to give that its own type? Let's not go overboard here.

> Thinking about this, a way to convert landscapes back to maps would be nice.

Hm, I was under the impression that there is already code for that? Can't quickly find it though. And we should really not encourage anybody to use a static map with map zoom of 1, even if it's technically possible.

Mostly agree on the rest, even though changing landscape size and zoom doesn't really sound too useful to me.