Alternate terrain generator

[Mlynki]

I have coded an alternate terrain generator (already mentioned some time ago in suggestions forum) and it works including gui and all that, but I ran into some uncertainities. Here they are:

1. I noticed that terrain generator algorithm selection (original/perlin/my new) is not saved across different executions of the game. I think it should be saved so that the user can somehow configure which generator should be used when generating a new game. Now I suppose it is always the 'default' = perlin. What do I have to do to move the variable into save file? Will that introduce any compatiblity problems? Should I do this or not?

2. If I add a new string into the program, do I add it anywhere into the txt files or is there any reasonable order? Namely, do I have to add it to the end of the file or can I insert it near other related strings?

3. My terrain generator works such that while it is running, the terrain stored in _m[] is not valid (height differences in neighboring tiles can be >1). This condition is validated at the very end of generation process. However, while the generator algorithm is running, the progress dialog thread redraws the partially generated terrain and it displays rubbish. I think that the game could also crash in some specific instances of invalid terrain combinations. I found the place where the screen is updated and added a condition not to do it while my generator is running, but, the screen still gets redrawn once... That may be enough to cause a crash. Is there a way to block the screen refresh somewhere so that it does not refresh after the generator algorithm is started? OR does the tile information structure have any member I can temporarily misuse for terrain height instead of using tile_height, so that even if the screen is redrawn during generation process, the game won't crash, just possibly display something strange? I want to avoid creating a new byte in the tile info structure (I already use the 'extra' byte).

Thanks for any help.

Mlynki

[Rubidium]

1. I noticed that terrain generator algorithm selection (original/perlin/my new) is not saved across different executions of the game. I think it should be saved so that the user can somehow configure which generator should be used when generating a new game. Now I suppose it is always the 'default' = perlin. What do I have to do to move the variable into save file? Will that introduce any compatiblity problems? Should I do this or not?

The terrain generator is stored in openttd.cfg, under the name 'land generator'.

2. If I add a new string into the program, do I add it anywhere into the txt files or is there any reasonable order? Namely, do I have to add it to the end of the file or can I insert it near other related strings?

Strings usually get added where it makes sense; you can add them in between. One thing to remember is that all elements of a dropdown menu should be placed subsequently in the language file.

3. My terrain generator works such that while it is running, the terrain stored in _m[] is not valid (height differences in neighboring tiles can be >1). This condition is validated at the very end of generation process. However, while the generator algorithm is running, the progress dialog thread redraws the partially generated terrain and it displays rubbish. ...

I guess you are calling IncreaseGeneratingWorldProgress or SetGeneratingWorldProgress from within generator algorithm, otherwise you wouldn't have 'complained' about the fact that the screen gets redrawn. I wouldn't use extra as that variable might be used later on (actually it is in the newhouses branch already), though you might consider to allocate a new array to store the heights in while generating and copy that data to the new map when you're finished.

However, to give more accurate help, it's usefull to get a view at what you've already done. So please attach a diff of the current state.

[Mlynki]

Thanks for info.

Strings: I did a little menu 'tweaking' in the sense that the current menu doesn't really suit my needs. I needed to add 'mixed' terrain type into it and I decided to change 'very flat' terrain type as well as 'very low' water level to 'random' so that the user has the option not to care. So, the menus I use are partially original strings and partially new ones and they are hot-swapped when different terrain gen is chosen. So, the strings are not necessarily 'in order', but I put them somewhere 'reasonable'.

Screen update: I don't complain, in fact I need the screen the update because I want the progress to be updated. But just the progress window, not the entire screen. Why can't I misuse the tile info structure as I wish when generating terrain? Is there any other process running meanwhile which uses it? I thought that when new land is generated, it is the first thing that ever fills the _m[] array and I return the misused data items to zeros just before finishing...

I shall post the code as soon as I'll be able to. I still need to do some code styling stuff on it though.

[doktorhonig]

Could you also post some resized-huge-screenshots of the generated terrain? I'd like to know, what it looks like.

[Mlynki]

Could you also post some resized-huge-screenshots of the generated terrain? I'd like to know, what it looks like.

You can see some in the OpenTTD suggestions forum under the same topic title ("alternate landscape generator"), there are also some savegames, although they may not be the newest format (I used the latest official release to save them).

[Mlynki]

Here's a patch.
I changed the generator to use temporary allocated arrays, not _m[], during terrain generation.
The patch needs 2 more things to do:
1. code styling rules
2. I need to download a newer nightly and provide diff against that. This one is against nightly 6790.

I have some new questions:

1. I created a new file. How do I get this comment to the beginning of a file? do I care or does the SVN system do that?

/* $Id: gfxinit.h 3183 2005-11-15 08:40:45Z tron $ */

I am not online. I download nightlies at work but program at home and since I have a really slow internet, I work offline.

2. Should the diff contain project file differences? I only added 2 files, but there seem to be many more things modified in the .SLN file.

3. How am I supposed to take care of my temp memory deallocation if the user chooses to abort terrain generation?

[Rubidium]

Here's a patch.
I changed the generator to use temporary allocated arrays, not _m[], during terrain generation.
The patch needs 2 more things to do:
1. code styling rules
2. I need to download a newer nightly and provide diff against that. This one is against nightly 6790.

Please download subversion and then checkout trunk instead of taking the nightly. You can checkout to for example a USB stick and if you install (Tortoise)SVN (TortoiseSVN being a GUI integrated into the Windows Explorer and SVN being the console version) on both your work PC and your home PC, you can easily work with it. When you go to work during the day you can synchronize your working copy on the USB stick and you'll have an up-to-date version every time.

Furthermore you can make unified diffs with SVN, which are better when reviewing as it shows the context of the insertions/modification.

I have some new questions:

1. I created a new file. How do I get this comment to the beginning of a file? do I care or does the SVN system do that?

/* $Id: gfxinit.h 3183 2005-11-15 08:40:45Z tron $ */

I am not online. I download nightlies at work but program at home and since I have a really slow internet, I work offline.

You can add those with (Tortoise)SVN, via setting the svn:keywords property to Id, but I don't know how to do that in TortoiseSVN, with plain console SVN it's 'svn propset svn:keywords Id <filenames>'. However, that line won't automatically change until the file is committed.

2. Should the diff contain project file differences? I only added 2 files, but there seem to be many more things modified in the .SLN file.

It should, but... MSVC has the tendency to modify way more than needed if you do it in MSVC itself. Editting the .vc_proj (there are two) files manually is fairly easy. The .sln files should not be modified. Please add the .c files also to the Makefile, if you scroll through the file you'll see where to add it.

3. How am I supposed to take care of my temp memory deallocation if the user chooses to abort terrain generation?

That's a difficult question; TGP does not call IncreaseGeneratingWorldProgress while it's effectively generating the map. Looking at your diff I would suggest to do the same as it makes the algorithm easier to read because you do not have the 'valid map' constraint. Another solution would be to add a 'abort callback infrastructure' to genworld.

[DaleStan]

/* $Id: gfxinit.h 3183 2005-11-15 08:40:45Z tron $ */

You can add those with (Tortoise)SVN, via setting the svn:keywords property to Id, but I don't know how to do that in TortoiseSVN, with plain console SVN it's 'svn propset svn:keywords Id <filenames>'. However, that line won't automatically change until the file is committed.

Select all <filenames>, right click, select properties, select the Subversion tab, click the obvious button[0], select svn:keywords from the drop-down (or type it in), and add Id to the list.

In other words: Use the console version, and do what Rubidium said.

[0] Possibly the "properties" button, but I don't have a Tortoise install on hand, so I can't check.

[Mlynki]

It seems now that all I need is a svn password to do a commit. Should I get a password (where?) If you need my e-mail, here it is (a bit garbled of course):
mlynki AT host . sk

Or maybe you'd prefer a .patch... I also put one on source forge.

I still don't know about that
/* $Id: gfxinit.h 3183 2005-11-15 08:40:45Z tron $ */
since as I understand it will only appear after a commit (which I can't do) and I also guess that 'tron' is some registered nickname (which I don't have).

[Mlynki]

I forgot to mention, that the memory-deallocation-on-abort problem still needs to be solved.

[Rubidium]

It seems now that all I need is a svn password to do a commit. Should I get a password (where?) If you need my e-mail, here it is (a bit garbled of course):
mlynki AT host . sk

svn access is only for the main developers of OpenTTD, so it's highly unlikely that you'll immediatelly get a svn account.

Or maybe you'd prefer a .patch... I also put one on source forge.

That's not necessary at this point; it's better to wait till you've had some feedback on this patch. Furthermore, sourceforge is not the preferred place to place new patches, http://bugs.openttd.org is.

I still don't know about that
/* $Id: gfxinit.h 3183 2005-11-15 08:40:45Z tron $ */
since as I understand it will only appear after a commit (which I can't do) and I also guess that 'tron' is some registered nickname (which I don't have).

You've understand correctly, and yes 'tron' is one of the developers that has an svn account.

[Mlynki]

I think someone competent should upgrade the wiki pagehttp://wiki.openttd.com/index.php/Development:Main_Page
because there is a link to source forge patch tracker and if the other one is preferred, it should link there or at least also give the other link and say that it is preferred.

Also, I would welcome some information about when to post a patch and where. I still don't quite understand what's the official place for a patch - these forums, the patch tracker or both. And maybe also some answers to my "stupid" questions above could make it to the wiki so that if anyone else not used to SVN can get the info right away.

Thank you all for your help.

[Rubidium]

I forgot to mention, that the memory-deallocation-on-abort problem still needs to be solved.

Thanks for mentioning this problem as it also existed with the TGP generation. Now I've added an abort callback, so one can free the allocated memory.

[Mlynki]

That's great. Do I fix my code to use it & post another patch or you can have a look at it? Either way is fine for me.