Bits not stacking
UberAffe opened this issue ยท 6 comments
trying to get my inventory file from the server owner so i can check the nbt information but I have 3 types of oak leaves that are not stacking, they all have the same #ID/meta. 1 type I chiseled a few days ago and 1 type I know for sure I got today because that is the type I continue to get when chiseling. The 3rd type I only have a few of and I'm not sure how/when I got them.
The only thing I can think of is that the date I chiseled them is preventing them from stacking.
Come to think of it I think leaves have a lot of possible states, like if they have been harvested.. silk touched, or some other things.
I don't think its possible to tell them apart by their names, or by their visibility, but MC considers them different blocks.
Might need some way to ignore certain states.,,
72f77320-5c4e-4d24-ac80-b167df6f1802.pdf
if you change the file type to .dat it will be my playerdata from that server, and the 3 types I am talking about are in hotbar positions 1,2,3
ID 18, 16402, and 32786
Block ID 18, with some metadata. so yeah, they are all different states as I suspected. I don't know what states however, that is in your world file.
But its not that important, I already know that its related to those hidden leaf states.
How about an overrides list of block properties to carry over when chiseling?
For example a map of blockRegistryID<->ListpropertyName:overridevalue
Then when you put down a new chiseled TE, check the overrides map before passing block metadata to the TE.
As a proof of concept I could fix the oak leaves problem with the following code in TileEntityBlockChiseled (warning: written at 3 am):
public void fillWith(
final IBlockState blockType )
{
IBlockState actingState = blockType.getBlock().getDefaultState();
String id = blockType.getBlock().getRegistryName().toString();
Map<String, Map<String, Object>> overrides = new HashMap<String, Map<String, Object>>();
Map<String, Object> leavesProps = new HashMap<String, Object>();
leavesProps.put("check_decay", false); leavesProps.put("decayable", false);
overrides.put("minecraft:leaves", leavesProps);
overrides.put("minecraft:leaves2", leavesProps);
if(overrides.containsKey(id))
{
Map<String, Object> overrideProperties = overrides.get(id);
for(IProperty property : blockType.getPropertyNames())
{
String name = property.getName();
if(overrideProperties.containsKey(name))
{
Object val = overrideProperties.get(name);
if(val == null || val == "default")
break;
else
actingState = actingState.withProperty(property, val);
}
else
actingState = actingState.withProperty(property, blockType.getValue(property));
}
}
// the rest of fillWith() using actingState instead of blockType
You could easily make the overrides map externizable and add IMC support.
Possibly, though it doesn't really solve the issue as it propagates with leave inheriting blocks. Which is the reason I've not really done anything re-guarding this issue up until now.
Its very much a patch job, and its not really a 'terrible' issue, so I've left it alone hoping a better idea could come along, though perhaps I'm a bit hopeful there.
I don't think it's possible to perfectly anticipate the blockstates of BlockLeaves child classes, but you can certainly try. For example if you move the overrides map to its own class, you could support things like this:
/*
* When creating a C&B TE from a block with registry id [anything], replace
* the "decayable" property with false.
*/
overrides.add("*", "decayable", false);
or even better, this:
/*
* When creating a C&B TE from a block instanceof BlockLeaves.class, if that
* block's registry id is [anything], replace the "decayable" property with
* false.
*/
overrides.add("*", BlockLeaves.class, "decayable", false);
By adding IMC support to the overrides map, you try { to let other mods be compatible out-of-the-box }.
By making the overrides class implement Externizable, you can let power users and modpack makers tweak their game the way they want it. Just make sure the user configs trump IMCs and replace your default map.