Topic Removing exact map mode
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to PeterW
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
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.
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.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill