Zitchas

Well, hopefully they get it worked out soon.

On our LAN server we used to be able to play with the server and all clients set to view distance of 20 and things worked quite nicely. Now the server and higher-end PC have had to drop that to 18, and older PCs  have to drop to 16 to get anything close to the same level of performance they had with 1.13. Disappointing.

There's nothing in the launcher log or in the regular game logs about a crash. The game log just ends.

Sure, I would be happy to. How do I attach a crash report? Or more specifically, where do I find the crash report in order to attach it?

This bug still exists in 1.12.2.

By the way, thank you for deciding to allow jack o lanterns to have stuff attached to them. I wish we could attach things to sea-lanterns and glowstone too, but having at least one block that emits light that can be used as a redstone supporting block is much appreciated. In the meantime, the sudden change from 1.11 to 1.12 has broken many of my redstone contraptions.

Confirmed also affects version 1.12.2

This bug just broke a bunch of redstone machines on my server. (I use jack o lanterns liberally in my redstone as a convenient way of keeping things lit - and a good way to keep track of which blocks shouldn't be broken.

Update: I still can't trigger that specific advancement on the server, but I can trigger it in singleplayer.

I just created a new world in sp, and with judicious use of creative mode reached the end, killed the dragon, and found a pair of cities. The advancement triggered immediately when I approached the door. (I don't think I'd actually entered, but was in the block adjacent to the entrance)

hmmm... Is there any particular point that it is suppose to trigger at? I'll go try a new starting a new world.

While I didn't explicitly mention it, and I probably should have, this occurred while playing on a server. The server itself is vanilla, freshly downloaded from the minecraft site. I'm running it locally on Java 1.8v131. The world itself, however, is one we've been working on for several years now. We did reset the end, however, back around the time the End Cities were introduced.

I was just about to start a major survival build using snow blocks as the white element (didn't want to use wool due to high exposure to the sky and quartz is far too rare), and I'm reluctant to start until there is some confirmation as to which direction this is going.

It makes sense that snow blocks should melt (ice blocks do, after all), but I'd much rather they didn't, since there are far to few non-flamable pure white blocks.

Thanks for the explanation. If I might make a suggestion, this bug report doesn't mention anywhere that it is invalid due to being used on modded minecraft servers. The text directing to the other bug report specifies "singleplayer AND does not involve pistons". My crash is on multiplayer and involves pistons, which suggest that it is this bug, not the other one.

Given that the server is directly under my control, I can confirm that it is using the jar file downloaded directly from Mojang, and has not been modified. But it is getting this bug with pistons.

My minecraft just crashed and directed me to this JIRA issue. I think this must be the first time I've had a crash direct me like this. I had an identical crash earlier, except that time it didn't give me an error message directing me to this JIRA isue.

Anyway, running a vanilla client connecting to a locally hosted vanilla server (both 1.10.1).

I'd like to note that this issue does not seem to be consistent. I've been building in an area away from my main base, and the game works just fine out there for hours on end. I come back to my main base to drop off mined material and pick up other stuff, then head back out. So I've been back to my main base 5 or 6 times in the past few hours, and I've only crashed twice. Both times it said it was due to a piston. While I have quite a few pistons around my base, only a single set activates in an automatic mechanism, and tracing the co-ordinates of the piston listed in the crash report goes to one of these pistons (used in a pumpkin auto-harvesting machine).

My minecraft just crashed and directed me to this JIRA issue. I think this must be the first time I've had a crash direct me like this. I had an identical crash earlier, except that time it didn't give me an error message directing me to this JIRA isue.

Anyway, running a vanilla client connecting to a locally hosted vanilla server (both 1.10.1).

I'd like to note that this issue does not seem to be consistent. I've been building in an area away from my main base, and the game works just fine out there for hours on end. I come back to my main base to drop off mined material and pick up other stuff, then head back out. So I've been back to my main base 5 or 6 times in the past few hours, and I've only crashed twice. Both times it said it was due to a piston. While I have quite a few pistons around my base, I have two that are part of a pumpkin timer. My suspicion is that it is when the pumpkin timer ticks over that the crash happens, as that is fairly random. All the other pistons aren't moving. Nope, not them. I checked the co-ordinates of the piston that gave the error, and it is instead one of the pistons in the pumpkin farm, which are powered by the pumpkin switch.

By the way, what does "Resolved - Invalid" mean?

Thanks for pointing that out. I searched, but didn't see it.

Just for the record, and anyone else getting this bug, it can be fixed by having whoever runs the server input the following command:

/gamerule disableElytraMovementCheck true

Running this on my own server solved the problem for me.

I almost never ran into this until 1.9.4, and I used spectator mode at high speeds a lot. But now I run into it a lot, particularly with Elytra.
(my own duplicate of this report: MC-102971, just for the record)

For those just coming across this bug due to its effects on Elytra, the following server command solves the problem for me:

/gamerule disableElytraMovementCheck true

Thank you Skylinerw for finding and pointing this out.

Possibly related: In the same multiplayer environment, when moving in spectator mode, if one starts moving too quickly it generates the same sort of thing: Assuming the forward movement key is held down, one zips along, then velocity keeps getting frequently - but irregularly - reset to 0, resulting in a very jerky movement pattern. This behavior usually occurs only when covering large enough distances to cause significant chunk loading. This is also accompanied by similar serving warnings along the lines of "WARN: player moved too quickly"

(I haven't made a bug report for this spectator behaviour because it may be related to this Elytra flight related issue)

Screenshot showing my map with all the green arrows on it. Note there are currently NO maps in item frames anywhere in this chunk. The map should be showing just the white arrow, no green ones.

The bug is still present in 1.9.2. I have a map that I put in two different item frames simultaneously, then I rearranged my base and took them both down. Now I still have both the green arrows on the map, despite it not being mounted anywhere.

Running 1.9.2 vanilla

note: I am running 1.9.2 vanilla, so the bug is present there.

LIke Gianna, I notice a lot of different threads, many of which match my bug more closely than this one, but they all redirect here.

Anyway, I have a map which I put on the wall in an item frame. Then I took it off the wall, and it still shows the green arrow marking where it is on the wall. I did this with two different locations on the same map, and the green arrows for both are still there.

If this is a technical support issue, does that mean that there is, in fact, a way for Realms servers to adjust the idle time-out? I would also like to have a somewhat longer time-out. Say, 15mins, or there abouts?

Also affects 1.8.4, 1.8.5, and 1.8.6.