Simply enlarge the map (I am enlarging from 512x512 to 768x768), and I got the newly created land that does not connect with existing land, and having sudden change in altitude at the edges.
Also, there is no industry in newly created land (Though this also happens in Standard)
Though, it appears a good challenge in this case - this road is going to be the steepest road in the world which cannot be produced by normal means ;D
(http://i.minus.com/ibeGBcVTKs5kha.jpg)
I just tried this out in 10.8 and could reproduce this easily :( ..... On the other hand .... I love the waterfall in the river :)
Hmm - this is interesting. I don't think that I have changed the code for land generation. I presume that this is not reproducible in Standard?
(The industry thing, I think, must be intentional, since enlarging the map is a separate function to increasing industry density).
Interesting behavior. Standard exhibits a bit of this tendency:
STANDARD:
(http://www.ssgholdings.ca/simutrans/images/map-expansion-standard.png)
With each expansion of the map there are lines left in the sea bottom but no effect on the land (and thus has no effect on gameplay, it just looks funny). With Experimental the same thing occurs except, strangely, when increasing to 768 it impacts the land as well. It doesn't seem to happen again after this size (though I only went to 1024x1024). What is so special about 768?
EXPERIMENTAL:
(http://www.ssgholdings.ca/simutrans/images/map-expansion-experimental.png)
Ohh, I think that I might know what causes this - but fixing it is another matter. Experimental is optimised for larger maps in a larger scale, so, at larger map sizes, the landscape shape is represented on a larger scale to give a more plausible map with larger scale features. If one expands the map to over this threshold, I can see how it would cause an inconsistency. May I ask - does the large change in height (etc.) occur on all expansions, or only on those that take the map over a certain threshold?
I wonder whether the answer may be simply to have the larger scale applying to all map sizes. However, if this were done, there may be many smalelr maps generated that were either all ocean or all land.
Thoughts on how to deal with this would be welcome.
Quote from: jamespetts on September 26, 2013, 12:10:58 AM
Experimental is optimised for larger maps in a larger scale, so, at larger map sizes, the landscape shape is represented on a larger scale to give a more plausible map with larger scale features.
Ideally, height maps would be fractal, and therefore scale invariant (at least over the relevant range of sizes).
Quote
I wonder whether the answer may be simply to have the larger scale applying to all map sizes. However, if this were done, there may be many smalelr maps generated that were either all ocean or all land.
I don't see that as a problem. If the minimap overview in the map generation dialogue shows nothing but water, you can either choose a different seed or adjust the sealevel.
Best wishes,
Matthew
The ocean depth level looks cenrainly like unextepected behaviour in standard, I think I recall having seen it while I developed the world limit removal, and forgot fixing it. :)
I'll have it a look. On the other isssue, you should use the same terrain generation functions, no matter what the size, imho.
Thank you both for your feedback on this. Markohs - can you let me know in this thread when/if you fix the Standard part of this issue? I should be very grateful.
sure
Thank you!
Quote from: jamespetts on September 26, 2013, 12:10:58 AM
I wonder whether the answer may be simply to have the larger scale applying to all map sizes. However, if this were done, there may be many smalelr maps generated that were either all ocean or all land.
Well, you can allways try to detect that situation and make the algorithm detect if that undersired situation will appear *allways*, not condidering map size.
generate_map_pre(params,requested_size){
if(the_map_will_be_not_desirable_on_the_first_750x750_tiles()){
adjust_params_to_avoid_this(¶ms)
}
generate_map(params,requested_size);
}
It looks like there is an another threshold at 2048 mark. (enlarging from 1200 x 2047 to 1200 x 2176)
Yes, indeed: those are the thresholds - 768 and 2048.
(11.18) I grew my map bit by bit to watch memory consumption and performance before going to the next level. Now I just had the same problem when enlarging a 180°-rotated map (growing to the north/west) to 2048x2048.
Sadly, as discussed previously, this is conceptually a difficult problem to deal with. Perhaps the enlargement amplitude could be based on the original rather than the new size of the map? Hmm.
This bugged me in my newest game with 120.0 and pak128. I noticed that certain portions of maps tend to repeat with multiple enlargements and figured it might be a miscalulation of origin. Indeed, when I edited the savegame and tweaked the origin a bit, suddenly the enlargements were contiguous.
In simworld.cc:2115:
// eventual update origin
switch( settings.get_rotation() ) {
case 1: {
settings.set_origin_y( settings.get_origin_y() - new_groesse_y + old_y );
break;
}
case 2: {
settings.set_origin_x( settings.get_origin_x() - new_groesse_x + old_x );
settings.set_origin_y( settings.get_origin_y() - new_groesse_y + old_y );
break;
}
case 3: {
settings.set_origin_x( settings.get_origin_x() - new_groesse_y + old_y );
break;
}
}
I believe that the case for rotation is incorrect, and should read:
settings.set_origin_y( settings.get_origin_y() - new_groesse_x + old_x );as
- origin is always in absolute (non-rotated) coordinates
- rotating map once (or three times) interchanges the axes, thus enlarging in X direction should change Y offset
Can anyone verify this?