News:

SimuTranslator
Make Simutrans speak your language.

Expansion of custom maps

Started by Leartin, February 21, 2019, 12:28:06 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

https://forum.simutrans.com/index.php/topic,18783 <-- For reference


  • DrSuperGood added the ability to see the map seed when expanding the map, but not (yet) to edit it - which is good for normal maps (especially since you could never retrieve it after you lost it), but it seems a missed opportunity to allow custom maps to be expanded by entering your own seed, as those maps wouldn't have one.

  • But this wouldn't be a request by me if I wouldn't overdo it. So instead, I request expanding custom maps based on a heightmap. ;)
    If you start a game with a custom map (via heightmap), the complete heightmap is used. To my knowledge, each pixel is a tile, and there is no way around it. I'd quite like it if you could, at this point, cut out a rectangle from the heightmap to use as your playing field. Hence if you don't use the complete map at the start, you would be able to expand it later. Basically, instead of a seed, you'd have a reference to the heightmap used.

    But more commonly, a player would choose a map of the size he want's, not part of a larger map. So I'd like to be able to edit the map after the fact, to expand it in different directions. Maybe I have a too simple mind, but exporting a simutrans map to a heightmap should be rather easy, given that the overview-map is essentially the same thing with different colors. I suggest the top right pixel would be red. (#FF0000) Hence, even if you expand the graphic to the top or left, you'd still find the red pixel and know where the original map started.

    So at this point, I'm asking for: Choosing which part of a heightmap should be used, expanding a map based on what's in a referenced heightmap, and exporting the heightmap from a running game, in case you want to expand it by drawing something. To me, this sounds reasonable. So still, not enough for me to request :P

  • If you were to export a heightmap, you could also export other information. For example, location and size of towns, location of rivers and forests, locations of factories and curiosities, climates,... for the most part, these things can be displayed and listed in the game as well, so that wouldn't be the problem. The hard part would be an importer, that could generate a new map with all the information exported before. Now, if those information were exported in human-readable format so they can be edited directly, it would be great - but even if not, you'd have a new dimension of custom map design.

DrSuperGood

QuoteDrSuperGood added the ability to see the map seed when expanding the map, but not (yet) to edit it - which is good for normal maps (especially since you could never retrieve it after you lost it), but it seems a missed opportunity to allow custom maps to be expanded by entering your own seed, as those maps wouldn't have one.
It also opens up the opportunity for people to lose their map seed number forever by accidently modifying it, unaware that they might need it again in the future to expand their map seamlessly. To prevent this kind of problem one would need to have the field as read-only unless explicit confirmation is given to modify it (eg an unlock toggle).

This would be a non trivial UI modification. So instead I did the quickest possible solution to display map seed number to meet the requirements for now.

Leartin

As I said, if you lose your original map seed, you wouldn't be able to retrieve it. I agree that just allowing to edit it would be a bad move.
However, somehow the game knows that it's a custom map, since it does not expand those. Custom maps would not have this problem in the first place, since their seed is somewhere between non-existent and useless. Hence if the field is read only in case it's a generated map, but editable if it's not, you wouldn't need explicit confirmation. (No idea if that is any more trivial though)

Ters

I thought the reason why the seed is in the map in the first place, is because the map can not be reliably expanded using any other number. That only the original seed will generate new terrain that matches the edges of the old.

Leartin

Quote from: Ters on February 21, 2019, 05:57:30 PM
I thought the reason why the seed is in the map in the first place, is because the map can not be reliably expanded using any other number. That only the original seed will generate new terrain that matches the edges of the old.
Exactly. Which is why it's hard to believe there would be any reason to change the map seed of a generated map. But for a map made via heightmap, the option to expand without a matching border would still be better than no option to expand at all. Choosing the seed, one can hope there is one that almost matches, making the seam less appearent, and landscaping tools can help smoothen it further. Not ideal, but it's something.

prissi

The enlarged map would have no valleys, but deep slopes, because the smoothening algorithm will run over it after generation or the raw values. Other than that it will be continuos, and some may even like the challenge of such features.