Getting proper ItemStacks from Blocks

So I've been attempting to create the Builder's Wand from Extra Utilties as a custom item for fun. Up until now it's worked great but I run into a problem when dealing with data.

For things like Pistons, the blocks are placed, but without rotation, which is a bit annoying.
For things like stained glass and logs, it thinks I don't even have the item because of rotation data and the data that colors it.

My question is: Is there a way that I can reliably get the correct data into an itemstack (e.g. When dealing with logs I'll get a stack with the correct type of log, but not the rotation, so that it can detect if I have it.)
My goal is to not cache blocks with itemstacks, as that's annoying and tedious.

 

What exactly are you trying to do? Place stained glass?

 

@Abs0rbed I believe Block.setData(data) can help fix your problem, although it's depreciated.

 

I'm pretty sure that all deprecated methods have some other way of doing it :/

 

You can do:

Code:

b.setTypeIdAndData(iStack.getTypeId(), (byte) iStack.getDurability(), false);

 

@Sulphate Unfortunately not true. Some methods do, some don't. For stained glass, there isn't an alternative.

@Elimnator That's an even worse method to use

 

@AdamQpzm I need to take a block in the world and see if it's in the player's inventory
It works great for normal blocks, but since some blocks share materials (like stone), it returns false.
I need a way to take, for example a piece of diorite (Material.STONE) and turn it into a stack that actually represents the diorite and not just smooth stone. And it has to work with other things like stained glass.

 

Actually, for stained glass, wool, and stained glass panes, there is a way:

Code:

ItemStack redwool = new ItemStack(Material.WOOL, 1, (short) 13);

ez

 

I think Adam was talking about a Block, not an ItemStack. If so, Adam is correct, unless a class StainedGlass/DyedGlass exists, which from what I see doesn't exist.

Can't you just do:

Code:

if (itemStack.getType() == block.getType() && itemStack.getData().getData() == block.getData()) {

'itemStack' being the item in the inventory (loop through the contents and add a null check).

Ignore the deprecations.

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

 

@KingFaris11 Yeah, just after I posted I solved the data issue, just didn't get the chance to post an EDIT.
I still have a problem with Rotation and things with lots of values like Leaves and Logs and Pistons. I'm not sure how to check to see if the regular item is in the inventory, while being able to place it the same way as one already in the world is.
I want to avoid any special cases if necessary

 

@Sulphate That method is also deprecated

 

No it isn't??? Creating itemstacks is certainly not deprecated.

 

@Sulphate My mistake, I was thinking of the (int, int, short) method. Either way, the (Material, int, short) isn't deprecated because the short represents durability/damage, not data, so it's not a magic number. When you're using it to represent data anyway, you're really just bypassing the deprecation rather than dealing with it. You'll still be using a magic number, which is the reason setData() is deprecated - this would be deprecated too if possible. Unfortunately, as I've already said, there's not a different solution for stained glass.

 

@AdamQpzm @Sulphate's way works...

 

@dlange Never said it didn't, I'm just pointing out that the method isn't really finding an alternative to a deprecated method, it might not be technically deprecated, but it's not a 'better' way of doing it.

 

@AdamQpzm

how is this not a better way of doing it? This is how you are meant to do it! This is why it isn't deprecated.

 

@Sulphate No it's not. If you look at the javadocs for the method you mentioned, you'll notice it's damage, not data. Why do you think that the byte is deprecated? It's not because there's anything wrong with byte or because short is better to use, it's because the number "1" doesn't really mean anything, but a colour (i.e. Red) does.