Talk:Java Edition 19w38a

About the new "Predicates" within 19w38a
Should we create a new page for Predicate? As predicates are now a stand alone thing that can be used in datapacks, it should like loot tables and functions get its own page. Now it's included in the page about loot tables where the section "conditions" describes this.

I suggest a page Predicates and copy/move over the section from Conditions, then add the new functionality. Also state the structure within the datapack namely: datapacks//data//predicates/ --User-8962067 (talk) 19:10, 18 September 2019 (UTC)


 * Agreed. FVbico (talk) 19:22, 18 September 2019 (UTC)


 *  Nixinova  T  C  19:37, 18 September 2019 (UTC)


 * also – Sealbudsman talk | contribs 01:06, 20 September 2019 (UTC)

Kill without arguments defaults to @s "change"
This was already the default behavior last I checked. Or did they remove it for a major version or two then add it back? Can't say I ever thought to test it in 1.13 or 1.14.

–Preceding unsigned comment was added by 70.67.123.123 (talk) at 19:27, 18 September 2019 (UTC). Please sign your posts with
 * They changed this behaviour in 1.13; I have been finding it annoying how just "/kill" doesn't work so this is a welcome change.  Nixinova</b> </b> T</b> </b> C</b> </b> 19:31, 18 September 2019 (UTC)

Graphical changes "Block outlines appear darker"
This isn't really a feature/change, as they are messing around with the graphics/render engine. I suggest not including these as a change, however we might be able to include these 'changes' under "Render Engine updated".

Like other notable facts, such as items appearing lighter in dark environments, these are likely to be bugs, or unintended changes, rather than feature changes.

--_&#95;AgentM_&#95; (talk) 14:11, 20 September 2019 (UTC)


 * The wiki will often list bugs/bugfixes like this as feature changes as they are typically significant enough to be counted as a change, and not always clear if it's actually a bug or not. Whether we should avoid documenting bugs like this is a discussion for another place like the Community Portal. -PancakeIdentity (talk) 20:10, 20 September 2019 (UTC)

Failed version
I added a sentence to the end of the opening summary about this being a failed version. It had a catastrophic bug (breaking blocks crashes the game) and so was replaced by 38b later the same day. Should we be clearly marking all of the "don't play this version" versions? Currently you have to discover it by reading the next snapshot's bugfix list. And if we do what are the requirements? For example 19w41a destroys paintings (causes them to fall off the wall a few seconds after world load, then they despawn after the normal 5 minute countdown). Is that serious enough to mark as a version to avoid? Also half of 1.8's snapshots (4 months worth of releases) were all corrupt (created entities with bad data that according to Mojang couldn't be fixed without just erasing the whole world and starting a new one). You wouldn't find that out by just reading next week's snapshot notes. You'd have to read 1 certain snapshot to see mention of it. –Preceding unsigned comment was added by 70.67.123.123 (talk) at 20:51, 16 October 2019 (UTC). Please sign your posts with
 * The point of a snapshot is to test features. They're not meant to be 100% stable.  Nixinova</b> </b> T</b> </b> C</b> </b> 21:24, 16 October 2019 (UTC)
 * Ok fair enough. It needs to render the version unplayable before we comment on it. In that case this block breaking one and that old alpha version where leaf decay crashed the game are the only ones I can think of off the top of my head. 70.67.123.123 22:27, 24 October 2019 (UTC)