ShelLuser

This issue also seems to be resolved. Right now I can issue:

/advancement grant @p everything
/recipe give @p *

After which I run '/data get entity @p' and I don't crash anymore.

This problem has been resolved as far as I can tell.

If you place a spawner then it will default to spawning pigs. If you then set SpawnData as per example from the op:

/data merge block x y z {SpawnData:{id:"minecraft:zombie"}}

then it will change into a zombie spawner, spawn one (or more) zombies and then reset back to pigs. This is intended behavior because SpawnPotentials:[] (which hasn't changed) gets copied onto SpawnData. And 'potentials' was still set to pigs.

But if we use this command instead then the results will heavily change:

/data merge block x y z {SpawnPotentials:[{Entity:{id:"minecraft:zombie"},Weight:1}]}

First several pigs will spawn (which is intended because they were still specified in SpawnData) but after that the spawner will change into a zombie spawner and it will remain spawning zombies.

The same thing applies if you give yourself a spawner and only set SpawnPotentials: first it will spawn pigs, but then it will start spawning whatever entity you defined. This is fully as intended because SpawnData was never set (and thus is set to default).

Which makes me convinced that this bug has been resolved. I've never been able to use customized mob spawners in 1.12.2 but I can in 1.13.1

This issue appears to have been somewhat fixed in the latest version (1.13-pre2 at the time of writing) because now these do show up in item frames (see attachment).

However I have discovered a new issue: although player markers are shown in "framed maps" they don't show any color attributes which are shown when a map is being held:

What I did here: I like to maintain a "teleport wall" with interesting places. Here I've copied the map ("pick click") I placed a named & colored banner and marked it on the map. As a result the banner shows on both maps, but as you can see the "framed map" doesn't show the cyan text nor does the banner appear in the fully right color.

Hope this can help!

This also happens to me quite frequently, even with the current 1.13-pre1, but only on multiplayer, not in a singleplayer world.

Also noteworthy: it only happens when I try to get the full list ("/data entity get @p" for example). Whenever I try to access a small part of the stats then it works as normal. So: /data entity get @p Inventory or Inventory[0] poses no problems.

And something I just discovered, I can resolve this issue by using the following commands:

• /clear @p

• /advancements revoke @p everything

• /recipe take @p *

I can also rule out upgrade problems because the world we play in was created using 1.13pre1.

(edit)

I noticed that a good way to reproduce this problem is by giving myself all available recipes (/recipe give @p *), and then trying the "/data get entity @p" command again. Note: I'm using a 32bit client while connected to a 64bit server.

First: sorry for the duplicate, I actually searched but there were so many "crash reports" that I overlooked this one. But I also failed to search for the keyword "datafixer".

I'd like to add that this also happens on 32bit environments and that I've ruled out a few options:

• I moved .minecraft out of the way to start fully fresh (no texturepacks for example) and that made no difference.

• I also tried skipping the shipped Java runtime but instead use a more recent version (1.8_161) and that also made no difference (still going to try SE9).

• And finally I changed some parameters to assign more and less memory, that too made no difference.

Hope this can help shed some light on this.

Just want to chime in that this report is still relevant today. 18w15a also has this problem.

But another reason for my comment: this seems to be a re-occurring bug because MC-46470 involved the same symptom (yet that one got resolved).

Late reaction (I don't frequent the bug tracker); the problem still exists in the current snapshot of 18w14b but it's definitely improved. Instead of setting up a weird sized box the system now sets up a correct box where size is concerned but does so at the edge of the structure box limit. So it doesn't encompass the actual structure.

I've attached a file showcasing this new behavior:

So although it's still somewhat wrong (I'd expect an error or something) it does make a lot more sense than the previous behavior.

Unfortunately yes, here is a screenshot when I tried this out with another player on 1.12.2. They killed themselves in a lava pool behind me, respawned and this is the result. It's hard to spot but you can even see some blue particles retain, those are a left over from me giving the player the night vision effect. As mentioned in the original description: on my console the player looks absolutely normal.

I can't test this on 18w07c because for some reason my client crashes the very moment I try to log on to the server, and I haven't had time to look further into that.

I can't reproduce this problem, but I wonder if there isn't a different cause:

Today I also started experimenting with functions (1.12-Pre7) and no matter what I did the function files I had made couldn't be found, even though they were there. I made: godgear\give.mcfunction (in the functions directory), yet it wouldn't get recognized at all.

I discovered the cause of the problem though: don't treat function files as real functions. So, at first I made this small snippet:

give @p diamond_sword 1 0 {
display: {
Name: "Cool sword!"
}
}

If you copy/paste that into a command block it'll work, if you do the same in a function file then no go. So then I removed all the cr/lf and put everything on 1 single line (as if you'd use a command block) and my problems were gone. It didn't even matter if I used a resource pack or not (I only use Lithos:Core).

Using comments and such makes no difference, but if you spread a function across multiple lines then Minecraft won't recognize it.

Could that be related to your issues?

I've been messing with the latest snapshot (time of writing, so 17w17b) and noticed that this is still a problem. Was about to report when I found this issue. It's especially annoying for servers because using spawners is a lot less taxing than having to mess around with command blocks. Even better: spawners help to keep the game feel more natural.

Confirmed.

One critical note though... If I had known this up front I wouldn't have wasted my time over it. Don't get me wrong: I appreciate Minecraft and what it provides, but it would help to mention these things in the official release notes instead of cryptic stuff.

Are you trying this on servers? I've had issues with this too, but that was usually lag related. I can't reproduce any issues with double click being to slow other than a lagging server or connection.

Just noticed this with the latest snapshot, searched, came across this. Can't help mention that I think it's a bit easy to claim "works as intended". Isn't the intention of the /kill command to actually kill entities in the first place?

I know I'm stating the obvious but.... FreeBSD 10.3 using OpenJDK 8.121.13 gives the exact same results. Seems like a common Java logger related bug of some sort.

I have the same problem on a 32bit Windows 7 environment, this is the crashlog which I'm getting:

https://pastebin.com/Dhv9Qucp

At first thought I can't help wonder if this might be caused by 32bit vs. 64bit. Also because of the header of that stacktrace:

java.lang.UnsatisfiedLinkError: Unable to load library 'SAPIWrapper_x64': Native library (win32-x86/SAPIWrapper_x64.dll) not found in resource path

(edited to add pastebin link, seems better readable to me)

Meh, this turns out to be a duplicate of MC-109831.

I was searching for 'skulls' not heads.

Yeah, apologies for possibly creating some confusing. I didn't even fully realize that it was edited and at first considered it to be my mistake. I'll be more careful next time. Thanks for the heads up Dylan.

Because my bug report (MC108785) duplicated this one I'd like to mention how I reproduced this on the latest snapshot (16w43a) because my method differs from the OP. Hope this helps and isn't inappropriate.

Basically this happens all the time on my server (16w43a) but only when another account logs on as well. As long as I'm alone I can switch from Creative to Spectator and back endlessly and nothing happens (I remain visible). But the very moment I'm joined by another player then my arm (and preview area) becomes invisible as soon as I switch back from Spectator to Creative.

Hope this can help.

@Orell If we follow your reasoning then shouldn't the observer keep responding as long as you place redstone dust in a single connected line? Thing is: it doesn't, if you place the 3rd dust it'll respond (this triggers the "lower" or middle dust in the OP's picture) but if you then place a fourth then nothing happens anymore.

@G4me: there's a little more to that story: if you place redstone dust in front of the observer then it triggers due to the block update. If you then place another redstone dust in front it triggers again. Expected behavior because the initial redstone dust updated (changed from a round to a line). But if you then place a third redstone dust in front the observer triggers yet again. That shouldn't be happening because the block directly in front didn't update. However, the 2nd block did. So there's more to this than merely updating the block directly in front.