closed by rP20314

The Smoothing behaves differently at the map border and can be simplified by removing magic numbers.

@wraitii :
I just notice that the check for BuildRestriction seems not being strong enough (exact opposite of training restriction).

I'm dubious about the graphics effects manager idea, as the readers expectation of it handling all kinds of effects would not be met.
But if there is a solid plan what should be in it, maybe. Perhaps one could also find a more concise name, so that it's clearly distinguished from all the renderer code.
Agree that the term explosion should be replaced with something more general (projectile hit animation)?

In D945#37549, @Mate-86 wrote:

Is there someone needed from C++ experts to give the green light for such ideas or should I just freely work on the code and we will see? :)

In D945#37521, @wraitii wrote:

Given the orientation taken by the code (i.e. not using local entities), I feel like it might be worth creating an "Effects manager" that effectively handles all kind of "temporary" graphical effects like this — possibly including particles?. But I haven't thought too much about it.

In the meantime though, "Explosion" is a rather poor word since it really doesn't have to explode. Maybe "SpecialEffect" or something. Also your rendersubmit has two basically identical loops, maybe template it or have both inherit from a common struct?

How are flames created by flaming projectiles handled right now?

I agree. A new effect manager could be used for other purposes as well. Eg. https://trac.wildfiregames.com/ticket/1912 Continuous damage after hit detection could use some animations too. Explosion could be replaced by a more general term indeed.

map.js and library.js will be refactored (hopefully soon), but the changes proposed in this part seem ok (#4804).
(I had hoped that we can move the wallbuilder to a separate library - however it is required by the Iberian Wall starting base feature, thus required by all maps (that place a starting civic center).)
I can't look through the wallbuilder code at the moment, but if you want to reduce some part of the code already and don't mind a bunch of git add -p, feel authorized to commit the var/let changes and other one-liners without supervision.
You might want to poke FeXoR for the wallbuilder part (perhaps asking for a review in a forum PM).
I guess the template changes are fixing things and the wallbuilder code won't become worse.

fixed in rP20313

All that is beautiful!

To demonstrate that a lot of places are off by one, here the Rivers map that is also shipped with being off by 1 but would be fixed when setting that messy flag:

Your idea sounds ok.
(Basically move that part in the EntityLimits component)

In D945#37521, @wraitii wrote:

How are flames created by flaming projectiles handled right now?

Wouldn't it end up being easier to add an "AllowedToReplace" function to the entity limits component?

Given the orientation taken by the code (i.e. not using local entities), I feel like it might be worth creating an "Effects manager" that effectively handles all kind of "temporary" graphical effects like this — possibly including particles?. But I haven't thought too much about it.

It would be better if we had a reachableTile (returns false for the 3 impassable map border tiles) and paintableTile function (returns true on the map border).

This commit transcribed what was identically present in C++ before.
The original C++ rmgen system was introduced in rP2293 (What was that ASCII generator though?).
The SmoothElevationPainter was introduced in rP2519.
The first two random maps were Cantabrian Highlands rP2683 and Neareastern Badlands rP2733.
The C++ rmgen code was removed after this commit in rP9219.

Problem:

allows easy height based terrain painting

It is easy to add one line, but it is not easy to figure out the effects of that (or even what the purpose of that flag is).

There seems to be some lineending issue preventing this commit to be displayed properly on Phabricator.

nice teaser!

Explosion animation works finally! There are lots of TODOs in the code which I have to address as part of this diff but feel free to do some early review.

Build is green