TerrainSampler issues with all other TerrainSamplers except the DefaultTerrainSampler

[Nystul]

There seems to be an issue with the TerrainSampler in the work-in-progress branch:
all other TerrainSamplers except the DefaultTerrainSampler seem to misbehave - also my TerrainSampler from the IncreasedTerrainDistance mod...

one can reproduce the issue when changing line:
ITerrainSampler terrainSampler = new DefaultTerrainSampler();
in DaggerfallUnity.cs
into
ITerrainSampler terrainSampler = new SimpleTerrainSampler();
or
ITerrainSampler terrainSampler = new NoiseTerrainSampler();

When loading a game the y position of the player spawn is not where it should be in relation to the terrain.

from deducing from increasedterraindistance mod interplay with dftfu:
since far terrain and near terrain are also on extremly different y-positions I think the terrain positioning is wrong rather than the player position (which matches the far terrain)

[Interkarma]

I've had to heavily rework player placement methodology to fit in with serialization/deserialization. I still need to loop back and make sure the other samplers work with the streaming world.

I'll see if I can fix this in DFTFU after today's release of the second Daggerfall Unity test build.

[Nystul]

hmm, I checked out the latest changes from git and now it seems to work. strange why it didn't work with the version a checked out yesterday

[Interkarma]

Weird. I haven't had a chance to look at that yet either. At least it works now, I guess.

[Nystul]

ok I found out what was causing the problems.

My custom terrain sampler computed averageHeight and maxHeight as absolute height values instead of normalized height values...
function BlendLocationTerrain in TerrainHelper.cs produced values larger than 1.0 for mapPixel.heightmapSamples then...

[Interkarma]

Just a quicky with the TerrainSampler. I found an interesting problem with my design.

If a user enables a mod that changes terrain heights (e.g. your improved terrain) then saves a game outside, the saved player height will be wrong if they then disable/change that mod and load the game. This can result in player falling through world on load.

This isn't really a bug for either of us, just a side-effect of allowing mods to change terrain heights. So following is how I'm going to slightly modify design to make the deserialization process a bit more self-defensive.

1. A new property called Version will be added to ITerrainSampler interface.
2. If we make any changes to our ITerrainSampler implementation that will affect generated heights (e.g. a different procedural method) then the Version number must be ticked up.
3. The serialization process will save both the current sampler and version on save.
4. Deserialization will check sampler and version on load, and if there is a difference will reset player position to current map pixel to ensure they are standing on the ground. The reset logic will be the same as when teleporting to a map pixel (e.g. player will be positioned outside city gates). The new sampler/version will be serialized on next save.
5. This has no effect if player loads a game inside a building or dungeon as they are grounded on exit anyway.

[Nystul]

a nice, encounterd this as well. Nice that there is a fix for it