Do any of the current game engines have features for 'on-the-fly' terrain chunks being sent to clients to accomodate 'player changed worlds' ??
Probably not, most seem to have settled on concept of a level, due to amount of offline processing needed to generate such level data. SecondLife has limited graphics capabilities precisely for this reason.
Not saying it's impossible, but effort needed exceeds ROI for such functionality. Especially at AAA, where visual quality needs to be consistent and ad-hoc modifications make that difficult if not impossible to guarantee. Best visuals are still a bunch of tweaks and hacks, optimized for that one use case through a lot of testing. For non-trivial modifications there's pathfinding, LOS, illumination, perhaps texture atlas generation, partitioning.
Then there's the usual performance issues, someone might simply make a grid that is 201x201 instead of 200x200 and suddenly a model of cards will run slow or crash.
The tools auto vetting would have to eliminate bad data (your grid example) format from top to bottom anyway....
I asked if any engines sound like they are starting to have features to support this and it sounds like 'static' is what they have (and continue) to be built upon. Until recently network bandwith probably was a big issue and CPU to rebuild and assemble the frequently changed data (memory/disk space not so much). though I dont think you would have to 'rebake a level' that often (and then in localized chucks) as most changes in game still happen to objects.
It does sound like they have largely stagnated around 'Pretty' static scenery (with virtually nothing active in it) -- that seems to be accepted (or has to be since nothing better is offered players in MMORPGs)
Minecraft might give them some ideas, but the Minecraft terrain data is extremely simple so generating update/delta patches likewise is straightforward (could even use zip compression of delta data per cycle/turn).
Data with templates within templates defining discrete objects is magnitudes more complicated, but the actual terrain changes over time (per frame or even per minute) would be fairly small for whats 'in sight' of the player (at least in the type of game Im thinking of that doesnt have large sections of scenery&content blown apart). So and then the sticking point is how fast you get accumulated changes as you walk into a new or not recently visited area. The active objects move all the time anyway so that update feed is continuous (use templates to compress how much need be sent for initial presence data, that then is cached with delta updates). Lots of secondary discrete objects (props - a magnitude more) ) treated likewise (just dont move/change anywhere as much as the active objects - probably good sized deltas/initial dumps).
Maybe just the number of discrete objects Im thinking of (city crowds, lots of prop objects all over which Players/NPCs can pickup/move/interact with) are already too much data flow, that without even adding changeable chunk scenery ontop of it (which in my system are just more large discrete objects and the deformations come from changing sub-components (ie- doors or wall section objects getting blown out).
BioShock 1&2 were using the older Unreal Engine 2.5 and the new game BioShock Infinite is going to use UE3 (shaders finally...)
Some of the features I saw today under UE4 (still in development due likely 2014) sound useful for some of what I want.
A MMORPG doesnt have to have cuting edge graphics so the performance issues might be less restricting.
Graphical consistency with what Ive seen on LOTRO would be sufficient if the other advancements could be added.
Having the multiplatform issue to aggrevate and increase endcases that need lots of hand tweaking for local abberations
again might be offset by the less than edge of envelope MMORPG graphics.