[SPIGOT-445] Many blocks cannot store data Tag Created: 18/Jan/15  Updated: 24/Jan/15  Resolved: 24/Jan/15

Status: Closed
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Kakifrucht Assignee: Thinkofname
Resolution: Invalid Votes: 0
Labels: 1.8, Craftbukkit, Essentials, bug, nbt, spigot

Plugin: (Essentials, not really causing it though, only showing that this issue exists.)

 Description   

When giving yourself blocks like stone, you can get unexistant ID's, like for example /i stone:1000 1, however when trying to get Mobspawners or many other blocks, that were not updated with 1.8, you can't. This is not really a bug, but since plugins sometimes use the Data-Value to store information (like Essentials, to store what kind of mobspawner it will be converted to after placement), this should probably not be limited.
It breaks plugin functionality. It does not really make sense to have blocks with unlimited data-value, but for most it doesn't allow storing it.

This bug started existing with the 1.8 builds. Using /give player mobspawner:123 will just give you a mobspawner without the data value.



 Comments   
Comment by Kakifrucht [ 19/Jan/15 ]

Thanks for the information, however I'm not really into adding more plugins for simple stuff like this.
Essentials already provides this functionality, so I'm hoping they can find a new method to store what kind of spawner the user wants.

Comment by Bobcat00 [ 19/Jan/15 ]

The plugin SilkSpawners will allow you to do what you want. The plugin also provides multiple methods for specifying the spawner type.

Comment by Kakifrucht [ 19/Jan/15 ]

Oh well, in that case it's an Essentials bug, they should fix the essentials.spawnerconvert somehow.

Comment by Black Hole [ 19/Jan/15 ]

Vanilla is filtering the data values. In a future minecraft update all invalid data values will be removed in the transition to the block state model.

Plugins should use some other way to store their data.

Generated at Thu Apr 03 13:22:20 UTC 2025 using Jira 10.3.3#10030003-sha1:d220e3fefc8dfc6d47f522d3b9a20c1455e12b7b.