Village lamp post floating torches

My adventure map was made in 1.3.2 using the seed 31337. When generated in 1.3.2, the torches are fine. But the same seed in 1.4.4 makes the torches float.

Just make a (normal, not superflat) map with the seed 31337, and teleport to -971, 77, 229.

/tp -971 77 229

@mrheat: sure, but this new issue may be caused by the fix for [MC-1611]

I can confirm the bug with the "31337" seed. In 1.4.3 all torches are fine. In 1.4.4 the torches in the village are floating. The torches in the strongholds are fine in both versions.

I've had the same problem.

I have discovered this minor problem persists in Minecraft 1.4.5. There are other bugs newly introduces in 1.4.3-1.4.5, which has me feeling that they should wait on doing pre-releases until we've found everything.

This should be updated to include 1.4.5.

Confirmed, v.1.4.5

I can confirm this, the torches looked exactly the same as your screenshots right there, and the fence part was also floating, but I'm not sure if that has to do with the torches.

I have actually seen this several times in a Mineshaft. I have seen also maybe 3 times that a torch was "attached" to a cobweb ._. I'll try to post a screenshot next time I run into it

please update to 12w49a

This still occurs in even the most recent versions (up to 1.4.6pre).

Attached screenshots of two separate villages generated in 1.4.6 within the same seed.

(The village depicted in the second screenshot came with one of the torches already lying on the ground, though this may have been caused by something I didn't see; I just took the picture as it was.)

Confirmed for Snapshot 13w02b.

Reading the code for the placing of torches in structures, it would seem that the code relies on some automatic algorithm to decide which way to attach the torch. The placement code itself does not specify it. Apparently, it doesn't work any more (or works worse than before).

Note, it didn't work well earlier, either. For example, in mineshafts the torches could be randomly placed on any of the neighbor surfaces if there was more than one. That is, it made a guess about the surface and got it wrong.

The need for automatic guessing of the orientation comes from the fact that the structure "blueprints" are defined in only one orientation, while the structure can be placed in multiple different orientations. This needs rotation of coordinates. Easy to do for blocks that are symmetric and do not need to be rotated themselves. The non-symmetric ones were left to be handled by automatic guessing...

The correct solution would be to add different placement method for those blocks that need orientation and which can not solve the correct orientation by itself. (For example, glass and fences, as they are, can always figure out how they should represents themselves, but e.g. torches, stairs, ladders can not always guess the right surface to attach to or the right orientation). A method that allows specifying the orientation like the player does; you're watching from here, and pointing to there, click. Such additional data can be rotated in the structure placement routines themselves just as easily as the block's coordinates themselves.

This solution might fix some apparently other bugs, too, like the stronghold library torches being fancily (MC-7010) or desert temple corner tower stairs being wrong, etc.

(EDIT: found a method that is supposed to rotate such blocks (i.e. adjust their metadata), but seems it is not used for torch placement. However, the method is of bad design anyway; the inner functionality of various blocks (the interpretation of metadata of torches, ladders, etc.) gets spread from their own classes into StructureComponent-class; the rotation code should be in their respective classes, which the generic rotation method would delegate the tasks to.)

Confirmed 13w04a