Fix world DSL hash
primitive to depend on seed
#1989
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It turns out that the
hash
primitive was always computing the same deterministic hash of the coordinates regardless of the seed. This meant that e.g. any world features placed in a way that depended on the hash were always in the same locations, and if you created a world that only relied onhash
and not on, say, Perlin noise, it would always look the same regardless of the seed. This does not seem desirable.This PR fixes the DSL interpreter by passing the seed to the
murmur3
hash function (we used to always pass the constant seed 0). In theory, this does mean that all the "classic" worlds are now slightly different than what they used to be (except for seed 0). However, there's no way to tell the difference between one random placement and another. The only scenario where we really depend on the particular locations of entities for a particular seed is theworld101
tutorial, but that used seed 0 anyway, which did not change.Depends on merging #1988 first.