Moderator: OpenTTD Developers
I wrote a "write tar file" patch a long time ago, and Terkhen started with generic code for handling layers of things (iirc). Unfortunately, the world is full of nice things to do, so this one was pushed to a lower priority.
If you want to work on it, that would be great.
Objects (towns, industry, signs) works fine, however defining spatial objects (rivers, forests etc) in txt files is not very convenient
(by now, instead of defining river tiles, I'm using automatic generation with river beds used to control their flow).
Hybrid bitmap+object txt file format, described by Terkhen, appear to be much better idea, hope that this idea will turn into working code.
It would be great if not only import, but also export is possible, to have opportunity to recreate old maps.
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, preindustrial houses, wired, ECS industry extension, V4 CEE train set.
Addicted to freeciv longturn.
If no one has been updating the thread, you can assume that the project is currently not being worked on. Alberth summarized the status of this project earlier on this thread.Gigigonzalez wrote:Yeah its really sad that the project is on total hold
I wonder if the guy working on this hasnt simply given up. i found some diff files on some openttdcoop ftp i think but it was last updated somewhere in 2013
I welcome anyone interested in this project to continue it where I stopped. My latest patch queue can be found at the following link, although I don't know if Alberth or anyone else did any further work on it. I have not been following OpenTTD development closely so I don't know if it will be very complicated or not to update this queue against current trunk.
The proposed design can be found at the following link. Besides the discussion that can be seen in this thread, other developers helped me in detailing and perfecting it, so IMHO it should be the basis for any future development.
I'll be around to provide advice from now on. I just suscribed to this thread in order to not miss any new posts, and I can also be contacted at the #openttd IRC channel.
I've taken the code from http://devs.openttd.org/~terkhen/patches/scenario/ and made the few small tweaks needed to apply the patches to master. I've then gone ahead and extended it to support loading extended heightmaps from .ehm files (really just tar files, as described on the wiki at http://wiki.openttd.org/Terkhen/Scenario_format); so far only the height layer and the town layer are supported.
The code can be seen at https://github.com/ZornsLemma/OpenTTD/t ... -heightmap. There are some (not very exciting) sample/test extended heightmaps in the eh-test directory in that repository. If anyone would like to give this a try please do, although the code is beta quality at best and while it works for me it may fall over horribly with inputs prepared by anyone else.
You can open an extended heightmap by choosing "Play heightmap" from the main menu and then choosing a .ehm file, or by starting the scenario editor, choosing "Load heightmap" and then choosing a .ehm file from there. There's currently no support for saving as an extended heightmap.
The text files mostly follow the spec on the wiki but have a few small discrepancies; the main ones I can think of are:
- There's currently no default for the 'file' property; you have to specify this explicitly.
- The town layer in metadata.txt is introduced by '[town_layer]' not '[town_file]' as per the spec (an oversight, easy to fix but I won't do it just now)
- The town 'name' property is not optional
- Towns have a 'size' property which takes values small/medium/large/random instead of a 'buildings' property; I couldn't see how to implement the 'buildings' property.
- You can specify a numeric 'radius' property in the [town_layer] section of metadata.txt, and you can override it for a specific town with a 'radius' property in the town file. This determines how far from the specified posx/posy position the code will allow the town to be created if the specified position isn't suitable. It defaults to 5; you can specify 'radius=0' to disable this and only allow the town to be created at the exact specified position.
I'd appreciate it if someone familiar with the OpenTTD code could give this a bit of a review, particularly the comments containing the string "EHTODO:" which indicate what I think are the main potential problems. It would be good to know if the basic approach I've taken to extending the earlier work is sound before putting any more effort into this. The individual commits on the branch are just me talking to myself as I worked on the code; anyone interested in reviewing this should just look at the diff between the last commit on my branch and master.
I should say that the earlier work was really helpful in getting this started; I have very little prior experience with the OpenTTD code and I'd have been struggling to find how to plumb my changes in properly without it.
I worked on this too back in 2017 apparently, but moved to generalizing tar handling in the game and drowned
Have been mostly inactive since and lost my commit access.
However, I still have some patches that may be of use to you:
Code: Select all
@ 22495[170_HACK_test_save.patch,qtip,tip] 412579e5c14e 2017-01-01 14:01 +0100 alberth | bool SQVM::CreateClassInstance(SQClass *theclass, SQObjectPtr &inst, SQObjectPtr &constructor) | o 22494[1_load_scenario2.patch] c7243449ebca 2017-01-01 13:59 +0100 alberth | [mq]: 1_load_scenario2.patch | o 22493[1_hack_load_scentar_crashing.patch] 42c8bff73e28 2017-01-01 13:59 +0100 alberth | [mq]: 1_hack_load_scentar_crashing.patch | o 22492[1_load_scenario_code.patch] b055a59641b3 2017-01-01 10:11 +0100 alberth | imported patch 1_load_scenario_code.patch | o 22491[1_split_tarfile_processing.patch] e12dc924a93b 2017-01-01 10:11 +0100 alberth | imported patch 1_split_tarfile_processing.patch | o 22490[160_hacking_save_to_honour_sct.patch] 6e82785ad567 2016-12-31 22:41 +0100 alberth | imported patch 160_hacking_save_to_honour_sct.patch | o 22489[150_add_saving_scentar.patch] 45c200562b5e 2016-12-31 22:41 +0100 alberth | imported patch 150_add_saving_scentar.patch | o 22488[140_add_scentar_fiostype.patch] e4a230f4b219 2016-12-31 22:41 +0100 alberth | imported patch 140_add_scentar_fiostype.patch | o 22487[130_fios_gui_save_dft.patch] 325945e2186d 2016-12-31 22:41 +0100 alberth | imported patch 130_fios_gui_save_dft.patch | o 22486[120_screenshot_dft.patch] 740bb396f199 2016-12-31 22:41 +0100 alberth | imported patch 120_screenshot_dft.patch | o 22485[110_add_scenario_save.patch] abe41ee141ee 2016-12-31 22:41 +0100 alberth | imported patch 110_add_scenario_save.patch | o 22484[100_improve_screenshot.patch] 0446481c2487 2016-12-31 22:41 +0100 alberth | imported patch 100_improve_screenshot.patch | o 22483[090_prepare_screenshot_filehandling.patch] 19e454005146 2016-12-31 22:41 +0100 alberth | imported patch 090_prepare_screenshot_filehandling.patch | o 22482[080_add_tarfile_writer.patch] d8d910221723 2016-12-31 22:41 +0100 alberth | imported patch 080_add_tarfile_writer.patch | o 22481[070_add_tar_format_writer.patch] c38a13e4beba 2016-12-31 22:41 +0100 alberth | -Add: Tar format writer class | o 22480[060_write_ini_as_stream.patch] 68094efbeebd 2016-12-31 22:41 +0100 alberth | -Codechange: Write config file through an output stream | o 22479[050_split_write_ini_file.patch] 2a97ab991e7e 2016-12-31 22:41 +0100 alberth | -Codechange: Split writing the INI file in file creation and file renaming. | o 22478[040_screenshot_changes.patch] efc44334d95c 2016-12-31 22:41 +0100 alberth | -Codechange: Use the proxy class to write images. | o 22477[030_filewriter_class.patch] 0993461da34f 2016-12-31 22:41 +0100 alberth | -Add: Proxy class that can act as destination for an output stream. | o 22476[020_unglobalize_screenshot_formats.patch] 3ef5fa07f0a3 2016-12-31 22:41 +0100 alberth | -Codechange: Remove _num_screenshot_formats, reduce scope of _cur_screenshot_format. | o 22475[1_document_tarfile_datastructs.patch] 42a67323cad9 2016-12-31 22:41 +0100 alberth | imported patch 1_document_tarfile_datastructs.patch | o 22474[1_remove_unused_function.patch] 646b6239ffe0 2016-12-31 22:41 +0100 alberth | imported patch 1_remove_unused_function.patch | o 22473[010_squirrel_compile_fix.patch,qbase] c9b28abd08f0 2016-12-31 22:41 +0100 alberth | imported patch 010_squirrel_compile_fix.patch
No idea if any of this is stlll relevant or mergeable at all. IT's in Mercurial, so first step would be to move it all to Git. Some of it looks like it could become a separate pull request.
Edit: Created a branch in https://github.com/Alberth289346/OpenTT ... o-tarfiles for the patches up to 22489, except the last patch has no road support anymore, as we now have road-types so my code was obsolete. 22490 and higher moves to loading tars, which I eventually got stuck, so likely nothing useful for you there. Code compiles, but I didn't actually try to run the code again.
Also, other OpenTTD developers may have different opinions.
Alberth - I've had a quick look over your code and it looks like it might well be useful when/if I get to the point of trying to support saving an extended heightmap from OpenTTD, so I'll come back to it then and take a look in more detail. Thanks for this, it could well reduce hair-pulling later on, and I appreciate you taking the time to put it in git for me!
I've opened draft pull request https://github.com/OpenTTD/OpenTTD/pull/7664 for this so I'll wait and see if anyone is interested in reviewing it there.
I don't normally use IRC (I think I tried it once about 20 years ago and found it confusing and a bit intimidating, though that was some general chat channel not one for a particular project) but if someone is particularly keen to discuss this with me we could probably arrange a time to meet up on there for a chat if that's easier than exchanging comments on the pull request or whatever.
Users browsing this forum: No registered users and 1 guest