Yet another random map generator

[elexis]

4 hours ago, aeonios said:

One of my biggest goals in improving random maps is to get rid of the bad ones

I'm not on board with that. I've had some dozen of matches on that Alpine map, even within the first month of installing 0 A.D. A snowy labyrinth experience I don't want to miss. IMO the crappiest one is mainland, but thats somehow the most popular too. new_rms_test maybe.

4 hours ago, aeonios said:

aren't even very playable, even if they do look pretty good

I don't know what you mean with playable, nor which maps you mean.

(Anyway, it's offtopic.)

[Pyrophorus]

Hi,

12 hours ago, elexis said:

rmgen doesn't scale well, so if one wants to argue with performance, one could test if proposed alternatives to the current code could allow larger mapsizes than 512*512. (I found it a bit sad to not be able to create a larger map for the jebel barkal scene in the a23 trailer than that giant one.)

Is it possible to specify larger map sizes than giant for now ? (From the map script, obviously).

Friendly,

[Imarok]

I think the map receiving the most hate when being the result of random choice is "Snowflake Searocks". But I find that map quite entertaining sometimes...

The maps I find least valuable are all those "mainland with bumps" maps that mostly differ only in texture/biome.

[elexis]

1 hour ago, Imarok said:

The maps I find least valuable are all those "mainland with bumps" maps that mostly differ only in texture/biome. 

You forgot the generic biome maps. Those are  "mainland with bumps" that not even differ in texture/biome sometimes.

IMO what makes maps good is uniqueness. Something noone ever thought of before.  But really half the players on the lobby are Die Hard mainland players, because they don't want to have to adapt to changing conditions, but optimize the build order for the average map in a petri dish.

15 hours ago, aeonios said:

The disadvantage of having too many map scripts that nobody plays is that nobody will be willing to use random map selection since they don't want to roll a bad map

(As mentioned I don't share the premise, but) just to mention that if some people don't like some maps, some of these people could use a custom mapfilter. Then they can bookmark their favorite maps and have randomness only amongst them. Surely my memories that I saw it being discussed on the forums can't be that off. I thought this was already filed as a ticket, but as I couldn't find any, filed #5209.

4 hours ago, Pyrophorus said:

Is it possible to specify larger map sizes than giant for now ? (From the map script, obviously).

Never tried until now:

Index: binaries/data/mods/public/simulation/data/settings/map_sizes.json
===================================================================
--- binaries/data/mods/public/simulation/data/settings/map_sizes.json	(revision 21835)
+++ binaries/data/mods/public/simulation/data/settings/map_sizes.json	(working copy)
@@ -37,6 +37,46 @@
 			"Name": "Giant",
 			"Tooltip": "Very large maps are not recommended as it takes very long to reach the enemy and the game performance can be reduced.",
 			"Tiles": 512
+		},
+		{
+			"Name": "1024",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 1024
+		},
+		{
+			"Name": "2048",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 2048
+		},
+		{
+			"Name": "4096",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 4096
+		},
+		{
+			"Name": "8192",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 8192
+		},
+		{
+			"Name": "16384",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 16384
+		},
+		{
+			"Name": "32768",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 32768
+		},
+		{
+			"Name": "65536",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 65536
+		},
+		{
+			"Name": "131072",
+			"Tooltip": "Chose this if you don't want to finish map generation.",
+			"Tiles": 131072
 		}
 	]
 }

0adsvn  -autostart="random/new_rms_test" -autostart-size=65536 -autostart-seed=-1 -autostart-players=8 -autostart-player=-1  -autostart-nonvisual

I could successfully generate 1024*1024 visually, IIRC non-visual is much more faster, but larger sizes froze my system, despite the random map script being empty. We arguably can't have a faster mapgen time. One could now look which of the remaining parts are that slow or don't support these mapsizes from the data structure. Perhaps exportHeightData could be omitted by converting the 2D array to a 2D vector in C++ (See #4816#comment:3 for screenshots of my initial troubles). If lucky, this might simplify the code in both RandomMap.js and MapLoader.cpp while improving performance to allow such mapsizes.

Other parts of the C++ part may be too slow as well and we should take a look at the most significant bottleneck consecutively.

The Profiler2 (see EngineProfiling) may or may not be used to measure which C++ parts are the slowest. (If there aren't Profiler2 calls in the slow functions, they won't be listed I believe). Usually I added a debug_printf with the current timestamp to see which parts are the slowest.

[aeonios]

2 minutes ago, elexis said:

IMO what makes maps good is uniqueness. Something noone ever thought of before.  But really half the players on the lobby are Die Hard mainland players, because they don't want to have to adapt to changing conditions, but optimize the build order for the average map in a petri dish.

I think the main reason people play mainland is because it's an open map that isn't wood deficient. Build order doesn't really differ that much on heavily choked maps, but scouting is much more difficult. This is something I found out playing on the alpine map and the ardennes map that I made. People still do play on other maps like frontier, just not as often because it's easier just to set mainland for the above mentioned reasons, and since everyone is familiar with it.

That's also why I've tried to make my maps super pretty, to lure people into playing them.

[Pyrophorus]

Hi,

4 hours ago, elexis said:

Index: binaries/data/mods/public/simulation/data/settings/map_sizes.json

I'll try this  out of curiosity. Thanks.

Now the YAMG for A-23 is on Github. No new features but a full upgrade.

The fractal painters expect an Area in their paint() method and mesa and depression painters provide a Vector2D array, instead of point array.

The Cell object inherits now from Vector2D and can be used in rmgen where a Vector2D is required. Of course, the placer and the utilities which rely on this Cell array can't be used without creating a g_TOMap Cell objects first.

AnEgyptianOasis is still a work in progress. It works nicely and don't lack features, but some details need to be fixed, particularly players starting resources. I have quickly copy/pasted some code somewhere and this code fails at time for some reasons.

Have fun !

Edited June 5, 2018 by Pyrophorus

[elexis]

Very promising! Needs more decoratives (stones, grass, bush, reeds actors), the path might or might become a bit larger, maybe some random patches for the areas. For the final touch, the balancing will be relevant, there should be mines here and there, not too many, not too few. Some animals and berries and you can call that top 10%-20% of the maps that people did so far.

Edit: But that is the recipe that every map uses. The final touch per map is going through the entire list of actors and regular entities in the atlas actor viewer and see if there are some kinda unique ones. (For instance the well on danubius or the kushite statues on JB)

Edited June 5, 2018 by elexis

[aeonios]

https://github.com/Pyrophorus/YAMG/blob/master/yamg/maps/random/yamg/fractal.js#L82

mapSize should be g_Map.size I think.

https://github.com/Pyrophorus/YAMG/blob/master/yamg/maps/random/yamg/fractal.js#L184

if you put nochiasm in the paint function the user cannot set it, since paint is usually called by a library function which does not know about it. It needs to be an instance variable and to be set in the constructor.

[Pyrophorus]

Hi !

10 hours ago, elexis said:

there should be mines here and there, not too many, not too few. Some animals and berries

The screenshot don't show them very clearly, but there are some mines (behind the roman caer) and animals (not only crocodiles). But the map needs a better painting and some more decorations, that's right.

9 hours ago, aeonios said:

mapSize should be g_Map.size I think. 

Yes, you're right. mapSize in only defined in my test script

8 hours ago, aeonios said:

if you put nochiasm in the paint function the user cannot set it, since paint is usually called by a library function which does not know about it.

"Usually" ? Anyway, I think the best would probably be to have three painters, because for now Fractal and Cracks painters give exactly the same result when nochiasm is set to false.

Friendly,

[elexis]

The paint function is called by createArea with only one argument, constructors contain all the arguments required by a Painter.

(Also it's better to avoid default variables when there is a choice. This way the mapscript is mandated to tell what it wants. If it doesn't do that, the caller often doesn't consider what value is actually passed and then the function potentially doesn't do what it should. In `misc.js` of alpha 22 / gaia_entities in a23, there were tons of default values and maps used a random subset of the defaults that were wrong in a number of cases, which could have been prevented if they'd have to specify constants. (Maybe the oversights of rP20405 fixed by rP20531 aren't the best example since it's still human error)

[aeonios]

1 hour ago, elexis said:

(Also it's better to avoid default variables when there is a choice. This way the mapscript is mandated to tell what it wants. If it doesn't do that, the caller often doesn't consider what value is actually passed and then the function potentially doesn't do what it should. In `misc.js` of alpha 22 / gaia_entities in a23, there were tons of default values and maps used a random subset of the defaults that were wrong in a number of cases, which could have been prevented if they'd have to specify constants. (Maybe the oversights of rP20405 fixed by rP20531 aren't the best example since it's still human error)

IMO it's bad not to have defaults because that makes it more difficult for designers to figure out what kind of values are sane, not to mention javascript crashes are nasty. If javascript fails on the same error twice in a row, atlas will crash. I'm not sure why that happens but it's bad.

[Pyrophorus]

6 hours ago, elexis said:

The paint function is called by createArea with only one argument, constructors contain all the arguments required by a Painter.

Yes, but AFAICS createArea is not the only opportunity to invoke a painter. What if  you want to apply successively two painters to the same area (for instance an ElevationPainter and a TerrainPainter) ? You call createArea twice ?

Friendly,

[aeonios]

4 minutes ago, Pyrophorus said:

Yes, but AFAICS createArea is not the only opportunity to invoke a painter. What if  you want to apply successively two painters to the same area (for instance an ElevationPainter and a TerrainPainter) ? You call createArea twice ?

Friendly,

No, the createArea functions take an array of painters as an argument, and applies all of them successively in order.

[Pyrophorus]

27 minutes ago, aeonios said:

No, the createArea functions take an array of painters as an argument, and applies all of them successively in order.

And what if I want to do something in between ? For instance selecting a second painter after the result of the first one ? createArea can certainly manage most use cases but not all of them.

Friendly,

[aeonios]

7 hours ago, Pyrophorus said:

And what if I want to do something in between ? For instance selecting a second painter after the result of the first one ? createArea can certainly manage most use cases but not all of them.

Friendly,

That's irrelevant, because you don't get to know the result of a painter anyway. If you want to do something like painting by height/slope you can of course do that in a separate step, but that has nothing to do with the interface to the painters.

[Pyrophorus]

Excuse me, but what's irrelevant here is to reply a question I asked to Elexis. I would like to know what he has in mind, and since you're not him, you can't say anything  but commenting rmgen code I can read just as well as you.

[Pyrophorus]

Bad news...

I found out a major compatibility problem with a-23 rmgen. I thought it was OK to make my cell object inherit from Vector2D. Then one could use them in any rmgen function requiring a Vector2D (or an array) in their parameters. And there's no problem on rmgen side: it works nicely. But there's a side effect which creates errors in further uses of the cell object in yamg: many rmgen functions freeze the objects they get as parameters. If somebody uses a cell array to create an Area for instance, the cell objects become read-only and any yamg function trying to write them (YPatchPlacer, buildRoads) will raise an unexpected error. The fractal painters are not impacted because they don't use the cell object.

Of course, it's possible to work around this trap,  but I don't like the idea to share such a breakable code. I think I will withdraw it.

Sorry...

[elexis]

19 hours ago, Pyrophorus said:

Yes, but AFAICS createArea is not the only opportunity to invoke a painter. What if  you want to apply successively two painters to the same area (for instance an ElevationPainter and a TerrainPainter) ? You call createArea twice ?

I think the majority of createArea calls use multiple Painters to consecutively paint to the same area.

Calling createArea a second time after some other statements is possible too currently (RectPlacer + StayAreasConstraint, possibly introducing an AreasPlacer proxy).

I guess the argument for having that nochism boolean is to be able to reuse that painter. But then I'd rather add a Setter function if it really can't be moved to the constructor.

47 minutes ago, Pyrophorus said:

freeze the objects

clone() or constructing new objects remove the freeze. If there are no other choices we can also consider to remove a freeze calls. Which ones exactly were in your way?

[Pyrophorus]

Hi,

23 hours ago, elexis said:

I think the majority of createArea calls use multiple Painters to consecutively paint to the same area.

Calling createArea a second time after some other statements is possible too currently (RectPlacer + StayAreasConstraint, possibly introducing an AreasPlacer proxy).

If I understand correctly, createArea is to you the normal if not the only way to create the landscape, which landscape is populated after using the created areas ?

23 hours ago, elexis said:

I guess the argument for having that nochism boolean is to be able to reuse that painter. But then I'd rather add a Setter function if it really can't be moved to the constructor.

Not exactly. It's quite impossible to tune the original fractal painter in order to get only hills or only depressions, but it's probably what scripters want most, and this is what the fractalpainter gave with a standard call 'paint(area)'. The nochiasm optional parameter was here for the rare case a fully random landscape was wanted. Anyway, I removed it and created three painters which offers the same functionalities: one of them creates only hills, another one only depressions, and the third creates both.

23 hours ago, elexis said:

clone() or constructing new objects remove the freeze. If there are no other choices we can also consider to remove a freeze calls. Which ones exactly were in your way?

That's  right, and it is one possible workaround. Actually, the YPatchPlacer is safe to use in createArea calls because its place() method returns a Vector2D array created on the fly, and not a Cell array. But the regions returned by its other methods (not rmgen standard) are Cell arrays and may be frozen if used to create an Area.
I listed the deepfreeze occurrences in rmgen and found out 12 (just in case I could miss some). Most of them can't create problems because they freeze new objects or clones. There is one at line 50 in library.js which has nothing to do with yamg.
The last one is in Area constructor, and it's probably not so easy to remove. I imagine you freeze the points array to avoid the membership cache becoming inconsistent, and cloning the points array you get as parameter wouldn't be very efficient and useless in most cases. There would be no problem if the deepfreeze could happen only on the array itself and the Vector2D members of the Cell object (their coordinates never change and could become read-only), but I doubt Javascript allows this.

Friendly,

[elexis]

2 hours ago, Pyrophorus said:

If I understand correctly, createArea is to you the normal if not the only way to create the landscape, which landscape is populated after using the created areas ?

It's a preference to use createArea to modify terrain. (If we can generate more than 65 maps with only one  type of terrain modification call, that makes it extremely easy and powerful. Newcomers and devs only have to comprehend one way to call things, rather than one way to call things per map.) Doesn't mean we may not introduce something else if it's impossible to reuse the existing interfaces.

Terrainshaping is usually done prior to entity placement. But sometimes things are mixed up for some random legitimate or illegitimate reason. Jebel Barkal is my flagship and I'd like to create 60 maps better than this one (just that ones life is too short too accomplish that).

2 hours ago, Pyrophorus said:

deepfreeze

 

2 hours ago, Pyrophorus said:

I imagine you freeze the points array to avoid the membership cache becoming inconsistent

Indeed that was the idea. We had such issues in the GUI often and adding a deepfreeze call revealed when something wanted to change the cache that noone was aware about (as there was too many indirection to notice the cache modification): #4257.

I really would have to look into the code before I can say something true, because it looks more like a design issue than an implementation issue. If the Cell objects are superior and accepted, we may consider using them everywhere intead of Vector2D. Then there is still only one way to do things and every map benefits. I was wondering if createArea couldn't be called with other prototypes than Area (CellArea?) that have the same function names and are somehow compatible (if things can't be unified). Not a trivial task, but it's possible to merge things one way or another.

[Pyrophorus]

Hi,

17 hours ago, elexis said:

It's a preference to use createArea to modify terrain.

OK, that's what I suspected. Of course, as long as it's still possible to do otherwise, I have nothing against it.

 

17 hours ago, elexis said:

I really would have to look into the code before I can say something true, because it looks more like a design issue than an implementation issue. If the Cell objects are superior and accepted, we may consider using them everywhere intead of Vector2D. Then there is still only one way to do things and every map benefits. I was wondering if createArea couldn't be called with other prototypes than Area (CellArea?) that have the same function names and are somehow compatible (if things can't be unified). Not a trivial task, but it's possible to merge things one way or another.

I agree. It's a design issue, and for myself, I think rmgen would benefit to have a unique cell object collecting most tile information in it. It would make many things easier and faster, but it's not a ten minutes task.

In the mean time, I updated the library to add a warning and a possible workaround. Instead of giving a Cell objects array to Area constructor, gives a Vector2D array holding the same coordinates. There is a zoneToPoints() function to do that (already used in the YPatchPlacer place() method). Instead of:

new Area(some_Cell_Array);
use:
new Area(zoneToPoints(some_Cell_Array));

Friendly,

[elexis]

I want paths where there's a texture in the middle, to the right of the path a parallel stream and then trees parallel to that path. Just using BFS to extend the area of some PathPlacer doesn't cut it, because we want the trees only parallel to the direction of the path but not at the start and end of the path. These were unintended artifacts in most use cases.

So the only way to accomplish that would be to have the PathPlacer return the direction of the path at every position that is part of the placed area. Since not every placer has a direction information, this metadata would have to be optional.

So it seems including yours, there are two use cases of Placers generating custom position metadata that Painters should use, so maybe createAreas should be able to support passing arbitrary position metadata from the Placer to the Painter? Painters should still be able to work as independent of such metadata as possible and only parse it if its technically inevitable because the information would be lost after the Placer ran or would be too time-consuming to recreate. Can we test the hypothesis and find more use cases?

Edit: It seems the catch is that the Area needs to save the metadata and changing the Vector2D object seems messy, so all Placers and Painters would have to construct and parse { "position": vector2d, "metadata:" foo } everywhere which is not too attractive either.

Edit 2: The paintRiver function does such a thing for instance and it was already used for one non-river for that reason (the transition of the fertile land to desert on jebel barkal consisting of parallel textures). Started converting it to a BFSPathPlacer, but it's also limited, because one can't use it for a circle segment area for instance. Meh.

[FeXoR]

About An Egyptian Oasis:

On 11/13/2018 at 9:28 PM, FeXoR said:

On 11/13/2018 at 3:52 PM, Pyrophorus said:

[--] give me some feedback about increasing playability [...]

The two main things I noticed that don't work well yet:

1. Paths are quite narrow so large armies have trouble to use them if they go through forests. While the texture width is OK there should be no obstructions that close to the path. It actually seems like they are not continuous and broken apart by tiles with trees.
2. Starting locations don't have domestic animals like chicken or pigs. This can put some players at a rather heavy disadvantage for some might wind up having camels nearby but others don't. And cavalry can gather meat quite fast.

Other more minor issues:

• Some maps have rather large areas covered by water and "ramps" that can be walked on but not build on. This makes it quite hard to use defences. Maybe the ramps can made a little less steep and the water a little more deep (so units can't walk through most parts of the water).
• The actors on mountains are those of actual mines. That might confuse quite some players that will mistake them for spots to gather from. Replacing them with non-mine actors would solve this
• The texture around start locations abruptly stops when reaching the playable map area's border. Instead I'd place the texture but no entities (or the actor corresponding to the entity) in the entire area if not outside the map (the square map where textures can be placed but I mean here).
• Roads often leading to/through lakes. This is not really an issue because units can walk through most parts of the lakes anyway but it looks like this is not planned
• The wet sand texture extends quite far into areas not covered with water. That looks strange to me.
• While I like your choice of textures very much in the barren flat regions the light grass texture doesn't fit very well IMO. 

I haven't read through the entire code so it's absolutely possible some of my comments don't make a lot of sense

Expecting requests for more concrete suggestions ^^

[Pyrophorus]

Hi everyone !

Thanks to @FeXoR for his feedback. He is right to say:

2 hours ago, FeXoR said:

1. Paths are quite narrow so large armies have trouble to use them if they go through forests. While the texture width is OK there should be no obstructions that close to the path. It actually seems like they are not continuous and broken apart by tiles with trees.
2. Starting locations don't have domestic animals like chicken or pigs. This can put some players at a rather heavy disadvantage for some might wind up having camels nearby but others don't. And cavalry can gather meat quite fast.

 

... of course.
Point 2 is not difficult to fix most probably. I use here an old version of rmgen routines which works not well every time (don't say I should use a newer version. I know but it creates problems in my design too).
Point 1 is more tricky. For now,  the road creation procedure draws one cell wide paths, which is not optimal when the path runs diagonally. It's probably why they look broken when running across forests. In mountains it would be even worse, but here, I have already made some adjustments to make roads (rather) walkable. But this is clearly not enough. Il have to rework the thing to create larger paths (and by a side effect, maybe solve the issue @elexis quoted here:

 

On 7/10/2018 at 9:23 AM, elexis said:

I want paths where there's a texture in the middle, to the right of the path a parallel stream and then trees parallel to that path. Just using BFS to extend the area of some PathPlacer doesn't cut it, because we want the trees only parallel to the direction of the path but not at the start and end of the path. These were unintended artifacts in most use cases.

Now, how wide ? It's not an easy choice: I often noticed the pathfinder has a problem with bottlenecks: even when the path is more than five tiles wide, if units use it in both directions, they deadlock each other and this results in a absurd mob (and a lag).

2 hours ago, FeXoR said:

Some maps have rather large areas covered by water and "ramps" that can be walked on but not build on. This makes it quite hard to use defences. Maybe the ramps can made a little less steep and the water a little more deep (so units can't walk through most parts of the water).

All these are created by the main landscape procedure. Mountain and water ratios can be modified easily (it's a parameter). It's always possible to modify the map in some way (make the water deeper for instance), but IMHO, the problem is to know if we create (rather) realistic maps players have to deal with (and this is part of the game challenge), or artificial playgrounds where all landscape difficulties are smoothed or eliminated. This is open to discussion but maybe we should make a clear choice (at least for this or a random map category).

2 hours ago, FeXoR said:

The actors on mountains are those of actual mines. That might confuse quite some players that will mistake them for spots to gather from. Replacing them with non-mine actors would solve this

Agreed...

2 hours ago, FeXoR said:

The texture around start locations abruptly stops when reaching the playable map area's border. Instead I'd place the texture but no entities (or the actor corresponding to the entity) in the entire area if not outside the map (the square map where textures can be placed but I mean here).

OK...

2 hours ago, FeXoR said:

Roads often leading to/through lakes. This is not really an issue because units can walk through most parts of the lakes anyway but it looks like this is not planned

Yes, it's not, but in real world, geomorphism don't cares about paths too... I suppose here the civilization level is rather low here, so paths follow the easiest way. It's possible to make them avoid completely water, but this would eventually result in absurd things: for instance a road climbing rather high to cross a mountain falling into water when it is shorter and easier to follow the bank, wetting slightly one's feet. In some way, I follow the pathfinder policy to connect parts of the map: it avoids not crossing the lakes and rivers even when it's not absolutely necessary.  Ideas ?

2 hours ago, FeXoR said:

• The wet sand texture extends quite far into areas not covered with water. That looks strange to me.
• While I like your choice of textures very much in the barren flat regions the light grass texture doesn't fit very well IMO. 

Textures can be changed easily of course, but I'm not that good at it. Feel free to suggest other sets.

 

2 hours ago, FeXoR said:

I haven't read through the entire code so it's absolutely possible some of my comments don't make a lot of sense

Don't worry, they make sense...

Edited November 15, 2018 by Pyrophorus

[FeXoR]

Oookkkk... (still not through the code...it's quite a read )

1. Roads: AFAICT you first paint textures, then you paint roads taking the textures painted into account. This means you are overpainting existing textures. What about defining areas instead of textures you can than take into account for the paths to be placed, then you place paths (again as abstract regions, maybe an inner one for the part textured and a second, larger one for not placing terrain entities - and not containing the tiles of the inner path [if you want to you could also add a 3rd - again not containing any of the inner areas -  that can contain entities and maybe avoiding start and end point by slightly more than it's own width to generate something like @elexis had in mind]) and then you paint the textures (with all the other map generation stuff in between ofc.). That way your approach will still work (weighted path search) but you don't have to overpaint textures and you can avoid entities close to the path and @elexis can have alleys (if you avoid forests or other entity rich areas because this is likely what is wanted). And I'd say try 5 tiles unobstructed path width (or 3 tiles from centre).
2. Domestic animals at start locations: You can just place them after line 194 like "berry bushes" or "starting trees". Did I miss something? (And what issues does which newer placement method cause?)
3. Large areas covered in water and ramps that can't be build on: Making the water deeper and the ramps flatter would do IMO. I don't get the entire main landscape procedure yet but maybe non-linear scaling (e.g. with square root) of the heightmap ("before" mountains are added - yea, it's in one go but in different sections) could change this without having to change much else? (on the other hand there should be an exponent scale factor for higher and lower terrain anyway IIRC) I can live with it as is but really think at least deeper water would be nice - and more realistic BTW (If the water level is set before the main landscape procedure one could also change those areas separately )
4. Roads avoiding water: Yea, no big deal. Still strange looking to me and AFAICT easy to avoid in placers.js line 513.
5. Textures: Not looked into, yet. To tired ^^

Well, I hope you can make something out of this rather chaotic set of suggestions.

Keep it burning @Pyrophorus

EDIT: After a closer look you do most of the suggested stuff in "roads" already. Additional Area types (e.g. road_clearance and road_border) and changing the texture placement might be enough.