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

[Bilbo]

Well seriously.. eventually we may get to this point if we solve obvious issues like the need to download a full map every time a user connects to a server.

Due to way the multiplayer works now (everybody runs a copy of the simulation as run on server) it would be impossible to avoid downloading a full map without basically rewriting network and some internals from scratch ....

[Mchl]

Thread from suggestions forum with an interesting idea concerning large maps.

[peter1138]

speed was reduced not to 1/4 but 1/12.5 (in 0.5.x, perhaps it was 1/4 in orig. game)

No it wasn't. It was always a quarter.

[Bilbo]

speed was reduced not to 1/4 but 1/12.5 (in 0.5.x, perhaps it was 1/4 in orig. game)

No it wasn't. It was always a quarter.

See http://wiki.openttd.com/index.php/Game_Mechanics

-> "Aircraft fly at 8% their listed speed."

But when I tried it in 0.5.2, it seems that in reality it is a quarter. So probably the wiki is wrong ... ]
Wonder who and how someone dig up that 8% ...

[Mchl]

'Who' part of your question is easy to find out. 'How' is still waiting to be solved.

[peter1138]

Never believe anything written on a wiki

[Bilbo]

Hmmm .. in trunk planes use different speeds anyway ... I'll wait for 0.6.0 and then I'll fix it :)

BTW new version of large maps patch (version 5) is now here (fixed selected resolution clamped to 2048 when it is saved in openttd.cfg)

[Bilbo]

I have posted updated version 6 of the patch.

Updated version only removes workaround around bug that was fixed in 10719, so for 10719 and newer, use version 6 of the patch, for older versions use version 5.

[RainierWatcher]

I tried the planes on the maximum length, didn't realise quite how long it would take, as it seems to be approximately trans atlantic distance timewise, got bored after my dinger 1000 had done a tenth of the distance. Fast forward didn't do much either, so it was a problem. Plus if you have the ChrisIN, the optimum distance for a plane can be given, and it's about 4000 squares, rather than 262,000 or whatever it is.

Good patch, but far too big unless someone makes a scramjet GRF or something suborbital.

[Bilbo]

When I've done the calculations, I estimated the optimum distance to be 4000 for ~950km/h planes and 10000 squares for dinger 1000.

So maps up to 8192 or 16384 long are still usable for end-to-end routes even with current aircrafts. For larger maps, you have to build shorter routes or wait for some GRF with faster planes

[Wolf01]

or use the daylenght to be able to travel the map in one month (which is still unrealistic), i've never seen an aircraft which took a year or two to travel around the Earth, also there is the novel "Around the World in Eighty Days" which tell it

[dimon22_g]

Wow! 9 year for a concorde to get to the other side of the map. Impressive.
I was playing on a 16k x 256 map and built the direct rail line from 1 side to another. It takes about 3 years for a fast train (about 200 kmh) to get to a separate side. There are a few stops between, however.
But concordes make it quite fast especially compared to 9 years mentioned.

[chrissicom]

Well for such large maps and "slow" vehicles the daypatch really does its job to make the game a little more fun imho, I always play at settings from 3 to 5 making the game not take forever but reduce travel times to a bearable amount What might be a good idea though is turning off impossible settings in the patch since a map with 64 length x max width doesn't even load with 4 GB Ram, 10 GB Paging File with a 64-bit version executable. I think the problem is, that the current game engine simply isn't meant to be able to allocate so much memory.

[Bilbo]

map with 64 length x max width doesn't even load with 4 GB Ram

That's weird. Max. width is 262144, so 64*262144 = ~ 16.7 million squares. Since one square is 9 bytes, you end up with cca 150Mb for map array. Add some memory for saving and other stuff ... but you are still under 512Mb ram usage.

If it doesn't load, it is a bug somewhere. Does it happen only with 64bit executables, or with 32bit too? Currently I have only 32bit systems here, but I may try it on 64bit linux ...

[chrissicom]

It happens with both executables, I usually play with a 32-bit executable because I am too lazy to compile the 64-bit version as it's not needed anyway as long as I can run 32-bit on a 64-bit system.

[Bilbo]

Hmmm ... I saw no problem when compiling with 32bit MINGW .... all map sizes worked fine.

What system and compiler do you use?
Do you see any warnings during the compilation?

[chrissicom]

I am on Vista 64-bit and use MSVC 2005 and Orcas (2008 Beta). I have no compiler errors, but the game crashes on certain map sizes long before the allowed amount of RAM for a 32-bit app (and that limit doesn't even exist for the 64-bit .exe) is reached. I also think it would be nice to somehow give a warning or disallow map sizes that won't work like max. x max. patch setting.

[Bilbo]

I am on Vista 64-bit and use MSVC 2005 and Orcas (2008 Beta). I have no compiler errors, but the game crashes on certain map sizes long before the allowed amount of RAM for a 32-bit app (and that limit doesn't even exist for the 64-bit .exe) is reached. I also think it would be nice to somehow give a warning or disallow map sizes that won't work like max. x max. patch setting.

But these are already disallowed - maximum is 4096*4096 (or any other size with this much or less squares)
Are you using the latest version? Or is the limit limiter not working?

[CARST]

Hello ...

first i want to thankyou bilbo for that patch. Really cool, everything a "TT-megalomaniac" can think of. Some month ago i made a Europe-map from SRTM-data on 2048x2048, now i can double the size.


But i have another question. Will it be possible in feature to make maps larger than 4096x4096 (or relative similar size)?

I made a black-and-white-PNG from SRTM for the whole world and really would like to import that to OpenTTD. Because the (in the PNG) included part of the world (without the poles) is nearly double as width as high i would have to use something like 4096x2048. But i think that is too small.

So here is my question:
Will it be to make (lets say) a 8192x16384 in future releases and be able to save games with them, too?


Regards,
CARST

[Bilbo]

But i have another question. Will it be possible in feature to make maps larger than 4096x4096 (or relative similar size)?

Yes, it will. But unfortunately, each tile requires about 10 bytes of memory (plus another 10 when saving the game), so 4096*4096 map need at least 320MB of memory (plus something for the code, vehicles, etc ..). For 32bit architectures, which can't go over 2GB for all the data the limit would be 8192*8192, for 64bit architectures it could be even more - if you take my patch and just modify the limit, it should work fine, BUT problem can be the tile loop (every second certain percentage of tiles is updated, too much tiles -> CPU can't keep up, aleso larger map = more cities, industries, etc and more "update" functions per second needs to run) and memory consumption (8192*8192 maps would need aboud 1.3GB memory. Not eveybody have that)

Basically, 4096*4096 is most what nowadays "not-so-bad" computers can handle (assuming 2.0-3.0 Ghz single core processor with at least 512Mb ram), so there isn't much point in allowing even larger sizes - bascially nobody have hardware good enough to run them.