Just noticed you stored the covers as shorts, this makes it impossible to properly get texture based on NBTTags as is done with Forestry planks.

Just threw this together for our new rewrite for the DynamicElvators as a possible solution

if (this.camoItem != null) {
NBTTagCompound itemNBTTagCompound = new NBTTagCompound();
this.camoItem.writeToNBT(itemNBTTagCompound);
nbttagcompound.setTag( "CamoItem",
itemNBTTagCompound);
}

Foresty items use tile entities and should therefore be excluded as covers to begin with - unless I'm misunderstanding you?

True but the ItemStack equivalent stores it's own NBTTag info using the itemStack.WriteToNBTTag function we can store the item much like how chests store items.

I confess I'm not sure what this would accomplish. I don't have a lot of experience handling NBTTags, either.. which might explain my confusion. But as far as I can tell my short's do just fine for holding covers (but may have to change in 1.7+).

O.K. This is fine as is for most blocks but some mods in the attempt to shrink their ID footprint use NBTTags on items to actually differentiate between textures.

IE forestry planks as an itemstack stores the following NBT Tag

woodtype: 1-29 or so

Sengir then returns the correct texture based on this.

This may become a none issue in 1.7 but they did away with blockIDS in the new version

We'll see what happens after 1.7, but I tend to ignore changes aimed specifically for increasing Forestry compatibility... mainly due to it's reliance on tile entities for simple things.

fair enough

OO just thought of another reason to store items as NBT Tags, if I give the carpenter block an Item that uses NBT tags, when you drop the item it will no longer be the correct item since all the NBT data would be gone, changing that item into a different version of it self.

This is an edge case scenario

If this in any way requires lifting the tile entity restriction for covers, it's going to create a lot of problems. It's very difficult to render blocks in the world when they have a dependency that doesn't exist.

It shouldn't require TE inception, I'll see if I can implement a system that will be satisfactory

IN my implementation covers will still just use ID:DMG the only thing that will be different is the items dropped

Implemented for 1.7.2 port.