Replacing terrain?

Home Forums Worldographer Replacing terrain?

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #7301

    Hi! First, great software!
    Now my question…
    Is there a way to replace a particular terrain (beyond doing it hex by hex) in the icosaedral map? I want a desert planet and would like to replace ocean, farm, etc with a specific terrain (IE desert rocky)

    Thanks in advance



    Guess I will assume itΒ΄s a feature not available right now…


    I’m pretty sure that’s something you can do. You want to check the Paint Bucket.



    Take a copy (IMPORTANT – in case something gets messed up) of the map file and open it in a text editor.

    Look at how the structure is and then do a simple search and replace operation.

    Save the file again. Test it.

    Repeat until you get what you want.

    But only do this if you have an idea what you are getting into (it is not difficult).



    • This reply was modified 2 years, 8 months ago by .

    Unfortunately the above method does not work in the latest versions (1.026 and possibly before).

    This is due to the fact that each hex in the save file does no longer contain the name of the terrain type (ie. “Border Only” or “Hills”, etc.).

    In stead the save file starts with a definition stating that 0 = Border Only, 1 = Hills, etc.

    The old save format would contain lines like this:

    Border Only 0 0.82 false false 0 0 0 0 0 0 0

    whereas the new save format contains lines like this:

    0 0 0.82 0 0 0 Z

    The format has been substantially changed.

    The good thing about this is that the file size of the save files has been drastically reduced.

    The downside is, that it has become much more difficult to manipulate the data in the save file.

    Personally, I prefer the old version – the save file size is not that important for me.

    I wonder if we can see a description of the save file format somewhere? The new format, that is.

    • This reply was modified 2 years, 7 months ago by .

    Speaking as a developer myself, I personally wouldn’t want users manipulating data in the save files at all. The amount of problems that it can introduce is huge and then it makes reported problems suspect because you can’t trust that the users aren’t manipulating the raw data.

    As far as using codes instead of plain text, I have no problems with it one way or the other. In thinking about this particular program, I would think the deciding factors would be the speed in which you can load or save the data (i/o transactions), perform reads of any code tables you may have, and the amount of RAM you may have to use if you decide to keep those code tables in active memory for faster access.

    Given all of the notes and world information that can be added to these maps (which is one of the design choices that was made early on), I can easily see how the file size can grow to large numbers. I’m just going to take it on faith that file size is important. I know it cut my save file size down to less than half of what it was.

    In any event, all of these decisions require detailed knowledge of the code and I haven’t looked at it myself (and don’t plan to at the moment). I’m just pointing these things out for anyone who may be reading this and not understand.

    Ok, I’m also trying to stick up for the developer who is probably wrestling with things we don’t know about and can’t understand with just our surface knowledge. LOL

    Please don’t take any of this as any kind of personal attack or anything. These are just my opinions based on my experiences. There are many ways to go about programming and while there may be a most efficient answer, there is not necessarily always a single right answer.


    Vargr pretty much has it. The Z just tells the system the remaining values are 0.

    We make it XML so you guys can edit it, but use a copy of course. I don’t mind people tinkering with it but as thevraad alludes, you need to be cautious and I probably can’t spend too much time helping you debug if you get into a bad spot.

    Its on my list to document it, but there is plenty on the list.

    But reducing file size was necessary because some folks were running into an issue where the xml writer wasn’t able to hold everything in its data structures, leading to failed saves. That’s my current working theory. Since the update with the file save changes, no one has reported a save/load issue in 1.026 or later.



    I completely agree with all the points you make – they are all relevant.

    It is basically a bad idea messing with save files – yet there will always be a few out there who for what-ever reasons will attempt just that (myself included).

    I certainly don’t take it personal – I would be hard pressed to find anything at all I could argue was a personal attack in your statement πŸ™‚

    I am making the assumption that if a self-modified save files works when loading and nothing has changed in your map, then you didn’t mess up. Perhaps too optimistic of me πŸ™‚


    I am fully aware (and I fully accept and understand) that you have no time (and probably no desire) to help out guys who by their own folly ends up with useless save files. πŸ™‚

    As for ideas for new features, suggestions for improvements and encountered bugs – would you prefer a mail directly to you or would you prefer to have them in the forum? And in the latter case, one topic per idea/bug/improvement, etc. or one catch-all topic?



Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.
Posted in

In Archive