Beta test the new forum at
Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

How to export height map from save files?

Started by jimishol, August 21, 2022, 06:44:55 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I am switching from simutrans - extended to standard.
I will begin from scratch but i would like to play on a map whose terrain is familiar to me already. I tried to enter the same seed number and dimensions of the map but the generated map in standard is different from that generated in extended.
Is there a way to export the height map of my old saved in extended, so as to use "Load Height Map" from starting GUI menu to import it in a new standard game?


As far as I know, no. It isn't a very common situation.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese


For many years I have asked about documenting the (binary) save and object formats, so external programs could read and write them. If we had documentation on what was in those files, I could write a Perl program (or someone else could use whichever other language desired) to do this.


Well, there is an option "saveformat" in simutab.conf to save as xml. I hoped someone could tell me "save in xml and copy paste that part of it, ... etc".


Cut'n'pasting the savefile would be extremely tedious/error prone.
Exporting the heightmap is not a feature...

The generated heightmaps should be the same with all parameters equal (roughness, etc..) upto mapsize 768. After that extended uses some different hardcoded parameters for larger maps. Easiest would be to pull those parameters into a custom .exe to generate your map.


The XML formats are effectively useless.  The save code does not write <height>23</height> as a proper XML format would, just a series of <i8>, <i16>, <i32> and such which are meaningless, and brittle (if you get anything out of perfect order, that crashes the format).  All that code dates from before it was standard practice to use libraries instead of hard-coding everything yourself.  The load/save logic, both for games and for paksets, really needs to use something modern like JSON through a well-known library.


A xml savegame in the i32 style is already 3 GB large, and with the height style it would become easily 10 GB for a 1024 x 1024 map. Apart from needing to touch all call to save routines (and no library could do that for you anyway).

It would be a simple, straight forward task to add another parameter to each rdwr_xxx call, so please go ahead if you need an xml save. Since the XML save are so huge and thus so slow, not much effort was put into them.


JSON libraries do exist. They are not a mystery :O
Compared to xml, json has less overhead, which will reduce the size of such "human readable" saves.

I am not sure if that's worth the effort. I don't think human-readable jsons are a good format for save games because the size will still be huge.
Thus I do not expect the format to be used quite frequently.


"External program readable/writable" is what's important here, not humans.  If there were a way to load and save worlds through a json format, I would be right now writing Perl programs to do all kinds of things.  World creation, reporting, displaying your world on a web page, heck you could write a bridge to load a minecraft world into simutrans. 

Anyone up for integrating an existing json library?