Altti Tammi
- Angs
- angs
- Europe/Helsinki
- Yes
- No
MC-74153
Affects 1.8.2-pre1
Affects 1.8.2-pre3
Affects 1.8.2-pre4
The problem with the formula used now - why breeding isn't at all likely to give any benefit
speed_of_stat_increase.png
Affects 1.8-pre3
Affects version 1.8
After applying my patch to MC-3416 that draws the map markers in front of the map instead of behind it, Fang Zhang was able to take this screenshot that shows map markers that have been duplicated.
After a simple test I have a found a way to replicate this bug in the vanilla:
- Create a new regular superflat world
- /tp 0 5 -200
- /setworldspawn
- (to make sure 0,0 gets unloaded)
- /tp 5 5 5
- Create a map and put a copy in a frame, leaving one copy in your hand.
- /tp 5 5 200
- /tp 5 5 5
- Repeat last two steps twice.
- Drop the map from your inventory and pick it up again
Your marker has now disappeared, because
MC-3416hides all markers except the first four and reloading the chunk three times has now duplicated the marker in the frame to fill slots 1-4.After applying my patch to
MC-3416that draws the map markers in front of the map instead of behind it, Fang Zhang was able to take this screenshot that reveals that map markers have been duplicated:
After a simple test I have a found a way to replicate this bug in the vanilla:
- Create a new regular superflat world
- /tp 0 5 -200
- /setworldspawn
- (to make sure 0,0 gets unloaded)
- /tp 5 5 5
- Create a map and put a copy in a frame, leaving one copy in your hand.
- /tp 5 5 200
- /tp 5 5 5
- Repeat last two steps twice.
- Drop the map from your inventory and pick it up again
Your marker has now disappeared, because
MC-3416hides all markers except the first four and reloading the chunk three times has now duplicated the marker in the frame to fill slots 1-4.
After applying my patch to
MC-3416that draws the map markers in front of the map instead of behind it, Fang Zhang was able to take this screenshot that reveals that map markers have been duplicated:
After a simple test I have a found a way to replicate this bug in
thevanilla:
- Create a new regular superflat world
- /tp 0 5 -200
- /setworldspawn
- (to make sure 0,0 gets unloaded)
- /tp 5 5 5
- Create a map and put a copy in a frame, leaving one copy in your hand.
- /tp 5 5 200
- /tp 5 5 5
- Repeat last two steps twice.
- Drop the map from your inventory and pick it up again
Your marker has now disappeared, because
MC-3416hides all markers except the first four and reloading the chunk three times has now duplicated the marker in the frame to fill slots 1-4.
After applying my patch to
MC-3416that draws the map markers in front of the map instead of behind it, Fang Zhang was able to take this screenshot that reveals that map markers have been duplicated:
After a simple test I have a found a way to replicate this bug in vanilla:
- Create a new regular superflat world
- /tp 0 5 -200
- /setworldspawn
- (to make sure 0,0 gets unloaded)
- /tp 5 5 5
- Create a map and put a copy in a frame, leaving one copy in your hand.
- /tp 5 5 200
- /tp 5 5 5
- Repeat last two steps twice.
- Drop the map from your inventory and pick it up again
Your marker has now disappeared, because
MC-3416hides all markers except the first four and reloading the chunk three times has now duplicated the marker in the frame to fill slots 1-4.I took some additional screenshots after a command block machine had teleported me back and forth for some time, which demonstrate both
MC-3416and this bug: The map marker has been duplicated and the markers are being offset in the wrong direction.
Linux and OS X, Java 1.8u25, Java 1.8.0_66
Affects 1.8.2-pre1
Affects 1.8.2-pre3
Affects Minecraft 1.8.2-pre4
Affects 1.8.2-pre7
we had a survival map for quite some time, when maps were able to be duplicated we decided to make maps for both of us (there are only two people on the server) it worked fine until item frames were added, then we wanted to make waypoints on our map using more duplicate maps and item frames. duplicating done with an empty map.
when we put the first two maps in the item frames it worked fine, but on the third extra map we noticed it didn't make a green arrow on our map. so taking it off and using the other version of the map in my hand made the green arrow appear. but then I "fell" through the map myself, so I quickly swapped back with the map on the frame, I broke the frame but the arrow stayed, however i was still not on the map. i later walked into an uncharted area to see myself for a second or two under the terrain being charted.
Steps to Reproduce:
1. duplicate a large map use the duplicate to make more copies (I think the issue lies here)
2. put the maps in various item frames around a world, we put ours in the villages we found.
3. you will notice on the 5th active map (there was me and my friend with maps on at the time, as well as two maps already working perfectly) will not show on the item frame, the actual map will be there, but not the green arrow. like I said through experimentation I noticed that the arrow still existed it was just under the terrain.
One line fix by Altti Tammi can be found in this comment
Altti Tammi: The mapping is a monotonic function, so changes in both directions are always equally likely, like an ordinary random walk. The magnitude of those changes is just gradually compressed to keep the stat within bounds.
jonathan2520 Your method seems like a very elegant mathematical solution (didn't actually run through the algorithm, but I think I got the intuition), but probably not very appealing from a programming perspective, as well as it is not as readable as code. I think I would prefer something simpler such as:
offspringStat = min( max( (Pa+Pb)/2+random, minimumHorseStat), maximumHorseStat); //random comes from some distribution with expected value of 0. Probably Gaussian-ish.
Your idea nicely addresses and fixes the problems that occur with this method when both parent horses are an extreme case. But I think that practically either one would suffice and that very few players would be able to distinguish between the two, especially not until they had very good horses anyway, which is when the differences between the two methods would manifest themselves. I could be wrong about this, I think the easiest way to find out would be just to implement both and test them seeing if there is any real difference from the players perspective.
Altti Tammi I also thought about your method, and I would be quite satisfied with it as well. My only complaint with it would be that it does not necessarily mean good game progression, but this is really just my preference. To demonstrate this let me give an example.
ParentA is good at running/jumping but has crappy health. ParentB has good health but really bad at running/jumping. The offspring could either be perfect, or flawed in one or more aspects.
In the case of perfect, then the player has achieved the ideal horse after 1 breeding instance, not very rewarding in my mind.
In the case of flawed, the horse will be really bad at one or more of those things, in my mind making the horse not fun, and not really a step up from either parent.
If on the other hand things were averaged, the first case of a perfect offspring is not possible, and the second case would be a more well rounded horse rather than a horse extremely flawed in one or more aspects, which I think makes better for game progression.
But again, I like your method too, and would be quite happy if it was implemented.
Any word from anyone on the Mojang team about this? Is this all moot because they are already working on some fix?
Altti Tammi: That would almost work. Hint:
logistic(stddev * nextGaussian() + logit(normalCappedStat))
How would other mappings work? These don't approach the edge as fast:
x/sqrt(x^2+1)/2+1/2 (speed in special relativity)
arctan(x)/pi+1/2 (angle)
Altti Tammi: Good point, playing around with that idea I agree with you now. So I am now completely behind supporting your method of:
offspringStat = randomParentStat+noise.
Are there any other ideas floating around though?
I completely agree with the mathematical niceness of handling the edge cases like you two are considering, but I am not convinced it is necessary. (And worry it is likely to scare away the Mojang Programmers? I do not know how much math they like?)
Consider the example:
Let the scale of stats be 0-10, and choose a bell curve with std dev 0.5, a pretty large standard deviation in my mind. Half the time the stat will change by more than ~0.3. A quarter of the time it will change by more than ~0.6. This seems reasonable to me?
If your horse is 9, then ~2.5% of offspring would be perfect. If we consider all three traits being 9, then the offspring will be perfect ~0.0015%.
If your horse is 9.5, then ~15% perfect. All three traits being 9.5, perfect offspring in all three ~0.3%.
If your horse is 10, then 50% perfect. With three traits 12.5% will come out perfect.
So to get a perfect horse it seems like it would still take a bit of work without limiting gains near the top.
So sure, by not dealing with the edge cut off, a perfect horse is attainable, but depending on the kind of standard deviation that Mojang wants and if they are ok with people getting perfect horses, it may not be necessary? So I am a fan of this approach as a first attempt:
offpsringStat = min( max( randomParentStat + random, minHorseStat), maxHorseStat); //random is from some bell curve type distribution with mean=0, and std deviation of about 1/10th-1/20th of the horseStat range.
If it doesn't work out in testing because it's too easy to get a perfect horse, or they don't want perfect to be attainable, then try the more complicated thing.
I wonder if this thread is so long that everyone from Mojang stopped reading?
Altti Tammi: I did consider the error function. The roundness is nice. But Java doesn't have it, and its inverse is even harder to get.
x/sqrt(x^2+1) would need some special handling of huge numbers, yes. Its problem is not division by zero but division by infinity (awkwardly producing zero) and eventually division of infinity by infinity (producing NaN). Not hard to fix, though. The most natural expression of its inverse (x/sqrt(1-x^2)) only has a division by zero at the edges, producing a correct infinity.
Erik Skau: The problem without some kind of tapering is that the same increment has the same cost at every level, even if horses at that level should be rare. You may want to tweak the standard deviations and all so the casual breeder can get a reasonable improvement at a reasonable cost (time, materials). Then a hardcore breeder only needs to invest a small constant factor more to get a coveted 
perfect horse. Strong horses should be more valuable than that.
I figure someone at Mojang might eventually read this, if they read as much as they write. This shouldn't be too much math to verify. The complexity is much lower than that of much of the rest of the game, which is somehow only moderately buggy.
Altti Tammi: How did you make that graph with the logarithmic scale? I just ran a similar simulation and got a much brighter picture. Starting with a pool of 10 wild horses and breeding 550 times (not quite millions!), my average of all percentiles of the best horse exceeds 90%. Starting with 2 horses and breeding 600 times will also do. It confirms my suspicions that maximizing multiple variables is relatively easy. I'm sure my strategy isn't even optimal, but perhaps yours is very suboptimal? I don't think I have a bug; if I use the old univariate strategy in the same framework I get results that agree with everything we've seen so far.
Altti Tammi: Even with a very naïve strategy (one stat at a time, making sure the others don't drop below the goal) it only takes me a few thousand attempts to exceed the 90th percentile in every stat. This is fully simulated breeding based on a live strategy, which is exactly what you'd be doing in the actual game if you were patient enough. No high-level models that might be wrong, no way to rig it. So how did you combine different stats?
I should add that my previous post underestimated the numbers, but only by a few tens. My continuous health percentile based on the discrete version in wild horses was a little biased. Not a big deal.
Sebastian MAlton: I had thought of that concept. The first objection is that it would be hard to make it work with existing horses. You'll also want to make sure you're happy with your phenotype equation, because you can't change it later.
Altti Tammi Thank you very much for confirming that the slight change works "like a charm" };]
Is more fair, but still remains a challenge.
@all: If Horse Breeding would need no change, Mr. Bergensten wouldn't have assigned himself to this bug.
I sense some negative emotions coming up during the last posts, so please calm down.
I'd like to tell you that I'm testing, breeding and researching the Horses ever since the 1.6 Snapshots.
http://puu.sh/eS0X9/22088a9848.jpg
In April 2015 this will be 2 years realtime already.
In order to figure that Horse breeding is "unfair", maybe one not only needs to be able to read the code and the graphs/distribution properly, but also actually see with their own eyes, or rather handling bajillions of foals with certain stats/abilities, like I do since so long (not the whole time, of course, but often enough).
For me, it's even worse, as I'm aiming for "the perfect Mule" (as you can attach chests to them), which means I've got to have "the perfect donkey" first.
(Don't take the "perfect" too serious - it's more like an approach to very good abilities.)
Wild Donkeys have got (mediocre as for Speed, and quite bad as for Jump Strength) fix abilities/stats, which makes improving them a challenge.
I'd just hope that Mr. Bergensten would briefly explain as of where he stands/how he sees the situation, before this here gets out of hand maybe (I already mentioned the "Bad vibrations").
Mojang has the final say in it anyways, so it would be nice to hear back from them, after soon 2 years, what they think in general, even more after reading through so many comments here.
Kind regards,
Meri
Most blocks you don't like can be omitted with minimal impact. You start out with 42 testable heights per full block. You'd lose 4 of them if you omitted the end portal and the cactus (because inconvenient blocks are to blame for your breeding experience). That's still close to 200 heights you can test this way, with more jump strength precision at the upper end where you'd likely need it. That's already a quantized extended phenotype much like you suggested earlier, but more granular. Yet you also said a coarser version was a problem because it's too coarse? Also, contrary to your claims, a quantized genotype would only make it approximately impossible to reach the next quantum.
I like Altti Tammi's proof of concept. It's simple indeed, really just the current system broken into pieces. You can more or less transfer between versions, if you fill in plausible genes while loading and keep storing the phenotype while saving. Overall it behaves much better. Horses at extremes will tend to produce similar foals, at the risk of a mutation most likely pulling them toward the average. Still a reasonable chance of improvements. Most average horses become an interesting gene lottery. Intuitive breeding works. If you're observant enough you can infer some information about the genotype and improve your chances. I'd have to playtest it, but it's promising.
Altti Tammi: Nice.
Donkeys are just weird. They spawn with fixed stats but somehow breed normally. Preserve that behavior for now, I guess. For any stat that should be fixed, set the phenotype and run pheno2geno.
Speaking of pheno2geno, here's a generalized version that can work for different numbers of genes (as long as it doesn't end up rejecting too often):
void pheno2geno(double[] geno, double pheno) { // Mirroring is the simplest way to bound rejection sampling. // The way it interacts also obviates the need for range checks. boolean mirror = pheno > 0.5 * geno.length; if (mirror) pheno = geno.length - pheno; generateAndCheck: while (true) { // Generate non-negative random numbers that add up to pheno. for (int i = 0; i < geno.length - 1; ++i) geno[i] = pheno * this.rand.nextDouble(); geno[geno.length - 1] = pheno; Arrays.sort(geno); for (int i = geno.length - 1; i > 0; --i) geno[i] -= geno[i - 1]; // Make sure each value is in range, as if the loop is: // do { ... } while (geno[0] > 1.0 || ... || geno[geno.length - 1] > 1.0); for (int i = 0; i < geno.length; ++i) if (geno[i] > 1.0) continue generateAndCheck; break; } if (mirror) for (int i = 0; i < geno.length; ++i) geno[i] = 1.0 - geno[i]; }
But above all I changed the description. I think it's a little too hard to visualize for most. It didn't help that I didn't describe it very well. I'd do a better job now, but we'd be talking about simplices and such now that it's been generalized. Not helpful to most of you, I presume.
I'll probably be less active for the time being; sensory overload broke me.
What are you trying to say? We've been over that.
Keep in mind that 'statistics functions' tend to be the limit of a simple process. A normal distribution emerges from a random walk, for instance. To pick something more relevant to the problem, alpha blending is a statistical agglomerate of coverage masks, that becomes quite pathological when said coverage masks are correlated. Using this sort of thing as a primitive isn't always a good idea. It's often better to model an underlying process from which desirable behavior emerges. More so when the discrete nature is desirable.
The anniversary of Altti Tammi's cracking an egg of Columbus and my polishing it is coming up. Is anything ever going to happen?
On this OSX, playing version 1.5.2, you can see some z-fighting while tilting the map; the hidden markers flicker to view (see attached images).
Problem exists still in 1.7.2.
This must be why I always end up outside behind the back wall of my stables when getting off a horse.
It seems they were trying to fix players nudging carts and boats when getting off and went out of the frying pan into the fire, so to speak. The old functionality was better, seriously.
Jar_: There isn't a way to easily tell horse stats without mods in the snapshots, but unless the formula is changed the problem is still there. It's a math problem instead of something that would go away without anyone touching it.
The problem is that (Pa+Pb+New)/3 makes the foal stats tend to average, because of the New part. If you breed two perfect horses with a max stat, say 1.0, the foal will always be worse than the parents, getting (1.0+1.0+0.5)/3 = 0.83.. on average. The same goes on the other end. Adding the variation as one equal third doesn't make sense. Just with the fact that the formula in another form is 0.66 * average_of_parents + 0.33 * newrandomvalue it's obvious the foals get kind of average, with excellence nowhere to be seen. The problem is that the expected value of a a foal's stat isn't the average of its parents' stats like one would expect, but 33% from the parents' values toward average.
Instead each attribute should be selected from just one of the parents and sufficiently randomized by e.g. gaussian noise. Java Random has a nextGaussian method that fits this use perfectly, giving us:
This then might need to be kept in range of allowed values, with:
The gaussian noise makes exceptional horses rarer but at the same time there's the tiny possibility for very exceptional values. The resulting distribution has two spikes at the parents' stats' locations and gradually get lower around them, representing the parent the value came from and a little bit of mutation from the gaussian noise. The foal will look like one of it's parents in each stat.
The following are the standard deviations for the current system (
assuming it uses uniform random numbers a.k.a. nextDouble()edited after hunting down the implementation from MCP), which might be good for the suggested system:Health: 1.149978
1.4433757Jump strength: 0.033314
0.0577350Speed: 0.012506
0.0216506Calculated by sqrt((((max-min)/3)^2)/12)Sample standard deviation from simulated values(Although I wouldn't recommend it, it's also possible to use both parents directly to calculate the new value if necessary:
Where the standard deviation can be the maximum of sqrt(((parentA-parentB)^2)/12) and the above mentioned values, which guarantees a minimum variation in case of identical parents and that horses can be better/worse than either parent. In this case the resulting distribution has just one spike at the parents' average, which might not be preferable for maximizing fun.)
Edit: After a quick test I'm quite sure nothing has changed in 14w11b. After breeding summoned perfect horses:
/summon EntityHorse ~ ~+1 ~ {Tame:1,Variant:257,SaddleItem:{id:329,Count:1},Attributes:[{Name:"horse.jumpStrength",Base:1},{Name:"generic.movementSpeed",Base:0.3375},{Name:"generic.maxHealth",Base:30}]})Unlike their parents, none of the ~20 babies had 15 hearts and just one was able to jump 5 blocks high.
Double post, but just to give perspective: if you have two ok horses that have all stats at 70 out of 100 and want to get a horse that has 75 out of 100 in all stats, i.e. a slightly better horse, the "third horse" has to have at least 85 in all three stats ((70+70+85)/3=75). The chance that all stats are at least 85 is 0.15*0.15*0.15 = 0.003375 or approximately 1 out of 300. That's a lot of gold and useless horses to get rid of, just to get a slightly better horse.
EDIT: It's actually MUCH MUCH worse than that. Apparently jump strength and speed are not calculated by one uniform random number but as a sum of three independent random numbers (health is also calculated as a sum of two random integers, but let's ignore that to simplify things, even though it would lower our chances even more). Because of this, the chance to get above 85% in the random part of one of these stats is in the ballpark of 1.52%. The example is changed to 0.15*0.0152*0.0152=3.4656e-5 or approximately 1 out of 28900. In fact, the chance to get just a baby that's ONLY better in all stats from our example 75%/OK-horses, no matter how small an improvement, is 1 out of 782. Just better speed? 1 in 14 horses. In other words: Don't bother breeding.
jonathan2520: It counts in the sense that the numbers were wrong and that the chance to get a better horse is lower with breeding than finding in the wild, since in the case of good random values the parents' stats bring the final value down and to compensate that you need a better random value that is much rarer than I previously thought because of the distribution. Think about the 75 / 85 example, in the wild it's enough to find the 75 horse, with breeding you need the 85 random value to get the same results. In just that one case with one stat it's more than four times more difficult to get to the same result with breeding. Your point about a matching foal holds, but my example was mainly to demonstrate that even though you are "able" to produce a foal that has better values than its parents, the odds aren't exactly in your favour (unless the parents were bad, of course, then it's very easy). The main problem is the mediocre expected values and the resulting futileness of breeding.
Affects versions 14w18b, 14w20b
Affects version 14w25a
Confirmed in 14w32a. It might be that this works as intended, but please reconsider this. Small servers might have everything worthwhile built around spawn, couple of kiloblocks away at most, so with a single map that was centered on spawn one could have most of the busy area covered.
Affects version 14w33c. Sebastian MAlton, you have misunderstood. It should work like that, but doesn't.
It bears repeating that while these new not centered maps are good for tiling multiple walls, they are bad for single maps. Judging from the votes this bug has and the previous non-tiling bug got, the previous behavior was better. Maps aren't just for big walls of maps, lots of people have a bad sense of direction and like a map centered on their base. Practical use should trump decorative use.
I don't have anything against maps that tile easily, but they should be optional. Some new recipe might work, e.g. old map + slimeball would snap the map to be the adjacent one, depending on the relative direction of the items, which could be done in the small grid for all 4 (or 8) directions.
Joseph Charron: If your base happens to be in a corner of a map, you have to have 4 different maps to be able to properly navigate in the vicinity of your base. I'm 100% sure maps of the US don't have Kansas in a corner. There's nothing hard from a programming perspective in allowing arbitrary centre points - there aren't any grids.
The snap idea was to craft a (copy of a) map into its neighbor, emptying it in the process. You wouldn't have to walk 1000 blocks to do it - you could do it everywhere in the world. Slimeball right of map? Moves map center east 128*2^maplevel.
I agree it's not a bug, but hey, neither was the previous one and it still got fixed. At least Mojang might read this if it's marked as a bug.
@Joseph I didn't say there isn't a grid now, but that there isn't one when arbitrary center points are allowed. When programming it's just a question of doing a modulus. Why is the Kansas reference silly? It's the exactly same problem people might have - the map shows only a quarter of the areas they are interested in.
I really think people shouldn't be required to choose their home based on where it falls on a grid. A single map isn't a world map and should be allowed to be centered to show whatever is necessary. The purpose of a single map is very different compared to a huge wall of adjacent maps and these gridded maps are helping people who want fancy map rooms at the expense of people who just want to see where they are.
jonathan2520: And by the time you get one stat to be good enough, the others have diluted to average values. (Btw, your numbers suggest you meant jump strength, not speed. The probabilities are the same for those two, so it doesn't matter.)
Affects version 14w34b
Erik Skau: Me too. I wrote my suggestion earlier in the thread too, but I'd prefer using just one of the parents for each stat, adding normally distributed noise (magicNumberStandardDeviation*Random.nextGaussian()) to it and capping it to the limits. It follows the pattern that is used for the colours too, that the foal clearly "looks like" one of its parents. Will the horse be strong like it's father and quick like his mother, or will he be dealt a bad hand in the gene lottery. On average it's the same as using the average, but it's more variable this way. One horse in 64 gets all stats from the better parent and get noise that improves those, and one horse in 64 will be worse than its parents in all aspects.
jonathan2520: Your example is quite hard to follow without diving further into the mathematics. Would this random walk be able to improve a stat that is already good and what would be the odds?
In 14w34c
In 14w34c,14w34d and 1.8-pre1
Affects 14w34c
Erik Skau: There would still be the random variation / noise, which could either increase or decrease the value. If the parents' average would be used, the noise would have to be in proportion of the difference of the parents if the foals should have a chance to exceed either of the parents (see my comment here). It might work, I'm just wary of using averages since the problem at hand is partly caused by averages. If you have two horses that are very good in some stat and bad in others, getting an all-around good horse is hard. Toy example:
a: 10,0
b: 0,10
c: 5,5 (a+b)
d: 7.5, 5 (a+c)
e: 3.5, 7.5 (b+d)
And so forth.
jonathan2520: I think I understand what you are getting at in your example and I think the logistic function and its reverse (logit function) fit perfectly for the capping, compressing the gains near the maximum while still having equal chance for raising or lowering the value. Here's my revised suggestion / pseudocode
jonathan2520: Fixed. I don't think approaching the maximum faster is necessary a bad thing, it's more fun that way. Even the error function might be a natural choice, but it's obviously not a good idea. At least the formula of the logistic function feels natural. The logistic function also has a benefit, at least compared to your first alternative: log and exp behave properly with infinitys, so the transformation works properly at the limits. x/sqrt(x*x+1) and its reverse have a division by zero, giving a NaN.
Affects version 14w34d
Affects version 14w34d
Erik Skau: Well, the math part is already thought out for them, free of charge
It's not that hard anyway, this picture tells a lot - it just stretches the limited range to an infinite one for adding the noise and then we do the reverse. I like the fact that perfection is unobtainable - there's still competition even at the high end. The normalisation that is done is a bonus - every stat can use the same formula. Otherwise you would have to keep track of the different standard deviations for all the stats.
I too wonder if anyone at Mojang reads these - I can imagine it doesn't help that this bug has been assigned for a long time.
Bonus implementation tips for Mojang: In case you write out the min/max values in the class for the limiter, you can make the stat generation use them instead of the hardcoded different formulas that are used now to make sure they match.
I ran some simulations on my latest suggestion to see how fast you reach to a certain percentile from a starting stock of 10 random horses, with different values for the magic number (standard deviation of noise) - the results are here. For comparison, in the breeding formula used now, it takes ~150 breedings to get to 0.7 and ~1000 breedings to get to 0.75.
Affects 1.8-pre1. (I wonder if anyone at Mojang reads these, it's been over a year since [Mojang] Jeb (Jens Bergensten) last commented on this issue)
Affects 1.8-pre1
Could someone mark this for 1.8-pre1?
Graphs are great.
Here is a graph showing how fast one can get the average stats of the best horse to increase to a certain level (notice the logarithmic scale) with the current breeding formula:
Here is another fun graph (about the current formula): inspired by jonathan2520's last comment about maintaining the distribution - results of a simulated life of a group of horses, breeding random horses and killing the oldest to maintain size.
The standard deviation of the average stat of the bred horses drops by 62% compared to the wild horses.
jonathan2520: It was done using the current thirdHorseAverage generation method, so it's the same numbers you posted here, but considering all stats instead of one.
Sebastian MAlton: A multiple gene system would be nice, but it would be much more of a hassle to e.g. summon horses if instead of 3 variables you need to specify 3*n_of_genes. It also wouldn't be backwards compatible with the variables the horses use now and it wouldn't be as easy to reason about the statistics. Such a system is probably best left for modders to do.
jonathan2520: I think I may have found the source of the confusion - I mistakenly spoke about percentiles, even though I meant stat values normalised to the range [0,1].
Also I experimented with different strategies and always taking the two horses with the best average (normalised) stats seems to be faster (albeit a bit different) than taking the two with highest minimum stats, which is faster than optimising one stat at a time.
Affects 1.8-pre2
Harv Pryce: Guess again
Affects 1.8-pre2.
Samuel Shank: It would be nice, but I don't think that's an option anymore at this point in the release cycle..
To the people in power to fix the bug:
This z-order issue has a one-line fix in the official equivalent of MCP's src/minecraft/net/minecraft/client/gui/MapItemRenderer.java:
In the last line of the loop where the icons are added, there is a variable that is increased (++var6; in MCP). Decrease this instead (--var6;) and the z-order will go in the right way:
Edit: If you want to fix this for yourself in 1.7.10, open the file bbz.class in a hex editor and at the offset 0x967 change 84 06 01 to 84 06 ff. (Usual modding requirements like a using a custom version and deleting META-INF apply.)
Dolphin263: It's a bit harder because the right class file will be unknown, but it should be possible.
Edit: In 1.8-pre2 it's offset 0x921@buc.class, 84 07 01 -> 84 07 ff
Edit2: Affects 1.8-pre3, the offset above seems to be the correct one to fix it for 1.8-pre3 too.
Affects 1.8-pre3
Affects 1-8-pre3
Affects version 1.8
For those who want to implement the fix: Change offset 0x921@bue.class from 84 07 01 to 84 07 ff. Linux and Mac users can use this installer to fix it.
Affects version 1.8
Affects version 1.8
Nicholas Canales: I added a Windows installer script (PowerShell, comes with at least Win7) and some instructions too.
(Michael Adam Gabzdyl's instructions are correct (apart from the missing bit about deleting the manifest), the script automatizes parts 1-5 in his instructions. You'll have to edit the profile yourself.)
Dolphin263: The flag M for jar tells it to remove the manifest (META-INF). And good call, that part is necessary for any modding. The bug (and the fix) is client-side only.
Nicholas Canales: The script doesn't need any input and fluency in PS isn't necessary (unless you want to verify the script doesn't delete your c drive, which at least someone should!
). First download the script from this link with Save as. If your system is configured to allow running scripts you could just double-click it, but I wouldn't count on it. Instead, open the Run dialog (Win+R) and enter, changing the path if necessary (this one is for the Downloads directory in your home directory):
powershell.exe -ExecutionPolicy Unrestricted -File "%UserProfile%\Downloads\mapfix_installer.ps1"
(Windows might then give scary warnings about how you shouldn't do what you are just about to do, because they think scripts are somehow more dangerous than other executables.) Remember to change the version (Edit profile) in the launcher.
Too bad. It seems like the jar program that can manipulate the .jar files only comes with the Java JDK, not the JRE that is required for Minecraft. I was hoping there was a way to do this on Windows without any external dependencies that aren't installed by default, but apparently not. I almost certain I can't redistribute just the jar.exe and Oracle doesn't have a separate download for it,
so for now downloading the JDK is the only option.Edit: There is now an option to use the command line version of 7-zip for those who don't want to download and install the whole JDK.
Zachariah White: It's amazing this bug has been left virtually unseen by Mojang for almost two years now and it seems like it won't be fixed in 1.8.1 either. The fix would be so easy, if only someone would look at this for a few seconds.
Oh yeah, affects version 1.8.1-pre1.
a: It a slight exaggeration to say it didn't get fixed at all - the smallest foals did get fixed. None of the intermediate sizes work as you mentioned - teenage foals still look like adult horses. Before 1.8 they had a total of 8 stages/sizes IIRC.
Mods: please reopen and mark 1.8.1-pre3 as affected.
Affects 1.8.1-pre3.
Fang Zhang: This is actually another bug, not an underlying issue to this one. The wrong z-order and your marker duplication are equally bad, but I think your find would warrant another bug report. I'm not sure if it can be accepted as you are playing a modded game. It's still worth a try I suppose. Your image made me think about a map I have ingame and explains perfectly why a certain marker looks "3D" in the item frame - there are a lot of duplicates stacked, though not as many as you have.
No wonder why in vanilla I have had maps that show only one marker without the patch, even though there was just one copy on a wall and one on me - the one on the wall must have been duplicated.
Affects 1.8.1-pre4
Fang Zhang: I submitted the marker duplication as
MC-74153. David Buckley: You guessed correctly, they can be seen behing the frame (see mentioned bug), which proves the cause for this bug too - markers are being offset in the wrong direction.Affects Minecraft 1.8.1-pre5
Affects Minecraft 1.8.1
Affects Minecraft 1.8.1
Affects Minecraft 1.8.1
Affects 1.8.1
In 1.8.1 the bug can be fixed at offset 0x923@buc.class, change 01 -> ff. I updated the installer for the fix to include 1.8.1.
Jenny Rooker: If cheats are enabled you / an op can use summon commands to spawn a horse with the stats and color you want. Click "view all comments" and search for "summon" for an example. The only way to play it safe is to have two best horses locked up and always use their foals even though they aren't as good as their parents.
Victor Baker: There's nothing new with your results. All of the stats of your horses were below average, so an increase is expected. The bug/misfeature isn't about breeding a perfect horse, it's about wanting any kind of increase in stats for breeding above-average parents. There isn't any point in breeding below-average horses like you did when literally 50% of horses are above-average. This isn't about 0.01m/s increases, you can't get anywhere near the best stats as it is. Breeding isn't fun when your expected outcome is bad horses. (Bad being defined as worse than the parents.)
See these three images for the distribution of the stats. Your breeding results are somewhat good but nothing stellar and likely you aren't going to get anything better. 28 hp is good, but hp has a different distribution and is thus easier to get up.
http://i.imgur.com/M7HpUcJ.png | http://i.imgur.com/ie1n9uR.png | http://i.imgur.com/QoeRpFc.png
Jump strength is relevant in the minecraft world. It is the upwards speed at the base of the jump. The total jump height is then affected by gravity so the relation between them isn't linear.
Since it's buried in the comments now, here's my current suggestion for a more fun mechanism which is compatible with current stats and allows to get an increase in stats while still being competitive in the upper range (you can't get perfect).
Victor Baker: They are the distributions of wild horses and thus also distributions of the random factor (the infamous "third horse"). The problem is that the random noise is centered on the average of all horses instead of the parents' average and the fact that the random noise has the same distribution as the horses, making a drop towards average even more likely.
From this picture showing the expected increase in stats you can check your progression:
Your best horse's stat average is now ~0.68 according to this chart, which makes sense if you bred 170 horses (at a cost of 150 gold). To take you to an average of 0.8 (which would mean 27 hp, a 4.5 high jump and a speed of 12.6 m/s, still far from the maximum) would take you well over 1000 breedings. For most of us that doesn't sound fun.
Victor Baker: That would actually make things arguably worse, because it would reduce the variance and getting an increase in stats would be even more difficult. Trust me, it won't be that simple - the whole third horse concept is flawed.
My suggestion isn't complicated - it's just a mapping of an infinite range of "goodness" into the finite stat range with a logistic function and giving an increase or decrease in stat a fair 50% chance. Plus selecting each stats randomly from one parent to get some sort of likeness more apparent.
Victor Baker: I think there is a misunderstanding here. If you take my suggestion to the extreme, giving the random part a multiplier of 0, you would actually always inherit each stat from one of the parents without randomness which is exactly what you describe, making finding a good exceptional stat important. What the mapping would do is give a slight variation to the stat while at the same time making perfection impossible. In your suggestion the foal's stats would still be at the average of the parents' stats, so it wouldn't do any good to breed horses with different exceptional stats.
Edit:
This discussion has given me an idea that I tested and I might change my suggestion to as follows:So instead of both parents use one, the "third horse" is uniformly distributed instead of using the wild horse generation (no amount of multipliers can make that give the same distribution). The chosen multiplier seems to do a good job at keeping a randomly breeding populations' stat distribution same as for wild horsesScratch that, absolutely too much variance. I'll stick to my previous suggestion.
Meri Diana: I revisited the idea you posted today, about >=three variables per stat and tried it in action. It works very nicely and I like the idea very much. Previously I was against multiple "genes" because of summoning hassle, but it can be avoided if it's okay summoned horses aren't good breeders (Default value of 0.5 for all genes) or if the genes are added in a version where it's allowed to change entities, they can be given three equal genes corresponding to their stat. Genes are from the range (0,1).
Since (most of) the stats are calculated by a sum of three independent uniform variables, those should be remembered and used as additive genes. When a new foal is born, it gets each gene from one of the parents, with a mutation (new uniform random number) happening maybe 10% of the time. Backwards compatible stats can then be calculated from these. Since all the genes, mutated or not are from the same distribution, all foals will have the same distribution as their parents. Using three genes makes the stats have the exactly same distribution they are now (except for health, which will be slightly different). With more genes you would have to relax the min/max limits or have more average values. Example code:
createChild(otherParent){ EntityHorse child = new EntityHorse(); double[] p1 = this.getGenes(); double[] p2 = otherParent.getGenes(); double[] childGenes = double[9]; for (i=0; i<9; i++){ int mutation = this.rand.nextInt(9); if (mutation == 0) then childGenes[i] = this.rand.nextDouble(); else if (mutation < 5) then childGenes[i] = p1[i]; else childGenes[i] = p2[i]; } child.setHealth((maxHealth-minHealth)*(childGenes[0]+childGenes[1]+childGenes[2])/3.0+minHealth); //etc }This is the best of both/all worlds - a population won't change its stat distribution over time since the stats are calculated the same way as before, children of good horses won't likely be as good as their parents as the mutations drag the stats towards the average, but it's still possible to get an increase with a reasonable number of breedings! It works so well it's almost magical. I'll have to make a mod out of this if someone at Mojang won't implement this.
ilmango: I haven't actually shown any numbers yet, have I? So how can you tell how hard it would be to see speed gains? I can tell you that it depends heavily on the mutation chance, since a mutation replaces a part of the stat with a brand new one, which is the way to get an increase. With a 10% mutation chance you get very good horses with some hundreds of breedings, with a 1% chance it takes thousands. Some examples how long it would take to reach good average stats with 10% mutation per gene (without having information about the genes):
A perfect score is still unattainable. For the record, this picture
shows the same numbers for regular breeding.
P.S. Making breeding useless is a dumb way to encourage exploring.
I just realized why the current system is wrong and why the 3-gene solution is the only sensible way to combine the stats without skewing the distribution.
The stats are a sum of three uniform random variables (well, health only has two but there's no reason why it shouldn't also have three). They follow a uniform sum / Irwin-Hall distribution. With any kind of formula that combines the two parents' stats the result is not from the same distribution - it's from a sum of at least 6 random variables, which after scaling has a smaller variance (i.e. more average values). The current formula yields foals that have stats that are a sum of 9 random variables (2 parents and the third horse). This picture shows this effect:
The only way to get foals that have stats from the same distribution as their parents is to ensure the formula is a combination of only three uniform random variates. This means using only one parent value without adding random numbers (this doesn't have any randomness besides the choice of parent), making a totally new unrelated stat (foals are essentially wild horses), or choosing three from the original 6 of the random numbers the parents got plus possibly new unrelated random variables a.k.a. mutations (the 3-gene system).
There are a few ways to select the three but the suggested system (select each of the three randomly from either parent and in ~10% of cases use a new random number) is nice because the mutation rate can easily be changed. A 10% chance is nice in the sense that approximately one of the total 9 genes is expected to change.
ilmango: Could you please refrain from needlessly spamming the comments. The whole point of what is wrong with the formula is that breeding reduces variance, random parents or not.
Victor Baker: I know changing the system is necessary. The current system doesn't work even in principle because if you happen to lose high-stat horses you can't overcome your loss. The formula you mentioned won't work for reasons mentioned before. The system I mentioned is actually the exact opposite of a completely new system - it's essentially using the same formula for wild horses and bred horses. The only thing changed is that the values used to generate a horse are kept and inherited instead of discarded.
Jump strength isn't the same as jump height because gravity affects jump height. If you are an op, you can already get the exact stats with the entitydata command.
Victor Baker: I can't see any point in rounding the stats, the game can handle the numbers and for the player it's precise enough to keep track of the jump height. Anyway, calculating the stat values that correspond to a certain jump heights (simulating gravity) is much more work / code than the suggested breeding formula change. I just can't see any benefit to it. Even health isn't rounded internally.
ilmango: Horses can and will pass on their stats. Wild and bred horses aren't sampled with the same function but the results have matching mean and variance.
Here's how the stats are essentially generated (excluding scaling and offsetting):
U = random number from 0 to 1
Wildhorse = { speed = U + U + U, health = U + U, jump = U + U + U }My suggestion is to remember these U values:
Parent_A = { speed = U + U + U, health = U + U + U, jump = U + U + U } ^ | Child gets always one of these randomly. 10% chance to get new value. v Parent_B = { speed = U + U + U, health = U + U + U, jump = U + U + U } //added third U to health because why notI have tried your suggestion before and it won't work for reasons mentioned here, unless you give the uniform random part a multiplier so high it diminishes the parents almost completely. Here's how it would affect a random population: http://i.imgur.com/43Xn6v2.png (I believe the effect on the distribution of a random population is the only viable metric with which to measure how good the breeding is because the formula would have to explain how wild horses breed. Looking at what the player does is irrelevant because the player introduces all sorts of bias.)
P.S. Nice trick with the leaping potions.
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).
Victor Baker: 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.
jonathan2520: 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.
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).
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?
Victor Baker: 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.
Victor Baker: 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 jonathan2520 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.
Victor Baker: We can prove it in a similar manner than we can prove the current system doesn't preserve variance.
Here.
> 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:
You can't tell if a formula works if you haven't given a proper metric to evaluate one.
jonathan2520: 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?
Affects 1.8.2-pre5
Affects 1.8.2-pre5
Affects 1.8.2-pre6
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.)
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.
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.
RimaNari: 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.
jonathan2520: 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?
Affects 1.8.3.
Affects 15w47c
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:
Once you add about 24 tropical fish there, all animal spawning in the ocean around you stops.
@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 and generateRandomX is the infamous third horse.