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 on hash 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 the world101 tutorial, but that used seed 0 anyway, which did not change.
It turns out that the
hashprimitive 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 onhashand 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
murmur3hash 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 theworld101tutorial, but that used seed 0 anyway, which did not change.Depends on merging #1988 first.