Transport Tycoon Forums

first computer i ever owned.....had 1 Gb of ram since i first bought it LOL

threw out a second hane 700Mhz computer with 192Mb ram.

perhaps i am spoilt

Alltaken

[quote]there is no need to get any bigger than that.[/quote]

Reminds me of that famous quote of Mr. Gates's:
"no computer will ever need more than 64kb [or whatever] or RAM"

Even OTTD wouldn't run on that. ;p

off topic on topic
I still think you should leave the possibility open to increase map dimentions. You never know when you may need it.

It would be a good idea to limit the mapsize (1024x1024) to prevent accidental large maps. Maybe you could code a commandline option to disable this limit if you'd want to test larger map then the default max.dimention.

- Just an idea -

Well given that there's been a lack of info regarding the development in the last fortnight I could be forgiven for thinking us bigmap users are stuck with the crappy 3.1 version eh?

Trainskier1406 wrote:Well given that there's been a lack of info regarding the development in the last fortnight I could be forgiven for thinking us bigmap users are stuck with the crappy 3.1 version eh?

I would like to second this statement. (i.e. pretty please with sugar on top: when will we see bigmap in 3.2, if at all?)

I would like to ask another thing - when will bigmaps be added to OpenTTD officially? (no patch required to use it)

Mad Dog McKill wrote:I would like to ask another thing - when will bigmaps be added to OpenTTD officially? (no patch required to use it)

Maybe, maybe not For now, we are simply waiting till some changes are made in the source... where some is an understatement

Let me guess: the new landscape array? That has also halted development on my shared track patch.

Its amazing how people say my computer has 64Mb of RAM, so who cares.

What about the people who have less than that? eg. My slightly older computer only has 16Mb of RAM, and the original PC I ran TTD on only had 8Mb... and what about people who are good enough to port the game to another platform (such as some form of PDA) or have enough patience to try and convert to a C=64 (with 64K, tehehee )

I think the best option is,
* Have the maps as large as people want them, BUT only if they download the source code and compile with a command line switch, eg. (for when ottd gets a configure command)
./configure --mapsize=65535 --yes-i-have-100Gb-ram
make all


The default should be 1024, with another version posted for thoose who want to stay at 256 (or what ever it is now) -OR- since OTTD should at some point have a good installer for most systems it could be choosen (or detected) at that point which binary to install.

Now that my two cents have been made and the problem should be sorted can we get to where things are at at this point, eg. do u need any help or have the testers had problems?

nzhook wrote:I think the best option is,
* Have the maps as large as people want them, BUT only if they download the source code and compile with a command line switch, eg. (for when ottd gets a configure command)
./configure --mapsize=65535 --yes-i-have-100Gb-ram
make all

Remember that having people compile OTTD themselves only is an option with Linux-users, as most Windows-users are somewhat clueless when it comes to compiling stuff, and usually doesn't have the right programs to do it

I know, I work with Windows users everyday... ((sorry to be insulting to anyone who does know how to do this)) they are also the most likly to complain when they download the largest maps possible and it dosnt work, hence 1024 is proberly suitable for a standard download anyone who wants better would need to have the knowledge to compile the source.

When bigger maps will be an official feature in OpenTTD, they will be dynamic, meaning that you can change the map size for each new game to anything you want. But that's the reason why it will take very long until it'll be implemented. It is not too hard to change it from currently 256x256 to 1024x1024, but we don't want a inreversible change of the size.

Well if it's gonna be a very long time how about an update for the so-called bigmap?

Trainskier1406 wrote:Well if it's gonna be a very long time how about an update for the so-called bigmap?

You should ask that to the people who have created the biggermaps version. Mainly Korenn who has made the 'biggermaps challenge' AND STILL HASN'T RELEASED THE SOURCE!!!! , or maybe Truelight who has done just a 'simple' bigger maps version.

dominik81 wrote:When bigger maps will be an official feature in OpenTTD, they will be dynamic, meaning that you can change the map size for each new game to anything you want. But that's the reason why it will take very long until it'll be implemented. It is not too hard to change it from currently 256x256 to 1024x1024, but we don't want a inreversible change of the size.

Dominik, the patch for dynamic maps is in SF...
And to make the map bigger then 256x256 will take me about 2 hours of work.. it is not that hard, it only needs merging in SVN

Darkvater wrote:

Trainskier1406 wrote:Well if it's gonna be a very long time how about an update for the so-called bigmap?

You should ask that to the people who have created the biggermaps version. Mainly Korenn who has made the 'biggermaps challenge' AND STILL HASN'T RELEASED THE SOURCE!!!! , or maybe Truelight who has done just a 'simple' bigger maps version.

Does his version have fixed AI?...and why normal OTTD still has bugged AI that buys 3 passenger wagons and 1 mail wagon on 5 square big station when it should be 3 passenger wagons and 2 mail wagons...their trains are always 1 wagon to short.

TrueLight wrote:Dominik, the patch for dynamic maps is in SF...
And to make the map bigger then 256x256 will take me about 2 hours of work.. it is not that hard, it only needs merging in SVN

What your patch does is setting up a static big map at compile time. And in the game it only uses a part of it then. As Vurlix put it:

Vurlix wrote:That's quite a dirty patch. Most likely going to be rejected..

And I'm afraid I have to agree with him, it's a hack and not a clean implementation. I suppose that some people like it anyway (most users don't care if the code is clean, do they ), therefore I suggest that you make a binary of that biggermaps version and release it every once in a while.

dominik81 wrote:

TrueLight wrote:Dominik, the patch for dynamic maps is in SF...
And to make the map bigger then 256x256 will take me about 2 hours of work.. it is not that hard, it only needs merging in SVN

What your patch does is setting up a static big map at compile time. And in the game it only uses a part of it then. As Vurlix put it:

Vurlix wrote:That's quite a dirty patch. Most likely going to be rejected..

And I'm afraid I have to agree with him, it's a hack and not a clean implementation. I suppose that some people like it anyway (most users don't care if the code is clean, do they ), therefore I suggest that you make a binary of that biggermaps version and release it every once in a while.

Hehe, you devs should get on one line, really!! I first made a patch which had a completely dynamic map, but that was rejected by ludde, because it was slower. Better was to use a static X-size map, and make it dynamic in that. Now I done that, it is rejected because it is X-size static... I am lost... really, I am......

For the rest, Vurlix said it was dirty, because, in his words, I used 256 and 65536 hard-coded. He did _not_ look close enough at my patch, because those numbers can not be done any other way, because it was for backwards compatibility.

This is not ment as flaming, I like OpenTTD, and I am working slowly towards a nice new AI. Never the less I find it difficult that so many devs have so many different opinions, and they don't get on one line..

ps: I don't agree that it is a hack: it is as clean as it can get if you want to keep a static X-size... which was ludde his request.

pps: what the patch do is very much not make a static map, and use a part of it. Is set's up a dynamic map, with a static x-size, to keep it as fast as possible. This way TILE_XY and GET_TILE_X are done at build, not at runtine. Which gives a big speed increase for a little penalty in the memory. Remember: 6 _map array, 65k each, is about 500k of memory... I mean: even my 486 could handle that in his low-mem

Sorry, TrueLight, I didn't mean to confuse you. A patch like your bigger maps patch is of greater magnitude than the average "new feature" patch. That's why the implementation has to be discussed. You've heard Vurlix' opinion, you've heard mine, but what counts in the end, is ludde's. You will have to ask him to commit it anyway, because only ludde commits big changes like this.