Currently maps are limited to 2^24 tiles. Expanding to 2^26 seems quite possible...
2^2 doesn't seem like much but that's a HUGE jump in maximum map size... 8,192 x 8,192... 16,384 x 4,096
Considering the recent post about map generation times, I wonder if letting users create bigger maps risks locking up their computers for hours with a non-responsive UI.
It's worth noting, in addition to the other anecdotes about map generation, that maps generated without cities or trees etc are fast even at very large sizes. I can't see a compelling reason to keep the 2^24 limit if 2^26 is possible -- you can always put it a health warning about using maps bigger than (say) 4096 x 4096.
Strongly support I was planning to do exactly this modification myself :)
It does limit heights to 64 (-20 to 43) but I don't see this as a huge problem at present.
Edit: Testing highest height differences on landscape I can get in can are around 43 (i.e. -20 to 23) so there's still a few height steps free on landscape. However following limitations are set in simworld:
min: grundwasser-10 (grundwasser can be as low as -20 so lowest heights ingame (tunnels under sea) will be -30)
max: 32 (either high peaks or elevated ways)
So range should be -30 to +33 (i.e. has should use -30 rather than -20). With this there is no capacity to give player a greater range in heights but 64 should be plenty I think.
64 is lots... considering we are playing with 24 and it's quite adequate (even with half height tiles). You can make some pretty hilly maps at 64 :)
The limit on height of mountains is there the have a limit on the map region the display routines have to scan for things that are visible on screen. The current logic could be replaced with a smarter one, which then would allow the full range up to +120...
Quote from: Ters on September 04, 2013, 04:45:42 AM
Considering the recent post about map generation times, I wonder if letting users create bigger maps risks locking up their computers for hours with a non-responsive UI.
There does seem to be something awry with map generation; Using the same settings for a 8192x8192 map, I've seen it take 2 mins, and 30 mins, and everything in between. Trees have been going berserk lately, covering every tile on the map with 3-4 of them! And, interestingly once I get above 6000x6000 or so, then trees start to behave and create forests like it used to...
Quote from: kierongreen on September 04, 2013, 07:33:48 AM
Strongly support I was planning to do exactly this modification myself :)
It does limit heights to 64 (-20 to 43) but I don't see this as a huge problem at present.
Edit: Testing highest height differences on landscape I can get in can are around 43 (i.e. -20 to 23) so there's still a few height steps free on landscape. However following limitations are set in simworld:
min: grundwasser-10 (grundwasser can be as low as -20 so lowest heights ingame (tunnels under sea) will be -30)
max: 32 (either high peaks or elevated ways)
So range should be -30 to +33 (i.e. has should use -30 rather than -20). With this there is no capacity to give player a greater range in heights but 64 should be plenty I think.
Are tunnels allowed -10 below min_height?
I see grundwasser can be set to -20 when double_height is set. Why the difference here?
Bridges/elevated ways can end up at 33 currently. And actually everything can end up even higher due to an apparent bug with dragging the raise land tools - why I left some margin at the top end.
Quote from: Sarlock on September 04, 2013, 02:32:23 PM
64 is lots... considering we are playing with 24 and it's quite adequate (even with half height tiles). You can make some pretty hilly maps at 64 :)
I was debating 64 or 128. Generated maps already don't take advantage of 64, so I thought 2^26 with 64 height might be preferable than 2^25/128. Can easily be changed now if 128 is desired.
Quote from: Dwachs on September 04, 2013, 04:06:37 PM
The limit on height of mountains is there the have a limit on the map region the display routines have to scan for things that are visible on screen. The current logic could be replaced with a smarter one, which then would allow the full range up to +120...
Mountains above ~24 are already breaking the display. I agree the range of tiles scanned needs to be smarter. All I can think of is to use the max height encountered on the last frame to set the scan limits for the current frame. Accepting a possible one frame glitch when scrolling into a higher area.
Water down to -20 was so that height maps could be loaded with pak conversion 2 and still look the same visually as with pak conversion 1 (or single height). Similar effect happens when loading old saved games. Coordinates are all multiplied by 2, so groundwater previously at -10 would now become -20.
That sounds like trouble. Load a map that actually uses the higher heights (or anything above 16), and post conversion the heights are > 32?
Yes, this has to work like this...
Any news on this topic?
Nope, haven't got back to it yet. IIRC there needs to be changes to the double heights stuff and especially this conversion business. The limits need to be the limits - having terrain converted to a height greater than tools are allowed to work at is useless.
inthashtable can work with uint64. The impact on performance and memory is neglible.
With my 2 GB physical memory I cannot test it, but 32766*32766 is now estimated with 70 GB memory needed (and will not perform at all, I am pretty sure ...)
Anyway, go overboard for now.
I'd pulled the limits back from 32766 to 32000 in my test patch above since trying to use 32766 is a guaranteed crash on map generation. 32000 seems to work as I didn't get any crashes. Sizes in between result in an increasing crash chance the closer to 32766 you get. This phenomenon needs investigation...