Block.setTypeIdAndData() fails to set direction for certain block types

I'm trying to import blocks from a file with their corresponding data values. I'm using setTypeIdAndData to add the blocks to the world. The resulting behavior is pretty inconsistent so far; some block types work fine, others seem to disregard the data value entirely.

Tested block types that work: signs, wool, pistons
Tested block types that don't work or have strange behavior: furnaces, tracks, torches

I found a couple threads about setTypeIdAndData() while searching for solutions, but none have addressed this as an overall problem. I've tried setting applyPhysics to both true and false with no effect. I've also tried refreshing the chunk and logging in to the server again.

The code in question is pasted below. Note that this is part of a block of code that pulls in 'rooms' of 16x16x8 blocks. blocks and blockData are byte arrays. The system.out line is outputting the data values to console so I can verify they are correct for the given coordinates and block type (they are).

Code:

// Add blocks to chunk
for(int x = 0; x < 16; x++)
{
	for(int z = 0; z < 16; z++)
	{
		for(int y = 0; y < 8; y++)
		{
			if(blockData[DungeonMath.getRoomPosFromCoords(x, y, z)] > 0)
			{
				System.out.println("Val "+blockData[DungeonMath.getRoomPosFromCoords(x, y, z)]+ " for "+x+","+y+","+z+" of type "+blocks[DungeonMath.getRoomPosFromCoords(x, y, z)]);
			}
			this.chunk.getHandle().getBlock(x, y+8, z).setTypeIdAndData(
					blocks[DungeonMath.getRoomPosFromCoords(x, y, z)],
					blockData[DungeonMath.getRoomPosFromCoords(x, y, z)],
					false
			);
		}
	}
}

Has anyone else encountered this issue and found a solution? Any workarounds?

Restarting the server also does not fix the bad blocks, so the data value is being discarded or overwritten at some point.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Try setting the blockface.

 

@Adamki11s Blockface isn't something you can set as far as I can tell.

 

True, a block has 6 faces, so how to set them...
For your problem: Try to play with other things, too. For example: block.getHumidity() (which represents the damage value, if I remember correctly, but as blocks like furnances, tracks and torches don't have a damage value it could be very likely that other data is stored there, like the color of wool is the damage value, too... )

 

@V10lator Yeah, furnaces, tracks, and torches use their damage/data value to store the direction they're pointing. I'm actually pulling the data value when I export the blocks, then setting the value when I import them again. I've checked the value (should be 2-5 for furnaces) and that's fine, leading me to believe it's a bug.

 

Data != Damage!
Data = block.getData();
Damage = block.getHumidity();

 

@V10lator Ah, thanks for the clarification. Do any blocks actually use a damage/humidity value for anything? Furnaces use their data value to represent orientation.

Workaround
Certain blocks seem to ignore the data value if it's specified while setting the block. I've now worked around the issue by running the setData call separately from setting the type, after all the local blocks have been placed. Furnace, torch, and track orientation are correct with this workaround.

 

Yes, don't ask me which exactly as I'm really KO right now... But I think (not sure...) the color of a wool block is stored there, for example.

So I was wrong and it seems to be a bug in bukkit. Please report it here: http://leaky.bukkit.org/

 

As far as I'm aware, the difference between data and damage is that data is used for blocks, and damage is used for inventory items. Blocks do not have damage, and inventory items do not have data (but the game uses the items' damage to track data in certain situations).

 

@nisovin That was my understanding as well.

If I get the time I'll do some more rigorous testing before submitting it as a bug. It does seem to have a relation to the blocks surrounding the (for example) furnace, so the way in which I'm setting blocks may be kind of an abnormal case (setting a swath of adjacent blocks in sequence).

 

Thank you for posting this workaround. It's 2013 and this is still seems to be a bug with setTypeIdAndData(). =(