@elexis No, there isn't an actual issue right now. I mentioned those two cases that came to mind above. I don't think this will help reducing debug time consumption and is IMO a pure limitation.

I wanted to clarify that my proposal is only a simple solution, not the definite way to go.

To change the indentation of e.g. a defense tower would require to copy the wall set, change the indentation parameter and rewrite the wall alignment function.
Without the freeze and with the wall stiles constructed at import only the indent parameter would need to be changed.

Thanks for the feedback!

Requested changes:

The wall lengths are really good! Thanks much!

Thanks much for picking this one up @s0600204 !

@elexis Ultimately, yes. But ATM there are 2 kinds of templates in the directory templates:

• Definitions to generate entities from (in the subdirectories). Entity templates so to say
• Perdefinitions of of a set of those (with the prefix template_), Entity template templates so to say.

Both are templates but in a different way.

@Stan pointed out that since the trigger points are moved to the directory triggers the trigger prefix should be removed.
I agree since this was the default approach previously, too.
So this should be part of this commit to stay conform.

I somehow agree with elexis meaningful folder naming.
Still I consider this is a welcome improvement ;)

@linear gain: Then I'd always chose the shortest possible trade routes since it's the same amount of resources per time and trader no matter the distance ... and nearly no risk involved.
@square is to much: What about an exponent about 1.5?

Thanks for the fast and pleasant feedback, @fatherbushido.
I have not looked into the other patch so please commit the two ;)

This patch has been reviewed and accepted and I also agree with it.

Rebased after changeset 19807 (D659 committed)

To reproduce the original bug:
Generate: Map Size: Normal, Number of Players: 4, Seed: 2537 (High ground trees in bases of player 1 and 4)

I'd add a comment to the documentation of getTileCenteredHeightmap() that TILE_CENTERED_HEIGHMAP must be false (see comment at the top of heightmap.js) for this is the point where things would break.
Otherwise perfect, thanks much, @elexis !

Wait with this after D659 !

Added mappreview

Fixed most of elexis comments
Increases defenders of the mercenary camps
Larger map sizes also have smaller lakes (maybe that initial heightmap would work well for all map sizes)

The mappreview is missing.
Would be nice if someone with full graphics enabled could provide some ;)

Fixed:

• Player placement fails on Tiny and small maps: Smaller lake and slightly reduced player base smothing and no Iberian walls on those map sizes
• Changed the one occurrence of mercenary_camp_egyptian to merc_camp_egyptian. Good catch! ;)
• Halfed the number of animals at the lake
• Smothened the terrain below farms
• Slightly reduced the amount of fish

I reviewed the random map part and it gets my OK.

For tiny (and small) map sizes I have to use a different initial terrain and/or water level ;/

Made farms biome specific

Settlements are ready now. Please check the guarding units.

Also needs a screenshot, but I guess better when it's finished ... which it is not ^^

Fixes elexis remarks (but map specificarguments).
Changed the order so woods don't grow into bases.
Added settlements, not fully designed yet.
Added terrain flattening for settlements (flat) and raider camps (pits).
ToDo:

• Biome specific settlements
• Biome specific domestic animals and farm buildings
• Biome specific raiders
• Move some functions to libs

Very nice!

Applying the patch causes multiple errors:

createAreas() argument "behaveDeprecated" can be removed since it's only changed by createAreasDeprecated() ... which then again is unused ;p

what speaks against committing it before the release?

To be honest I'd rather fix the glitch where it happens (the functions, as you already did) and adjust the maps afterwards (even if that means a bit strange maps along the way) than add new functions that are by design not meant to stay.

Thanks much @Imarok for this patch!
(Not so much for @elexis for retiring as reviewer after making this patch big...)

In D401#16690, @elexis wrote:

JSON.stringify(someObj) ?

The "Total" of a ratio is the weighted average. Not sure if that was taken into account and how to weight each player (for the total score is an arbitrary value).
Why do we show those "scores" in the first place? IMO we should only show numbers that are not made up like number/cost of units produced/buildings constructed, number/cost of units killed/buildings razed/captured. If a player want to make up things he can do it himself. And different styles of play will lead to different "scores" while they still can be as effective.

"...currently it's enough to garrison its gatherers and wait for the end of the storm." is already damaging the economy of the attacked player.

@long argument: The suggestion means another variable is needed. I plan to extract this function (as many others of this map) into a lib. So that's not a good idea IMO.

Added style changes according to elexis patch.
I don't remove non-innermost brackets though!

@elexis: Sounds wise.
Could you please add links for all patches that should go in first (if not only that git branch you already linked)?

Added mappreview

elexis and me agreed on:

I still think placeCircularWall should be used for the ritual.
Otherwise I accept the map generation code.

@Random map generation code:
Very similar to Aegean Sea.
Walls leave a gap to the map border where units can pass through (IMO the forts should not be placed right at the map border).
Line 1: False comment
Line 5-10: I'd suggest to define some variables for those like tpA, tpB, ... (I don't mind. But if you comment on stuff that is somewhere else in the code that seems odd.)
Line 14, 22: tIsland, tSeaDepths, oDeer, oFish used exactly once each so unneeded (Just saying, I don't mind). Also I'd rename tSeaDepths to tSeaDeap or tDeepSea for tSeaDepths sounds like it's the depth of the sea rather than the texture of the deeper sea areas.
Line 14, 17, 18, 19: Commented out code (I'dd pick one and remove the other or randomly pick one of both)
Line 113: Add "for ships" to the comment.
Line 226-233: I'd suggest to use placeCircularWall() instead. Much simpler and takes care of the angles ;) (Use 2 * Pi * radius / n as WallElement.widths then)
Line 273 ff: Cleaner/simpler solution welcome ;)

Removed the "two spaces".

• Removed obsolete ToDo.
• Added tab and newline
• Preview still missing!

@"!validT": That loop contains terrain texture and entity placement. The entity is checked for "validT" in placeObject(). The terrain texture - if checked for validT - is not painted everywhere visible (at the edge of the map). So I need to place it everywhere.
The actual bug is in "visual map area" (Renderer?) doesn't match "validT(distToBorder = 0)" (rmgen).
@Map preview: Definitely! I can't make such a screenshot with my hardware though. Would you provide that, elexis?
@player start position distance to map border: I am sure it's at least 30, yes. That might actually be more than needed if Iberian players don't get walls (which I should IMO do in some map size/number of players combinations) - then 20 would be enough. Agreed?
@ missing tab: Oops x) Quite obviously ;p
@ToDo removel: Accnoleged!
@pizza: Nop. Diffenernt concept. Where that leads you can see in Schwarzwald.... Still I agree to soften the issue by increasing the valid height range for start locations dependent on map size/number of players combinations (related to start positions didtance to map border)

Removed spaces
Changed "integer" to "number" for js doc for the changed function
Thanks elexis!

While the debug messages will not be of any use to the player I agree with elexis that debug code/messages can stay in some cases and silenced in the release version.
This will help maintaining that specific part of code.
Shouldn't be to extensive though.
I'd suggest to use a debug flag for that.

Adjusted to comments of elexis, thanks!

Reviewed the map generation code mainly.
(Some functions still use hard coded tile class names for their defaults and don't use the now available alternative argument syntax - but that's not this map's fault.)

Try another time since the last diff didn't apply for some reason

Accepting this patch since in case of returning Undefined the only function using it (addBases) takes care of valid start positions.
I don't think that return Undefined is needed but this patch solves the original issue of an infinite loop.

Oh, I didn't see that the minimum distance was relative, sorry.
That means that the probability that all attempts fail go against 0 for resets going against infinity.
So the last change returning Undefined is not needed. And it will break the map definitely if more than 10000 tries are needed.

Though this will still end up in an infinite loop when the maps size is to small for a given map size and minimum distance between player AFAICS this change will reduce the chance.
Otherwise the minimum distance would need to be lowered with each "reset" which also would be possible to do in case "if (attempts > 100)".
I'd find the use of a while loop more appropriate than reducing the current player index "i" over and over again but OK.

Resetting to best chice I found
So no context for now...

Another try
"svn diff" definitely shows full context ;/

And another try
Maybe a Windows cache update problem?

Another try
svn diff now definitely gives full context. Let's see if this works out...