I can confirm this issue. I can replicate it in a vanilla world. Place a campfire, grab a raw food. Set DoLimitedCrafting to true, and run the command to clear all known recipes. You can still cook the item.
This same issue applies to the Stonecutter, and other similar workstations. (aside from the crafting table)
I opened a map with this issue in pre-3 and it resolved. I followed the instructions above after (Singleplayer: Select world → Edit world → Optimize world → check "erase cache data" → Backup and load) and few around in creative with no issues. I then played for half an hour with no lighting issues. Pre-4 is out now, I will post a follow-up if I see the issue return.
I had this issue with a map I created. I replaced the region data from a previous backup that wasn't loaded in 1.14-pre1 or 19w14b. I now see no lighting issues.
I tried the same files from my map (that are now working in single player) in a pre-2 server and there are still lighting glitches there.
[media]I discovered the cause of my issue. Happy that my map was loading without lighting issues I ran it through the "Optimize world" option with "Erase cached data" checked. This re-added the lighting issues into the map. Reverting back to my fixed version and running that with the server resulted in no known lighting glitches.
This is not resolved. Today (4/16) while playing the single player world that I thought was fixed, lighting glitches appeared after visiting a previous area that had none.
[media]I can confirm this issue on my map I've created. (If you need it: https://www.dropbox.com/s/m9gv3jsf8r55r89/Xiphias%201.14pr1-19.04.11.zip?dl=0)
I cleared the chunk cache and then flew around some areas to make sure they were all loading correctly. Just flying around in one area on a second pass lighting glitches appeared where they weren't before. Quitting and relaunching a server with the map caused the generation of light glitches - and sometimes where the issues were changed.
Confirmed in 19w14a
I think I understand what is happening after thinking about it. I'm assuming placing 2 chest the game is generating the loot rather than the player, so no luck is applied. I can confirm this by placing a single and double chest tied to a loot table and then try to look inside each in spectator mode. On the single, I get the message I'd expect, that I can look inside - on the double, the loot has already been generated.
In the case of the shulker box, spectator mode shows that the loot isn't generated yet, but luck is still not applied.
I think in the case of the double chest, the placing players luck could still be checked. In the case of the shulker box and other containers, the code may just not be in place - but shulker boxes are perfect for loot rewards because they can be different colors and the box is a reward in and of itself.
EDIT: I also meant to add - breaking a container attached to a loot table does not check the luck value of the player either.
This is still an issue as of 14w32d. Commandblocks seem to be able to operate outside of the worldborder, but after teleporting away, with no players nearby, the commands stop.
This is with commands that are in map spawn chunks.
You can test this with a simple clock hooked up to a say command. Teleport 5000 blocks away and then set a small worldborder centered on you. You bay need to teleport back and forth a few times. It also seems like it will happen after just a short time.
It feels like the game is unloading the chunks because the area is outside of the world border, yet these chunks are spawn chunks and should not be unloaded.
This is vital for map makers that want to have a "game system" that is only loaded for the server, but that they also want to use the world border feature in.
I can explain more if necessary, but I think this crowd knows what I mean.
All command blocks are outside the border
13w05b Rename Bug Still Exists
Check attached photo above
How did you reproduce?
I think the stairs have a data value # of ??, but when it's placed it would also have an extra number, — :, the added number would be the direction it's facing. I don't have time to test, but I'd place a quartz stairs in each direction, clear your invintory, pickblock the first one - /kill command, etc for each direction you may have used and see if that is the cause of the issue.
I just wanted to comment that I love that you were just actively looking for bugs - this is such a great community!
But then I thought I'd feel bad just posting that, so I tried to reproduce it and no luck. I even matched your inventory as exact as I could from shot 2, is that a slowness potion?
I made a portal near spawn, then made a second portal and returned then did the /kill with keep inventory on. I also used /tp in the nether to for like 400 blocks away and tried again - no issue.
Was this a new world, or a world from a previous version? Were you near natural spawn? Any other game rules you change? Render distance? Were the chucks loaded when you did /kill or when you went back to the normal world?
Other questions that may help, but honestly shouldn't matter, 32 or 64 bit Java (and version) I'm using Java 7.10 64x Windows 8. Can you verify a default install (No MODs)?
It definitely happened... I don't think there are any combination of keys you can press to put 64 of anything in the second slot to replace something.
==== Diffrent Idea Here ====
Did you at any point pick the stair block back up by using the 'pick block' key (middle mouse button)? If the answer is yes, then we'd have a direction to test.
Will do from now on - sorry
the 178.5 56 -517.5 is intended as far as I know. The solid numbers would put you on the cross sections of the blocks, the .5 puts you in the center of a block.
You could also use "-179.0 56 -518.0" if you want that specific location
Also if you have "tp @p -179 56 -518" as your command I don't see any arguments for radius.
http://www.minecraftwiki.net/wiki/Command_blocks
EDIT: I see the bug now, but the other stuff I typed should still apply.
I have also reproduced this bug: https://mojang.atlassian.net/browse/MC-5019
Retested in 1.4.6 - clean install, results posted above, please reopen
Juat forge and some basic HUD stuff, I'll retest the same map in a clean install and report back tonight.
What about the player heads? Should those lose the custom naming data?
It's called "lore" text. You'll need NBTEdit to add it to items. Visit my site: MiniCTM.com, I have some info there, you can also contact me there, or on the MC forums as "Brandonn".
But let's keep this area for information about this bug. 🙂
I am confirming this issue. I'm adding Piglins to the same team as the player so that they are friendly. I will try adding weakness so they do no damage to achieve the same result for now.
EDIT: Making a MOB deal no damage has caused it to not attack the player in that past - but that also does not work. You can set generic.follow_range to 0 but then they still attack when you are right next to them and a follow range of 0 makes them not walk around.
Anyway - not for the bug, I'm sure it will be fixed soon, but the solution I found that I now love, is to just make them all babies.
[media]