User talk:Anomie x

Checking the code for exp drop amounts
Hi, I noticed you said, about the experience dropped by smelting wet sponge, "From code, it's 0.15". I was wondering, would you be able to help me double-check some experience numbers directly?

I was curious how much exp drops with an Elder Guardian, so I did some in-game testing on blazes and normal guardians, to first calibrate my method. Assuming the experience-leveling graph on this page was correct, then I was getting about 7.5 exp per blaze, and about 8.5 exp per guardian. I was counting the levels I gained (and fractions thereof) for every 25 of each mob I killed, and got those numbers. But the graph there says 10 exp.

Either I'm doing something wrong (sample size?), or the wiki is bad, so I was wondering if you would be inclined to check blazes, guardians and elder guardians directly, and any others you might be inclined to do. Thanks!

– Sealbudsman (Aaron) T, C, b 17:27, 10 September 2014 (UTC)
 * @Sealbudsman: As far as mobs go Wither is 50, Blaze is 10, Silverfish is 3, Ghast is 5, Guardian is 10 (Elder or not has no effect). Slime is 'Size' + 1, and Magma Cube inherits that too. Zombies are 5 but babies are apparently 12 (5 * 2.5 rounded down), and Zombie Pigmen inherit that too. Other hostile mobs are 5 by default. Jockey chickens give 10, Squid give 1-3, and other animals give 1-3 by default. Mobs (except for animals and Squid) also get a bonus 1-3 for each piece of equipment they have that isn't a guaranteed drop. I don't see any changes here from 1.7.10 for non-new mobs, BTW.
 * For smelting, none of the 1.7 items have changed so you can look here and get the number from the end of each line to check them. The new meats give 0.35, cracking stone brick gives 0.1, and drying sponges gives 0.15 as already stated.
 * If you want me to track down more numbers, let me know. Anomie x (talk) 21:20, 10 September 2014 (UTC)
 * Also, BTW, it looks like breeding is 1-7, not 1-4. Anomie x (talk) 21:36, 10 September 2014 (UTC)


 * Thanks! So the Endermite is 5 and not 3? Does the chicken jockey give 10 when you kill the chicken, or the zombie, or is it just 5 for each mob (in which case it's 5 for the baby rather than 12)?  Does the spider jockey drop anything different than 5 for each mob?  Does the 1-3 bonus extend to the Jockeys?  Much obliged. – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 21:38, 10 September 2014 (UTC)
 * ... No, Endermite is 3, Silverfish is 5. I got confused reading the obfuscated code since they use the same sound files. Sorry about that. Chicken jockey gives 10 for the chicken and 12 for the baby. Spider jockey is 5 for the spider and 5 for the skeleton, it's just like separate mobs. Same for the equipment bonus. Anomie x (talk) 00:35, 11 September 2014 (UTC)

Checking the code for Block States for Fire, Flowing Water/Lava and Source Water/Lava
Hi again, Anomie,

I've been going through the Block states page, filling in what blocks I could by using F3 mode in a Debug world -- but you can't hover over fire or liquids to get those block states. I was wondering if it was within your capability to look in the code, and find those block states and their ranges of values that way? Thanks in advance,

– Sealbudsman (Aaron) T, C, b 18:35, 24 September 2014 (UTC)
 * Added one for Fire. Flowing water/lava is correct, and still water/lava is the same as flowing. Anomie x (talk) 22:17, 24 September 2014 (UTC)
 * Thanks! – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 22:22, 24 September 2014 (UTC)

Hello again,

I wonder if you would be able to identify whether block 36 – that people call 'Piston Extension' – has a minecraft:name or any named block states? In the debug world it seems there are 12 blank spaces where Piston Extension should be, so it led me to wonder.

Thanks again for looking into all this stuff!

– Sealbudsman (Aaron) T, C, b 17:45, 29 September 2014 (UTC)


 * It does have a name, "minecraft:piston_extension". --KnightMiner  (t 18:00, 29 September 2014 (UTC)


 * I see. It must have 12 distinct states? – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 18:05, 29 September 2014 (UTC)


 * Likely, although I though it was mostly block entity. It does need to store the block it becomes and a time delay I know. --KnightMiner  (t 18:08, 29 September 2014 (UTC)


 * Yeah, a lot of these things, like heads or banners, have hodge-podges of states, damage values and block entity data that describe them. I'm sure there are block entity things going on, but that's outside the scope of what I'm asking for now – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 18:13, 29 September 2014 (UTC)
 * As far as block states, it has "facing" and "type" like piston_head (no "short" though). The block entity stores "blockId", "blockData", "facing", "progress", and "extending". Anomie x (talk) 22:25, 29 September 2014 (UTC)

Villager behavior
Seems like you've been looking at their code, so I figure you might be able to clarify this. If a villager is willing to breed because they have enough food in their inventory, what happens after they mate? Are they willing to breed again immediately, is there a time delay, or do they actually consume the food they're holding? -- Orthotopetalk 19:15, 2 October 2014 (UTC)
 * The food is consumed at the time the "willing" flag gets set; there's a method on the Villager class that checks the "willing" flag, optionally consuming food if "willing" is clear and the villager has food. There's no check there that implements any delay. Similarly, there's no check in the trading function that implements any sort of delay for becoming willing that way.
 * The only thing that calls this method, and the only thing that clears the "willing" flag, is the AI routine for villager breeding. For clearing "willing", it only happens with a successful breeding which (as with other mobs) sets the "age" of each parent to 6000.
 * As for the check that calls the check-willing method, it looks something like this:
 * Villager's age == 0?
 * Random number 0–499 is 0?
 * Is the villager is inside a village?
 * Does the village allow breeding right now? In other words, is the village's "noBreedTicks" timer not active and is the village not yet at its population cap?
 * Is the villager willing? This is the method call that might eat food.
 * Is there another villager nearby?
 * Is that villager's age == 0?
 * Is that villager willing? This might cause that villager to eat food.
 * If you're wanting to dig into the code yourself, in 1.8 Villager is class 'agp', the "willing" flag is 'bs' in that class, the method that checks "willing" and potentially consumes food is 'boolean n(boolean)' in that class, and the AI routine is class 'zj'. Anomie x (talk) 20:56, 2 October 2014 (UTC)

Checking the code
I wonder if you use a publicly available deobfuscated version of the code or something, or whether you have something you've done yourself. I feel like I bug you a lot for things, and I hate to bother you! I do have a few more questions about block states, and I would be interested in seeing how you are doing what you are doing, if I could. – Sealbudsman (Aaron) T, C, b 20:26, 6 October 2014 (UTC)
 * I wish I knew of some publicly-available deobfuscated 1.8! I use https://github.com/Bukkit/mc-dev for looking at things in 1.7.10. As for 1.8, I just ran it through jad and read the decompiled-but-still-obfuscated source. Blocks and items are easy enough to find by searching for their names to find the equivalent of Blocks.java or Items.java, and entities can be found by searching for their sound files (e.g. "mob.zombie.hurt"). Once you have the item/block mappings you can find some other stuff, like searching for "amk.i" (diamonds as an item) can find you the chests that have a chance of diamonds, the code for beacon sacrifice items, the crafting recipes that include diamonds, and so on. And then cross-referencing with 1.7.10 can help to find related code.
 * As for block states, class "atr" is the Block class, and you can find the specific subclass for any block by looking at the list of calls in method R (which is equivalent to method Block.p from 1.7.0). In 1.8 Block has "protected bed e" that has something to do with the block states; I'm not sure what exactly class "bed" is (it seems to have something to do with producing a list of all possible blockstates for the block), but it takes an array of "bex" which is apparently something like "IBlockProperty". The implementations of that e method are generally just "return new bed(this, new bex[] { ... })" where the "..." is a list of static fields defined in the same class. The initializations of those static fields will give you the block property names, and the specific subclass used for each tells you the types: "bet" is a boolean, "bew" is an integer range, "beu" is up/down/north/south/east/west, and "bev" is some other enum (the identity of which is included in the initializer). Anomie x (talk) 01:46, 7 October 2014 (UTC)

Attack damage
Some user recently messed with the skeleton attack damage, and I noticed nether the change of that user or the original is accurate. Can you check the code to find their attack damage range?

Also, what are the affects of regional difficulty on attack damage, if any?

–KnightMiner  (t 18:12, 8 November 2014 (UTC)
 * Arrow damage is somewhat complicated, and I hope I'm reading the code right here. Experimental trials to check this would be a good idea.
 * The amount passed to the "damage entity" method is D = ceil( sqrt( motX*motX + motY*motY + motZ*motZ ) * damage ). Plus randomInt(0 to floor(D / 2 + 1) inclusive) on a critical hit, except I don't see any indication that a skeleton archer can do criticals. (This applies to arrows from any source.)
 * For that sqrt( motX*motX + motY*motY + motZ*motZ ) factor, it looks like skeletons always shoot with an initial force of 1.6, compared to a fully-charged player bowshot of 3.0 and a Dispenser shot of 1.1. (The initial force comes from the Skeleton code itself.) But of course that changes over the flight of the arrow: it looks like for each tick it decreases by 1% in air (40% in water) and gets motY -= 0.05 to simulate gravity. That 40% was only 20% in 1.7, BTW.
 * As for the damage multiplier, it looks like it actually depends on distance as well as difficulty: minmax(distance / maxrange, 0.1, 1.0) * 2 + randomGaussian * 0.25 + difficulty * 0.11. They hurt you less at point-blank range (but they shoot faster: for skeletons it's 24 ticks between shots versus 60 at the max range of 15 meters). So a skeleton with a basic bow should have a damage multiplier of 0.31–2.36 on easy, 0.42–2.47 on normal, and 0.53–2.58 on hard. This compares with a player (and a dispenser) having a constant damage multiplier of 2.0. For both players and skeletons, Power adds 0.5 + 0.5 * PowerLevel. (The distance-based 0.1–1.0 factor comes from the "ArrowAttackGoal" AI routine, while the rest is in the Skeleton code itself. Power is calculated separately in Player and Skeleton using the same formula in both places.)
 * Regional difficulty has no effect, it only considers the set difficulty.
 * So a fully-charged player shot with a normal bow, assuming the initial 3.0 force is approximately unchanged, would theoretically do 6–10 damage. Making the same force assumption for a skeleton, we'd get 1–4 on easy and normal and 1–5 on hard, mostly based on distance. A skeleton shooting almost straight down might pick up an extra point due to gravity speeding up the arrow. On flat ground, some quick simulations point to a max of 4 on all difficulty levels for skeletons.
 * Difficulty also decreases the error in skeleton's aiming. A player has an "error" of 1, a dispenser has 6, and a skeleton has 10 on easy, 6 on normal, and 2 on hard. To account for gravity, it looks like skeletons aim 0.2 meters above the target for every meter distant horizontally (and aim for 1/3 of the way up the body).
 * HTH. Anomie x (talk) 23:50, 8 November 2014 (UTC)


 * Nice work. I saw that arrow damage depends on velocity, but never got around to calculating what the exact damage caused would be. -- Orthotopetalk 00:51, 9 November 2014 (UTC)


 * Thanks for the information, it was really helpful as the most my findings found was the minimum attack damage. I will have to work on incorporating the information on accuracy into the article while rewriting it later.
 * By the way, does regional difficulty affect the attack damage of any mob? I know it affects the rate zombies have weapons, but I'd assume there would be no other affect to damage. –KnightMiner  (t 01:30, 9 November 2014 (UTC)
 * Besides the stuff already listed at Difficulty, I see:
 * Regional difficulty increases the chance of larger slimes (up to 50% chance of upgrading the size if it's not already largest).
 * Zombies are more likely to be able to break doors (up to 10% chance directly, and there's also up to 5% for being a leader zombie, for a total of up to 14.5% chance).
 * Zombies are more likely to have the "Random zombie-spawn bonus" multiplier to their generic.followRange stat, and to have larger values (a random float between 0 and up to 1.5 is chosen, and if F > 1.0 then F is the bonus).
 * Zombies are more likely to be a "leader zombie" (up to 5% chance), which includes being able to break doors, getting the "Leader zombie bonus" multiplier to their generic.maxHealth stat, and getting the "Leader zombie bonus" addition to zombie.spawnReinforcements (this last is already noted on Difficulty).
 * So nothing directly affecting attack damage that I see. I also don't see anything besides slime spawning depending on moon phase without regional difficulty, or any use of regional difficulty that doesn't also involve moon phase.
 * Every use of regional difficulty follows the formula I described at to determine a multiplier between 0.0 and 1.0. In most cases the multiplier is used to scale a percentage chance from 0 to a max; random zombie-spawn bonus to generic.followRange and the equipment enchantment levels are the exceptions. This also means that anything affected by regional difficulty is going to be 0% chance in easy in 1.8. Anomie x (talk) 06:50, 9 November 2014 (UTC)
 * BTW, the chances of the things already listed on Difficulty are up to 55% for CanPickUpLoot, up to 10% for spider effects, up to 15% chance of having armor (but how full of a set and what material aren't affected by regional difficulty), up to 25% chance of having an enchanted weapon, up to 50% chance of having enchanted armor, enchantment-table level for both weapon and armor enchantment ranges from 5 up to 22. Anomie x (talk) 06:50, 9 November 2014 (UTC)

An award for you

 * Thanks! Anomie x (talk) 00:09, 21 January 2015 (UTC)

Spawning behavior of 1.8 mobs
Talk:Spawn. We need actual spawning behavior of new mobs added in 1.8. I’m Nick the Red37, f.k.a. Naista2002  19:14, 31 January 2015 (UTC)

Projectile motion in snapshots
Since you've been digging through the snapshot code already, can you look into the claims related to this edit and see if Entity needs to be updated? I'm a bit skeptical of the post on reddit, which claims snowballs had no drag factor is 1.8, since I'm fairly certain they did when I was analyzing this based on the 1.2.5 code. -- Orthotopetalk 05:57, 1 August 2015 (UTC)
 * I already saw that they changed the code for firing projectiles, probably fixing the situation where they hand five different incompatible ways to shoot something. Whether that actually changed anything or is just different code with the same result I don't know.
 * As far as motion for what MCP 9.10 calls EntityThrowable, I don't see any relevant-looking changes to the motion function. The projectile gets an initial motion-vector when launched, then each tick (absent collisions) it adds the motion-vector to the current position, then multiplies each component of the motion-vector by drag (d=0.99 in air, d=0.8 in water) and subtracts a gravity acceleration (default is g=0.03 but can be overridden) from the Y component. The result doesn't match either of the equations on that imgur. Assuming I did the calculations correctly, the equations for the motion-vector work out to  and , which gives distance equations of   and.
 * For arrows it's basically duplicate code, except gravity is g=0.05 and drag in water is d=0.6. Again, I don't see any relevant-looking changes to the motion function for free flight.
 * So the actual flight mechanics seem to be the same in 1.8.8 and 15w31c. The "initial motion vector" might have changed, but I've already spent too much time on this for now. If you want to look into it more, classes in 1.8.8 are wq for arrows and wy for 'throwables', corresponding to xd and xp in 15w31c. HTH. Anomie x (talk) 14:45, 1 August 2015 (UTC)