mojira.dev

Orthotope

Assigned

No issues.

Reported

No issues.

Comments

This sounds more like a feature request than a bug to me. Beacons require an unobstructed view of the sky to function; this ticket seems to be asking for that to be changed to allow them to function anywhere in the Nether. The only bug I see is that they ever worked in the Nether at all.

Still in 1.8; looking at the code, it seems to be a simple oversight. Previously, the thickness of snow was stored in its data value, using the range 0-7, so the number of snowballs dropped was (thickness + 1). With the transition to block states, the thickness is now internally represented as 1-8, but the formula for snowballs dropped wasn't changed, so it gives one extra.

Added another screenshot with a 1.8 crystal on the left, summoned in the one on the right to show 1.7 and earlier behavior. Looks like there's an off-by-one error setting the crystal too low. The code to create the bedrock is still there, but suffers from the same off-by-one error, so it doesn't function because it will only replace air, not obsidian.

Speaking as a longtime contributor to the wiki, it primarily documents observed behavior of the game. On the rare occasion that we do document intended behavior, there will always be a link to a statement by a Mojang employee confirming it. In the absence of any such statement, do not make assumptions about what is or is not intended.

Speaking as a programmer, Markku's code analysis looks solid to me. This appears to be a simple case of a missing 'else' clause, which definitely qualifies it as a bug.

Looking at the code, the problem here is the use of the java.util.Properties.load(InputStream) and Properties.store(OutputStream, String) methods. Both of these assume the use of ISO 8859-1 encoding, and this cannot be changed. The solution is to use the Properties.load(Reader) and Properties.store(Writer, String) methods instead; InputStreamReader and OutputStreamWriter can be used to wrap the FileInputStream and FileOutputStream respectively and specify the UTF-8 charset.

As for the current behavior, non-ascii characters are encoded as (slightly modified) UTF-8, then written to file as escaped Unicode characters; when read, the escape sequences are handled properly, but it is not converted back into UTF-8. The section sign (§, \u00a7) happens to be encoded as \u00c2\u007a (§), so formatting codes work, aside from adding an extra character. Many other characters do not contain themselves when encoded (such as ÷ (\u00f7), encoded as \u00c3\u00b7 (÷)).