The Wild Hunt is biased towards negative XZ offsets
ztk4 opened this issue ยท 1 comments
I built my pentacle for summoning the wild hunt in an 11x11 room underground, and have noticed the mobs tend to spawn in the wall near the negative XZ corner and suffocate instead of closer to the center of the ritual.
Taking a look at the summoning code for the 3 wither skeletons, the XZ offsets are calculated as follows:
double offsetX = (level.getRandom().nextGaussian() - 1.0) * (1 + level.getRandom().nextInt(4));
double offsetZ = (level.getRandom().nextGaussian() - 1.0) * (1 + level.getRandom().nextInt(4));
I believe the intent of the above code is to is to spawn the mobs somewhere between -4 and +4 blocks from the center of the ritual in both X and Z. The first term is supposed to range from [-1, 1], and then the second term scales it from [0, 4].
However, nextGaussian()
returns a pseudorandom sample from a Gaussian distribution with a mean of 0 and stddev of 1. That means the random number from nextGaussian is already centered on 0, with values ranging from [-inf, inf]. There's about a 68% change the value will be on [-1, 1] though (within a single std dev).
Therefore nextGaussian () - 1.0
shifts the result to be centered on -1, meaning the result is far likelier to be negative than positive; with a 68% chance to be between [-2, 0]. As a result, the XZ offsets range from [-8, 0] more often than not, resulting in enough of a bias to negative coordinates to frequently spawn in my wall and suffocate ;)
If this negative bias is truly unintentional consider:
- Removing the
- 1.0
from the first term, OR - Using a continuous uniform distribution from [-1, 1] for the first term, instead of a Gaussian. This would bound the first term on [-1, 1] resulting in an overall offset that is bounded. This might be preferable to using a Gaussian since it can technically return unbounded values (e.g. it VERY RARELY could return a value as large as 3, which could result in an extreme offset of 12) OR
- Using just
nextGaussian() * 2
as the only term for the offset. This will be on [-4, 4] ~95% of the time. To remove the possibility of larger offsets, you could always check ifabs(offset) > 4
and clamp to 4 if it does.
P.S. Thanks for a great mod. I've been having a ton of fun playing with it in the E6 pack ๐