Definitely a problem in 1.14.2 and even in 1.14.3-pre4 still. Easy to reproduce: create a new world, with seed 4.
Now create a small tank:
/fill -56 64 115 -69 68 126 glass
/fill -57 65 116 -68 68 125 water
Once you add about 24 tropical fish there, all animal spawning in the ocean around you stops.
Affects 15w47c
Affects 1.8.3.
@unknown: Proposals for a fix are always welcome, otherwise there wouldn't be anything in these comments. The /r/Mojira thread was created because the discussions turned into a is a bug / is not a bug fight.
@unknown: Your suggestion might be too complicated since most of the combinations of expansion directions wouldn't be useful. It would also cause slightly more work for the map wall crowd. I do like the intuitiveness and flexibility of your suggestion. Having varying expansions by half maps and full maps might complicate things a bit?
Suggestion for a crafting recipe to make both ways work: The regular crafting recipe (map, paper all around) gives you a larger map with more space all around. If at any one expansion you have the map in the corner instead and the same 8 papers filling the other slots, the map will be aligned to the universal grid.
By making a new custom world in 1.8.1 without caves, teleporting underground and clearing a 128x2x128 area I can almost instantly see that slimes do indeed spawn underground and in expected locations, as demonstrated in this screenshot
I was wondering if the non-functional slime farms in question rely on drowning the slimes because since version 1.8 slimes won't drown but will swim instead, what would explain why they don't work.
Right now donkeys have a jump strength of 0.5 from a range of 0.4 to 1.0. It might be sensible to give them a genotype that gives them stats from the range [0.4…0.6] and similarly for speed. Breeding donkeys would give a mix of these and a mutating gene would have a value from the same range. This way donkeys' stats would stay in the same range over time. (I do think all bad breeding mechanisms should go under this bug. Donkeys getting a stat of (donkey+donkey+horse)/3 counts as one.) Mules would then get a random mix of horse and donkey genes, giving them stats between the two. They can't breed so inheritance of their genotype isn't a problem.
(It would be nice if the stats were calculated as a sum of four uniform random variables instead of three, because then we could have pairs of variables from which one could come from each parent, similar to how dna works. This would guarantee that each parent gives the same amount of genes and that mules get two donkey genes and two horse genes. The downside is that the stats would overall be slightly more average if the range isn't changed.)
Affects 1.8.2-pre6
Affects 1.8.2-pre5
Affects 1.8.2-pre5
@unknown: I took the time to add your formula to add backwards compatibility to the proof of concept mod implementing the suggested changes.
Btw, any idea on how to incorporate donkeys too to make donkey breeding make more sense than it does now?
> I pointed out that, vis-à-vis the current system, using one random variable increases variance.
Yes, I did that too. I also pointed out that it increases it enough if you give it a multiplier of 2.414, but whether that would be good is up for debate.
> It makes perfect sense that the variance would be lower in a system where two-thirds of the weighted average value is fixed.
Variance of a single breeding isn't the same as the variance of the population. There's variance in a single breeding in the suggested system too which comes from the pool of available genes. Variance of the population is the expected difference from the mean, weighted by how likely the parents' stats are.
I can give a million awful, degenerate formulas that would give you a similar chance of improvement, but that doesn't mean one would "work" in any sense. Here's one:
if (random() < chanceToGetEqualWildHorse) then return stat*1.0000001 else return minStatValue
You can't tell if a formula works if you haven't given a proper metric to evaluate one.
@unknown: We can prove it in a similar manner than we can prove the current system doesn't preserve variance.
@unknown: Previously generated horses can be given a default U-value of 0.5 if backwards compability isn't needed, given three equal U values corresponding to their stat or creating new correct values what is what the algorithm @unknown posted today does and is what we have discussed today. Here I have dwelled on the issue of why it's more relevant to look what the formula does on an arbitrary horse rather than check one set of known parents. I just wanted to show the limit but what matters more is the drop from generation 0 to generation 1. The limit is what you get if your horses have regular accidents.
The graph shows that using one random variable loses variance. I can mention that it would work if the one random variable was given a multiplier of 2.5 and the parents 1 both. But this would mean that bred horses are essentially completely generated anew, which would discourage exploration and make foals look a lot less their parents.
I'll just add that if we look at just a fixed breeding, that variance doesn't really matter - it's always the same since it comes from the fixed random part. What matters there is the expected value that is dependent on the chosen parents and whether it is too bad or too good. The problem is that you can't easily tell what that expected value should be because it depends on the chosen parents. Variance is just a mathematical tool that tells the expected (squared) difference from the mean and it's simple to calculate. If the variance after the breeding doesn't match with the variance before the breeding, we can tell that the formula overall gives values that are too near to or far from the mean.
@unknown: The code might look scary, but conceptually it's the easiest thing one could ever think of and there is already working code for Mojang to copypaste. What we were just talking about is a way to create the values for old horses that have lost the needed information, which would be nice but in the end is optional. Think of it as creating fairly three dice rolls that have a certain sum.
Yes, the New is calculated with three random variables and no, even calculating the "New" with just one variable wouldn't work. It came up before here
I might have to make a picture tutorial of the suggested system to make the concept more clear.
Breeding arbitrary horses is actually the generalized scenario, not a limited one. It's the only way to measure the breeding formula itself is unbiased. The player naturally adds his own bias when he does any kind of selection. You can't eliminate bias from the formula but you can eliminate bias from the player to check if the formula is biased. While you can calculate the variance if you fix the parents, you have no indication of what the true variance should be.
You sampled the points of a cube intersecting a plane of constant values, but I think here's actually a simpler way to retrofit the gene variables for backwards compability (generate three random numbers with a fixed sum).
//aiming for a sum of k
double[] g = Arrays.sort({0.0, k*this.random.nextDouble(), k*this.random.nextDouble(), k});
result = {g[1]-g[0], g[2]-g[1], g[3]-g[2]};
Edit: Nevermind, this can actually just give the cases where the sum is at most the maximum for a single variable (the triangles in your example). Isn't this equal to the contents of your while loop with some scaling?
@unknown: I especially like how it still encourages exploring and finding new horses, as once you get the best bits of all your horses aligned in a foal, the way to get an increase is a mutation or finding new horses that have good values (not to mention colour). And like your said, even average horses might be a mixture of very good and bad variables.
I have also submitted a formal proof of the current formula being awful in case someone still gets it into their heads that there's nothing wrong.
[media]@unknown: I think your wanting to quantize the stats because you are bothered by not having perfect information is besides the point of this bug report and perhaps should go to the suggestions subreddit. The method you mention seems completely ad-hoc without any statistical basis.
I might add that if you saw my last post, in the example I gave two horses that jumped 2.64 and 2.81 blocks managed to give birth to a horse that jumps 3.96 blocks. The difference can thus be notable without resorting to quantization, if only the breeding formula wasn't wrong.
I made a proof of concept mod for Minecraft 1.8 for testing the suggested formula
This naturally keeps the population at the equilibrium, since now bred horses are now calculated in the same way as wild horses, only using information from the parent instead of random numbers.
Here is an "action shot" from a test run, showing the fourth foal of two parents (the first one to show a mutation).
@MacchuPicchu the problem is with the math. A way to keep tabs is to decompile MC source code with e.g. DecompilerMC and open file server/net/minecraft/world/entity/animal/horse/AbstractHorse.java
The problem is this part (this is from 1.18.2, but it's the same it has always been):
protected void setOffspringAttributes(AgeableMob ageableMob, AbstractHorse abstractHorse)
double d = this.getAttributeBaseValue(Attributes.MAX_HEALTH) + ageableMob.getAttributeBaseValue(Attributes.MAX_HEALTH) + (double)this.generateRandomMaxHealth(); abstractHorse.getAttribute(Attributes.MAX_HEALTH).setBaseValue(d / 3.0); double d2 = this.getAttributeBaseValue(Attributes.JUMP_STRENGTH) + ageableMob.getAttributeBaseValue(Attributes.JUMP_STRENGTH) + this.generateRandomJumpStrength(); abstractHorse.getAttribute(Attributes.JUMP_STRENGTH).setBaseValue(d2 / 3.0); double d3 = this.getAttributeBaseValue(Attributes.MOVEMENT_SPEED) + ageableMob.getAttributeBaseValue(Attributes.MOVEMENT_SPEED) + this.generateRandomSpeed(); abstractHorse.getAttribute(Attributes.MOVEMENT_SPEED).setBaseValue(d3 / 3.0);
this
is parent A,ageableMod
is parent B andgenerateRandom{_}X{_
} is the infamous third horse.