Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/differential/736/display/redirect

This feature combined with the texture changing from the simulation is a very interesting feature.
Use cases will include an earthquake map, erupting volcanoes, cliffs appearing during the game, players building trenches, streets near walls and houses.

As far as I know the data that is used, changed and serialized in the simulation should be located in a simulation component, not graphics/.
So there might be a hopefully not too long rattail of preliminary refactoring needed.
Also what the bot said https://jenkins.wildfiregames.com/blue/organizations/jenkins/differential/detail/differential/736/pipeline
Once textures and terrain are serialized, we can skip the entire rmgen / maploading stage of the loading screen (ticket somewhere).
Should estimate how big that data structure becomes, how it affects the size of savegames/rejoin state sizes (+3MB?), zipped (one can print the length of the zipped state in a Net*cpp file).

In D1642#65042, @elexis wrote:

As far as I know the data that is used, changed and serialized in the simulation should be located in a simulation component, not graphics/.

Does hold true for water too. Which is at the moment the only such thing that bridges simulation and graphics AFAIK.

In D1642#65046, @smiley wrote:

In D1642#65042, @elexis wrote:

As far as I know the data that is used, changed and serialized in the simulation should be located in a simulation component, not graphics/.

Does hold true for water too. Which is at the moment the only such thing that bridges simulation and graphics AFAIK.

Am I recalling incorrectly that simulation/ only uses a single number for the water level and only informs graphics/ that the watergrid used for rendering has to be rebuilt?

Other than that, that's part of the mentioned rattail. I'm reminded of the cinema path support where the data had to be moved from graphics/ to simulation/ in order to become serializationsafe, but maybe I'm missing something. CTerrain is used in several places in the simulation, it seems broken already. (So we have the choice between continuing to build upon an incorrect implementations and look the other way seek to rectify or debunk this issue).

Thanks so much for working on this. I guess you could link this to the "terrain flattening ticket". Could also allow us to finally have a functional murus gallicus.

Thanks @Stan , will fix with the next update.

Am I recalling incorrectly that simulation/ only uses a single number for the water level and only informs graphics/ that the watergrid used for rendering has to be rebuilt?

Thats exactly how it does. Same structure could be used for terrain too. I'm guessing that the heightMap and texture patches could be stored in ccmpterrain and graphics could load it from there.

Could you try to make foundations level ground ? This would save so much useless underground polygons, might have some positive impact on the game.

In D1642#65064, @Stan wrote:

Could you try to make foundations level ground ? This would save so much useless underground polygons, might have some positive impact on the game.

Then players will build bridges by placing and deleting storehouse foundations?

Well you can't build storehouses along shores... And you could disable it for docks but... Yeah

IMO, it would look kinda odd when foundations suddenly flattens a square of rolling terrain.
Anyway, its not quite in the scope of this diff. This diff just makes it possible to do this in the engine. People can come up with uses in the future.

Foundations

I think if the building restrictions are more strict, so that the terrain is almost flat, then flattening it might or might not prevent such effects like being able to build bridges or impassable terrain.

Nice idea, @smiley .
I'd like to inform you that I requested such a feature before and was warned that the engine was not designed with this in mind.

So, please, seriously test this.

Concerning ground below buildings: @Stan: Either we allow players to manipulate the terrain as a game feature (which is both a long shot and outside of the original design concept) or we shouldn't provide any way to the player to change the terrain (impacting passability) at all (basically what @elexis said).

Well you shouldn't be able

In D1642#65081, @FeXoR wrote:

Concerning ground below buildings: @Stan: Either we allow players to manipulate the terrain as a game feature (which is both a long shot and outside of the original design concept) or we shouldn't provide any way to the player to change the terrain (impacting passability) at all (basically what @elexis said).

Really ? I thought it was part of it since Philip made a Trac ticket for it.
Well it makes sense to use features we implement right ?
What we could do is remember the destruction caused by a building and revert it when that building is destroyed. But smiley is right it's out of the scope

What we could do is remember the destruction caused by a building and revert it when that building is destroyed.

+1 for something like this.

In D1642#65083, @Stan wrote:

Well you shouldn't be able

In D1642#65081, @FeXoR wrote:

Concerning ground below buildings: @Stan: Either we allow players to manipulate the terrain as a game feature (which is both a long shot and outside of the original design concept) or we shouldn't provide any way to the player to change the terrain (impacting passability) at all (basically what @elexis said).

Really ? I thought it was part of it since Philip made a Trac ticket for it.
Well it makes sense to use features we implement right ?
What we could do is remember the destruction caused by a building and revert it when that building is destroyed. But smiley is right it's out of the scope

I thought the flattening Philipü wanted to introduce was visual only so it doesn't change passability. I may be wrong though, didn't check the code.
And in my book it makes much more sense to implement features that we see fit for the game rather than the other way around ;)

<Stan`> Would be nice to be able to set passability with no change to the terrain, for special entities :P
like, bridges set the middle of the bridge passability land
<smiley> i guess needs walkable meshes first.
<smiley> (or make walking indepednt of the ground :p)

Well if you do not keep the passability grid in sync with the visible terrain you can ;) Tweak that a little and you have draw bridges.

Ah, the classic What You See Isn't What You Get. :p

/**
  * Call when the underlying CTerrain has been modified behind our backs.
  * (TODO: eventually we should manage the CTerrain in this class so nobody
  * can modify it behind our backs).
  */

A comment from ICmpTerrain.h, I guess getting rid of this rattail had to be done eventually anyway. Hopefully, can start some further work on this during this weekend.

Thank you smiley for taking your time and working on this. Btw there also seems to be some incomplete support for formats as said here https://trac.wildfiregames.com/ticket/2828 (last two comments from elexis).

I have to say the current way (1 vertex per call) to modify the terrain is pretty slow, especially if it's called from JS. So I suggest to use a range modifier, or even better - brushes. With brushes you only need to pass brush params and C++ part will complete a request as fast as possible. With brushes you're still able to edit terrain by 1 vertex: just pick the brush radius as 1.

Thanks for the additional review. Would resume working on this soon.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/760/display/redirect

Good first step. I think this should follow the "GetHeight" conventions for vertices vs terrain tiles.

In D1642#69176, @wraitii wrote:

Follow the existing naming nomenclature and we should be mostly good to go.

In D1642#inline-33187, @smiley wrote:

If this sounds like a desirable feature, all I can say is to commandeer, make the relevant changes and commit.

My comments from D1642#65042 and Vladislavs comments from D1642#65595 are not relevant or silently examined?
If you have the urge to commit something before cleaning up the affected codebase, at least admit that it's an anti-pattern to serialize data from graphics/, that this had caused OOS errors in previous times already that took a year to have them fixed, and that the data should be moved from Terrain data to CCmpTerrain in the future if not now.
Estimating how many megabytes serializing the terrain will cost must be done. I already get 100% memory freezes with my 8GB memory when there are 20-30 rejoins (serializations) in a game with 1600+ units. It can make that worse, which may be a cost that must be paid but should not go unnoted.
It will also make savegames greater. You can check the filesizes of zipped PMP file I suppose to get a measure of how much data this will cost. The data will also be transmitted, a bandwidth thing.
It reminded me that there is also a ticket about exactly this #2147.

Why not add any proof of concept to demonstrate the feature and implementation, test it's possible limits and that it's actually feasible to write JS to achieve that?
Is it fast enough change a lot of area? see the mentioned use cases, for instance an earth quake, new rivers, cliffs or a volcano. If that's not performant enough, what are the optimizations? If that's still not performant enough, what are the remaining use cases? Maybe a small plateau during one event in a game?
Not that it's inevtiably necessary to write a POC, but it would show everyone how it works. The feature carries the potential to create the most interesting map that exists so far, possibly a headliner of an a24 release. If there is no example, it might just be an unused feature for years to come, which would be sad.
I would expect that changing one vertex at a time has a much worse complexity than passing a set of of modified coordinates at a time? (I think you asked me that already in the lobby, but how can I know without doing the dirty work.) Vladislav mentions it above too.
Consider for example the rebuilding of the pathfinder grid when the waterheight changes on extinct volcano.

Maybe it's not strictly necessary to determine about how exactly one will use a new feature in JS whose C++ backend is implemented, but it would be healthy to do so to chose the best implementation amongst discoverable alternatives.

I suppose exposing the rmgen library to the simulation would open up an extreme range of utilitiy. It would probably be necessary to pass on the existing tileclass data from rmgen to simulation, so that the sim already knows where the water and hills are and can build on that.
There is already a ticket that asked for Skirmish/Scenario maps to have some metadata saved per tile - for example to have different walk speeds in swamps or more fruitful grounds for fields somewhere.
So the tileclass data type might be abstracted and developed into a new datatype that also works for the simulation and other maptypes.

But that's only one thought of a possible JS implementation. The first proof of concept could just be something simple and self-contained. Just smoothing out the existing terrain for instance, or just messing with one rectangular area. Hannibal for instance is working on a flood/tide map, it could be used for that if we don't have the resources/population count necessary for a new volcano/new cliff/new river or other great adventures.

At last, it Petra AI thing.

It might be noteworthy that despite the engine differences Spring Engine supports in-game hightmap manipulation and e.g. Zero-K makes extensive use of it e.g. most projectiles deform the terrain. So looking into their code and playing a few games to see the gameplay impact might help to determine the needs and outcome.