Spoon Boy

Is there a pertinent need to block carpet, trap door, etc lighting solutions? These are generally used by a lot of the community to make builds less "look at all my torches".

Honestly, I can't quite follow it. It just feels like restricting creative use of blocks that we've all used for years now and I'm not sure how that in any way benefits the game or adds fun.

I can't think of very many occasions where I'd say, "Ugh, there's just too much light from my light sources, I wish they were blocked by more things!"

Also, as far as trap doors and the like, kind of ignores texture packs (some of which have windows in ALL the doors – remember, default textures are optional).

I can understand an explanation of "It's logical!" but Minecraft has hardly ever been logical (and its unique rules are what make it a fun world). Also, as long as oak trees drop apples instead of acorns, there is no logic in this place anyway.  lol

Anyway, not trying to sound combative. I'm just... confused as to why such things are worthy of "nerfing" after being a feature for so long... resulting in tightening the leash on creativity, as it were.

Wait, so carpet is actually a candidate to be adjusted, too? That's... That's going to make a LOT of people mad, I think. lol

Kinda taking away established creative methods that've long been established by the community.

That has literally been a lighting method for years at this point.

I'd really hope we aren't going to be forced to spam torches everywhere! I mean, lanterns are nice and all, but they're hardly a replacement. It's not like anything casts light down to the ground without severe drop-off so you gotta spam the stuff.

...Also, I literally have entire hundreds-of-blocks-wide chambers that are entirely spruce trapdoor ceilings covering thousands of jack-o-lanterns with no visible lights besides a few ornamental lanterns... Aaaand I tend to light my underground with thousand-block-wide expanses of jack-o-lanterns covered with carpet. I do hope 1.14 isn't going to give me hell in that regard. lol

Also, by this logic, carpets should not allow light through, having completely covered the light source... but they still do.

I'm aware of that being the case on SOME blocks, yeah. But like... It worked YESTERDAY just fine. Not sure why the need to change the lectern lighting rules from Prerelease 2 to Prerelease 3...??

Being able to hide lights in creative ways is kind of a feature of Minecraft that shouldn't really be harshly restricted or it starts turning large survival builds into torch spam (literally what I'm having to do until these lecterns work again).

After testing this, I readjusted the beds to face all 4 directions, but the villagers defaulted to the wall it was next to each time.

I moved it away from that wall, and it shoved them into the new adjacent wall.

I move it back a block, expecting them to be ejected into the same position in relation to the bed (thus into the middle of the room).

No, it puts them in the 3rd wall it was now next to, the opposite side of the bed they were hopping out of a few seconds before.

This makes no sense to me. It's like they're programmed to target the nearest walls.

I've had to load from backups twice due to finding ALL my bed-using villagers missing (but the ones still in a defunct trading booth are fine each time).

I had a suspicion it was something like this as I tried to respawn villagers in their place, then slapped one while he was in bed and he teleported into a wall and suffocated.

It's a snapshot, so, problems bound to happen.  But maaan I swear I only ever notice they're gone after dumping a bunch of hours on some big project. lol

Happening again in massive amounts in 19w08b.

Tested this. Item is being pushed downward a block.

Yep, same thing happening in my crazy little snapshot house. It's full of framed maps and chest markers and every time I load, my inventory floods with dupes (in addition to lighting breaking, and inability to use a bed atm). Seems to be resolved already, at least. Here's hoping for a new snapshot soon!

Ah, yeah. As of right now if I have a villager with, say, Paper (DV of 5), and given names/descriptions/etc, the game only cares about DV (last I checked) and unless a DV was set, the NPC would just take any crafted paper with no name or lore... so DV let me make custom trade-ins players couldn't get unless performing tasks such as this. But ever since one particular snapshot it all turned pink and black and while it's still ... er, useable, it's completely weird looking.

It's fixed? Is this in a snapshot? Still present on my trade villagers in 1.8.6 as of right now.

Yup... I had a server I was creating in 1.7.10 but advancements in the 1.8 snapshots had me upgrade (for vital features that'd been missing) and prepare the server I'd been working on for a vanilla 1.8 release for friends, and public release when I had protection plugins available.

...unfortunately at one point everything that already existed in my map turned pink and black. I'd made heavy use of damage values because they were NECESSARY to do anything advanced.

I've been at a standstill ever since. I'm told this is in preparation for the plugin API, but that won't be release in 1.8... therefore map making features are now "intended to be completely broken, sorry guys" and that's pretty much that. I'm ... completely lost as to how to proceed in my own creations at this time. Really hope Mojang offers alternatives to what was lost... and soon. Not a year from now.

This worked perfectly fine until now, Mog... An invalid value showed the default texture.

I'm not sure if you know much about adventure maps and custom map makers, but this is practically a required staple for villager trades, quests, and command block interaction.

Ripping this away from us with a stone face cripples the creatives in the community. I know I've got months of work – that's been growing with 1.8 – suddenly useless.

I'm fine with this change if a comparable, or better, solution is provided. Right now Mojang has given us nothing that I know of.

Let users use damage values for their creations and let the blocks keep looking like their base counterparts.

Without damage values, what else do we have left?

"Also you can corrupt your map doing this. You're lucky that's all you got. The usual response from moderators here is "we never intended you to use that so we don't support it"."

I would challenge you to PROVE you can corrupt a map with damage values, since just about everything uses them.

It's fine if I have to define my own textures for the items – I could even define new textures and thus expand what I'm working on. This COULD be a beneficial change. However I don't know how one would link a new graphic to a damage value that's not yet defined, and I've had no luck finding anyone who can confirm that's actually possible (most say it isn't). :/

If anyone knows how to do that (link texture to DV in resource pack), I'd be so thankful.

Okay. I've tested this further. I highly doubt this is intended, and if it IS, then this is a horrible idea. Here are my findings:

"Villagers ignore names, Lore, and other tags... but paid attention to damage / data values." — CORRECT
"that villagers do not look at any tags got fixed, you can use the methods mentioned above" – LIES AND SLANDER
"a way around it is to simply create a duplicate texture and include a resource pack." – CANNOT FIND ANY EVIDENCE THIS IS POSSIBLE, PLEASE CONFIRM.

I removed the damage value from my special piece of paper.
I can now trade a stack of REGULAR paper for a whole stack of rare quest items rather than my 1 specially-data'd, lored, named paper item.
I can also craft with the specially made items as if they were regular paper.
This essentially breaks everything I've worked on for months.

How is this beneficial if I can't reskin the items? What's an alternate workaround that creates an uncraftable item that NPCs won't eagerly accept its regular counterpart for in its stead?

Okay, if this is "intended", then how do you link a texture to a damage value? Because I've been trying to figure out how to do this in vanilla for a couple weeks since my own report of this "bug" got shut down instantly...