Updated extra-large-maps patch, version 12 (for r23992)

[Bilbo]

I have added new version of the patch, see first post to get it. I have also posted the new version to http://bugs.openttd.org/task/1059

Changes from last version:
* When map size too large is selected, the text gets red-colored to indicate it.
* Map size strings are no longer in translation and are generated dynamically
* Limits decreased to "reasonable" values, however increasing them is very simple. Just open map.h and modify MAX_MAP_TILES_BITS from 22 to 26 and MAX_MAP_SIZE_BITS from 13 to 20. This will enable resolutions like 1048576*64 or 8192*8192 (and you'll need cca 1.3GB memory for them). If you have 2.6GB memory or more, you can set MAX_MAP_MAP_TILES_BITS to 27 (or even to 28, but then you'll be unable to load or save such large maps) and have yet larger sizes, etc ...

[CARST]

Hello Bilbo,

it's me again, Carst. Well, i said goodbye to my plan to build a 16k x 8k world map, wasn't perhaps the best idea with the actual versions of openttd and it's way it saves the games. Perhaps in a far future blablabla...

But your last update implicates it is possible to build 8192x8192-maps with 1,3 or more GB of RAM. That would give the opportunity to build a 8192x4096-worldmap with all the capitals and main cities.


So i tried myself to add your patch (with changes max_map_xxx parameters) to the latest nightly and the latest chrisIN but i failed miserably.
I installed cygwin with all correct modules, downloaded the trunk, added your patch with tortoiseSVN, configured without failures, but it just won't compile, no opentdd.exe is created and errors that are nowhere mentioned appear.

Well, i think the error isn't your patch nor the programs, the problem is sitting in front of the screen doing something wrong, but i don't want to rape your thread, too.

So i ask you, would you or could someone else compile the patch with the latest chrisIN to give me the oppurtunity to create my map? I know it's some work, but i don't see me to get that working...


Regards,
Carst



Edit: I also mailed chrissicom if he could include the patch with the possibility to do 8k x 4k (or 8x8)-maps.

[mexicoshanty]

I'd love to play massive maps like this. But atm i'm not even game to try. I get lost in 2048x2048 let lone these sizes. Before they are playable i think we need further zoom out levels.

[Bilbo]

Well, there are some efforts to add further zoom levels, there even was one further zoom level in trunk for some time but it was removed due to horrible artifacts being drawn.

There are some efforts for further zoom levels, like here:
http://www.tt-forums.net/viewtopic.php?f=33&t=34749

... but I think most such efforts ended up only as discussion and I saw no usable patch to solve that issue

There are also some patches for zooming the small map:
http://bugs.openttd.org/task/54
http://bugs.openttd.org/task/1222

I guess one of them may get in trunk relatively soon - these will help in map orientation too..

[CARST]

You got a solution for my problem, too, Bilbo?


Regards,
CARST

[Bilbo]

Your wishes were granted. I have updated the patch for r11781, and I posted both normal version and version with raised limits. The "raised limits" version comes with precompiled windows binaries. It is based on vanilla openttd rather than chrisin, since latest working chrisin is too old (r11355)

See first post of this thread for the files.

[CARST]

Thank you very much for your work Bilbo! Keep up the good work...


Regards and thx,
CARST

[CARST]

Hi Bilbo there seems to be a problem with this build. OpenTTD doesn't some settings. Autosave is set to save every month, i can disbale it or set it to 12 month etc, but the game still autosaves every month. In the config there is always that what i have set (no autosave), but the game still saves every month, very annoying.


But it is playable, i also tested the super-large-maps (8000x4000) on three computers with the help of my friends. Maps can be saves and loaded on computers with 1GB, 2GB and 4GB. I will test with 512MB, too, if a find someone with an PC that old.

So it it would be possible to disable autosave or set it to 12 month, because of the now longer save-times it could be great fun to play these big maps.


Regards,
CARST

[Bilbo]

The problem is with some DEBUG_DUMP_COMMANDS being defined by default (but I have not specified any extra paremters to configure except location to zlib and libpng), basically causing extra autosave every month. Once I figure how to turn that thing off, I'll post updated binaries.

[CARST]

Okay, thx again ... i'll wait for that updated version.

Meanwhile i can spend my time making the 8000x4000 worldmap... just love that game.

[Bilbo]

It turned out it's not anything in configure - glx hardcoded a monthly debugging autosave which can't be turned off (except by modifying the source code)

I have to remove "#define DEBUG_DUMP_COMMANDS" line added in r11772 to stdafx.h to solve that problem

I am including modified patch (the large version) + windows binaries which have this fixed - no more unwanted autosaves.

I reposted this to the bugtracker (as this issue exist also in trunk, except due to the smaller maps and smaller save times it is not so deadly -> FS#1630), so I think it gets fixed in some future revision in trunk too.

[Rubidium]

I reposted this to the bugtracker (as this issue exist also in trunk, except due to the smaller maps and smaller save times it is not so deadly -> FS#1630), so I think it gets fixed in some future revision in trunk too.

As stated in my comment of that bug, it is not a bug but something that we want. We have resorted into this measure to be able to get a bug report into a state where we can reproduce it. To make it anywhere near useful we need a recent save. As we do not know when the bug will occur, we cannot 'just' disable the autosave as that drastically reduces the chances in fixing the bug. Once the bug has been found the 'forced' autosave behaviour will get removed again.

[Bilbo]

Well, yes, I understand that it is desired, but for large maps it makes them basically unplayable. Perhaps turning that feature on only for smaller (1 million tiles or less) maps would be ideal solution.

Or alternatively, turning off compression for those saves. While this would produce larger dumps, it would considerably save cpu time when making them, so even with larger maps that would workquite smoothly.

[Rubidium]

Well, yes, I understand that it is desired, but for large maps it makes them basically unplayable. Perhaps turning that feature on only for smaller (1 million tiles or less) maps would be ideal solution.

Or alternatively, turning off compression for those saves. While this would produce larger dumps, it would considerably save cpu time when making them, so even with larger maps that would workquite smoothly.

Both are basically too much effort for way too little gain... a little faster game for a few revisions. The drawbacks are IMO bigger because it means that when we get the problem triggered we do not have a savegame of it or the savegame is soo big that people cannot get it uploaded to flyspray.

[CARST]

Well, i think the problem will be sorted out fast enough, so the forced autosave can be turned off in the future.

Till that happens, everyone else can use Bilbo's version here.


Thank you very much for your efforts and fast reaction Bilbo...


But one question remains, why doesn't your feature with the super-large-maps (8000x8000) get into trunk? Like mentioned before i made a 8000x4000-map from a heightmap, just created two towns for testing and let some friends test it for me. It worked on 1GB, 2GB and 4GB RAM PCs. Only the forced autosave was annoying for the 1GB and 2GB guys; well that's sorted out now. I have hopes it will work on 512MB RAM, too.

Saving and loading works, so where is the problem, why isn't it in the trunk? I'm missing something? Or are here so many players with 256MB RAM etc? Well i use it on my PDA, too, but i am not so stupid to try a 2000x2000 map on WinMobile, 256x256 is enough here. Perhaps there could be a message if someone starts a map greater than 2000x2000 that saving will take longer on low memory and the game could be unplayable (less than 512MB or 1GB)...

[Bilbo]

Well, yes, I understand that it is desired, but for large maps it makes them basically unplayable. Perhaps turning that feature on only for smaller (1 million tiles or less) maps would be ideal solution.

Or alternatively, turning off compression for those saves. While this would produce larger dumps, it would considerably save cpu time when making them, so even with larger maps that would workquite smoothly.

Both are basically too much effort for way too little gain... a little faster game for a few revisions. The drawbacks are IMO bigger because it means that when we get the problem triggered we do not have a savegame of it or the savegame is soo big that people cannot get it uploaded to flyspray.

They can compress it (zip,7z,rar,gzip,bzip2 ...). I know that this will disappear in few revisions, but for large maps and slow single-core CPU's, the saving takes either significant part of one month of the gametime (compressing cca 64mb of data (2048^2 map) takes quite a long time) or even multiple months (and with large map patch things become MUCH worse). This mean that 90% of the game you are in process of saving, which means the game is extremely laggy during it due to lack of CPU power. This makes it difficult to build anything.

Shouldn't turning off the compression for debugging saves be like setting one flag somewhere? Perhaps one or two lines of code changed ...

[Bilbo]

But one question remains, why doesn't your feature with the super-large-maps (8000x8000) get into trunk? Like mentioned before i made a 8000x4000-map from a heightmap, just created two towns for testing and let some friends test it for me. It worked on 1GB, 2GB and 4GB RAM PCs. Only the forced autosave was annoying for the 1GB and 2GB guys; well that's sorted out now. I have hopes it will work on 512MB RAM, too.

Saving and loading works, so where is the problem, why isn't it in the trunk? I'm missing something? Or are here so many players with 256MB RAM etc? Well i use it on my PDA, too, but i am not so stupid to try a 2000x2000 map on WinMobile, 256x256 is enough here. Perhaps there could be a message if someone starts a map greater than 2000x2000 that saving will take longer on low memory and the game could be unplayable (less than 512MB or 1GB)...

First reason is they don't want to "redesign" the gui (you need to widen a bit the input fields, because 7 digit number is wider than 4 digits number - but you just change size and positions of few input fields, so it is very minor change)

Also, due to this wish from developers I made the patch to be "truly universal" - you just change the limits to something higher and voila - it works (except the strings may be cut off in the GUI and you have to ensure you have enough RAM). So once developers decide to raise the limit, they just modify the three constants. That's it. And yes, they need to widen up the dropdown boxes a bit, but that is few constants changed in the gui definition and the dialog window as it is will not be enlarged by it.

Second reason is that the really large maps are not tested well enough. But enabling really large sizes is basically only way to test it and people playing on smaller sizes won't be affected by any bugs from this. Only bug I think of that may manifest more often is FS#716 , but that bug occurs in current map sizes too.

I think I may solve this by printing estimated memory consumption while the user selects the size (so he'll know to watch the "memory consumption" number not to go over amount of physical ram. In fact, he can go over physical ram slightly, if he enjoys swapping, but that is not our problem :)

I wonder, does openttd have some way of cross-platformly determining (or at least guessing) amount of available RAM?

Well, I made patch according to devs wishes, but I made it so the limits could be easily raised once devs change their mind about extremely large maps (I can supply the patch for widening the GUI elements too, as I can take that from older versions of this patch)

[Bilbo]

I have updated my patch to 11849. See first post for updated patch. As per CARSTs request, I have also combined my patch with "close airport" patch and "2 airports per player per town" patch.

The result (combined patch + windows binaries) is attached to this post.

[CARST]

Yeah Bilbo thanks a lot again, there is nothing i can say else, but just fantastic.


Will be great multiplayer-airplane-gameplay now!

[Bilbo]

Will be great multiplayer-airplane-gameplay now!

Just a word of warning - the version with these two airport patches is not compatible with unpatched version. So you can play only on servers which have this patch installed too.