Talk:Java Edition 15w34c

Lead
, consistency has no value or meaning at all if it's inaccurate. It's the reason you don't put "released mainly to fix some bugs and crashes" at the top of the Horse page. Accuracy trumps consistency. A person visiting this page isn't going to be well-served by deliberately-placed false information. I'm surprised to find you getting into an edit war (you're on your 2nd revert of 3?), defending inaccurate information; I thought you to be meticulous about this kind of thing.

There were no crashes fixed, and as far as I can tell, only one bug fixed (as of this writing): the time-command one. The other one wasn't fixed in this snapshot. It's inaccurate and misleading to leave that bug on this page, but that's a different discussion. The blog reads: "even more changes to the melee combat mechanics, and some further (experimental) optimisations", so even though this is a 'c' snapshot, it's not a typical 'c' snapshot: it's inaccurate to say "released mainly to fix some bugs and crashes". – Sealbudsman talk/contr 15:34, 21 August 2015 (UTC)
 * I second that. At least 3 people have changed this obviously false statement. This week, Mojang have used the b and c snapshots to add features and rebalance rather than bug fix. I think "15w34c was released mainly to balance/extended changes introduced in 15w34a/b" Is a better opening paragraph, though. Any thoughts? FM22 (talk) 16:48, 21 August 2015 (UTC)
 * I went ahead and changed it. which is better? FM22 (talk) 16:54, 21 August 2015 (UTC)
 * This has been the case for a lot of b and c snapshots recently. A lot of snapshot pages have only a few bugs fixed, and a lot of major additions/changes. While in the past, b and c have been big fix releases, this is no longer the case. PancakeMan77 (talk) 19:03, 21 August 2015 (UTC)

DPS
Perhaps it would be a good idea to put the weapons' DPS values into the table, to see how they really compare with each other? I was debating doing that with the last update, where the Axe's DPS dropped below the Pickaxe's, but I haven't had time. It's still a good idea, but I'm still rather busy. Firebastard (talk) 00:56, 22 August 2015 (UTC)
 * The calculation is basicly  so using the current values we get a DPS table like this. Oozebull (talk) 01:32, 22 August 2015 (UTC)
 * {| class="wikitable" style="text-align:center"

! Item ! colspan="4" | Damage/Second (DPS)
 * Swords
 * 5.8
 * 7.25
 * 8.7
 * 10.15
 * Axes
 * 6.8
 * 7.65
 * 8.5
 * 9.35
 * Pickaxes
 * 3
 * 4.5
 * 6
 * 7.5
 * Shovels
 * 4.5
 * 5.5
 * 6.5
 * 7.5
 * Hoes
 * 4
 * 5,32
 * 6,68
 * 8
 * }
 * Right. I was just saying that should be a part of the article. Firebastard (talk) 04:04, 22 August 2015 (UTC)
 * 5,32
 * 6,68
 * 8
 * }
 * Right. I was just saying that should be a part of the article. Firebastard (talk) 04:04, 22 August 2015 (UTC)


 * Added the DPS info to the article. –Goandgoo ᐸ Talk Contribs 04:49, 22 August 2015 (UTC)
 * Does that take into account damage immunity? Anomie x (talk) 10:59, 22 August 2015 (UTC)


 * I don't think so. PancakeMan77 (talk) 15:08, 24 August 2015 (UTC)


 * As far as I can tell, it shouldn't make a difference except for hoes, since all the other tools have an attack speed slower than 0.5 seconds. For hoes, DPS would be cut in half if you're attacking a single mob, but not if you're alternating attacks between several mobs. -- Orthotopetalk 15:40, 24 August 2015 (UTC)

So why do we need a chart about killing a silverfish with different weapons here?
That seems to me like it would be more applicable to a tutorial page. Anomie x (talk) 11:55, 24 August 2015 (UTC)
 * Yeah in hindsight it was a bad idea; I made a thing for working out if the sword or axe was better for killing different enemies at different tiers. I will make a new page and add my tables to it. There are 3 by the way, I forgot to add the others. FM22 (talk) 13:36, 24 August 2015 (UTC)

Major World Save Change in this Snapshot!
There is a major change that occurred in this snapshot that I haven't found documented anywhere. Previously Unused data values of blocks were preserved in the World save. From an in-game perspective these unused data values of blocks would appear as air, but if not over-writen by placing a block in the location of an unused block data value the save file would preserve the block.

One of my projects relies on this "feature", and after returning to work on the project in 15w42a I found that my world longer contained any of these blocks. Well I tracked the change down to this snapshot. 15w34b still has the "feature" in it.

Firstly let me explain the "feature" better and how I have observed it change over Minecraft versions. This feature of the Save file preserving the unused data values of blocks (I believe) came into existence with the Anvil Save Format. What was it purpose and benefit? Well if a person loaded a world into an older version of Minecraft the blocks would disappear for the fact they were not in the older version of Minecraft. However blocks would be persevered in the save file so that if they returned to playing the world save in the newer version the blocks would once again be in the world so long as they weren't over written. Ideally this would somewhat keep the world safe though we know changing versions of a world has it's complications.

Back in 1.7.10 and before blocks unused data values would appear the same as data value 0 of the block in-game. For example stone with a data value of 15 would appear to look the same as normal stone with data value of 0. So these unused data values could be observed in-game but texture wise were indistinguishable from the primary data value 0. Blocks that were not yet added to the game of course appeared as air. This change with the addition of Block States. In 1.8 all the unused data values from then on all appeared as air, yet preserved.

In the snapshot 15w34c this "feature" has been scrapped. I'm a bit sadden over this as in my opinion it was a very useful "feature". Worlds loaded in 15w34c will drops all unused data values of blocks when the world saves.

When loading my world; chunks with unused data value blocks in them appeared as "world holes". Exiting out of the world (which triggers a save) and re-entering the world everything appeared as normal again (since unused data values appears as air anyways). Loading up the world in MCEdit showed that all the unused values were no longer present but actual air blocks.

Block States are meant to replace Meta Data (data values) and it seems this is likely one of the steps toward that end. Block States however does not have a similar "feature" to replace this one. Which is why I'm sad to see it go. I tried my best to write this in an easy to understand way. I consider this a major change. Worth no less then at least being documented on the TALK page.

Laige 22:38, 18 October 2015 (UTC)


 * That seems a big deal enough to mention, yeah. Probably on at least one other page besides this one -- something to do with world save or data values, though I'm not familiar enough to say where. Another note, have you checked the bug tracker for any sign of this change? – Sealbudsman talk/contr 01:43, 19 October 2015 (UTC)