Jay Avery

I want to create items which will render differently depending on information stored in an ItemStack capability. My goal is a bit similar to how vanilla items are rendered with a durability bar: the underlying item remains the same but there is another layer rendered on top which is one of a few textures. The possible overlay textures are the same for all the different items that have this property (just like the vanilla durability bar is the same for all items with durability), but the underlying item texture is different for each. I think I'll need to use item property override like the vanilla bow, but I just don't really understand how and can't find any tutorials or explanations. I can't figure out how the property override gets converted into json-usable information. I also really don't want to have to make multiple model files for every single item when they will all be using the same set of properties and overlays, so I'd like to figure out how to make some kind of abstract json that can be 'subclassed' without having to redefine things every time. But, I also don't know how to do that. And when I try searching for minecraft json help I mostly just find stuff about blockstates. A summary of my questions: 1. How exactly does item property override work? Is there a tutorial I can refer to? The apply method returns a float, but where does this go and how is it converted into different item textures? 2. How does inheritance work with json models? How would I go about making a parent model which uses the same overlays for the same item property override, but with a base texture that can be specified for each item type?

Forge uses github and accepts pull requests, when they deem them useful. Ohh, so you mean suggest a change to Forge that would make it easier for me to do this?

Yes, I acknowledged this in my original post!

Pull Request I don't understand what you mean by pull request here, isn't that a github thing?

PR?

Since I posted, I've found a way to hijack the vanilla durability rendering without needing to use actual item durability - and made a capability to handle my decay process. The problem I'm stuck with now is how to enable combining stacks of the same item that have different levels of decay - I'd really like to be able to make that possible by some kind of averaging process. But the ability to combine stacks seems to mostly rely on ItemStack.areItemStackTagsEqual which checks the capabilities. So if I'm storing my decay capability then vanilla will automatically prevent stacks with different decay levels from being combined. I could override all the various stack-combining methods in my inventory containers (I've already got custom containers anyway so that's easily possible), to manually check whether stacks can combine, and then update the stack capability accordingly, but that would be a lot of hassle and probably not totally reliable. Another option is to somehow cheat the NBT check by making my own subclass of NBTTagCompound to override the equals method and prevent it from checking the values which I want to be irrelevant. But I'm pretty sure that overriding an equals method so that it tells an outright lie about whether two objects are equal is some kind of cardinal sin and will probably cause all kinds of problems I haven't thought of. And even if I use one of those workarounds to make sure combining stacks is allowed, I still have the problem of how and where I combine the information from their capabilities to make the new one. It looks like gatherCapabilities in the ForgeEventFactory is the method that takes the capabilities of two stacks and combines them into one set. But that method uses the CapabilityDispatcher constructor which seems to always add the capabilities separately and doesn't have any ability to combine them in some other way. Maybe the ability to combine differently-decayed stacks is just a lost cause. It's still pretty good that I've got damageable stacks at all, so perhaps I should just let it go. If anyone else has any ideas or suggestions though, please tell me!

It sounds like a problem with your crate block itself, not the item. Can you post your code for the crate block?

I think it's extending GuiScreen that is the problem. That class is used for things like the inventory and comes with a bunch of inbuilt methods for receiving mouse and keyboard input. Based on how simple your GUI is, you can probably just extend the Gui class itself and draw it in RenderGameOverlayEvent .

I think it's highlighting the whole lot because the IItemPropertyGetter block is all still within the addPropertyOverride method's arguments.

I think sometimes eclipse just gets confused after a search and messes up the highlighting. Clearing the search results should work (the double-cross "remove all matches" icon at the top right of the search tab).

1) I'm planning to create custom chest TileEntities, so I will be able to add ticking for that anyway. 2) I understand that, and I'll either introduce workarounds (instant rot when a chunk becomes re-loaded, perhaps) or just let it go. 3) Some sort of averaging process - something like how spoilage levels are combined in the game Don't Starve. I know it's a big job and I might end up dropping it, but I'd like to give it a try if I can.

I want to make food items which can spoil over time while in a stack. It seems logical to use the vanilla item damage/durability for the spoilage, but damaged items can't be stacked. My first instinct would be to make a subclass of ItemStack and implement my own functionality for combining damage and stack sizes, but since ItemStack is final I can't do that. Does anyone have any ideas for how I could achieve something like this? Or will it be painfully difficult/unachieveable? Edit: update in post #5

You seem to have missed off the beginning of the crash report. There should be a line that says what the crash was, before it lists the stacktrace.

Yes... like I've been saying all along, the updateTick method is what you need to use if you want your block to act on random ticks.

Right. But BlockBush also does a bunch of other stuff which you probably don't want, like checking for soil underneath the block and various other methods associated with plants. If all you want is for the block to be passable by the player, then all you need to do is (in your class extending Block , not BlockBush ) override getCollisionBoundingBox to return NULL_AABB .

i have found what you mean: my code looks now like this, but somehow it still doesnt work .. x-x public class BlockUpdateFireBlockClass extends BlockBush{ public static final PropertyInteger AGE = PropertyInteger.create("age", 0, 15); public BlockUpdateFireBlockClass (String name,int light, Material materialIn){ super (materialIn); this.setBlockUnbreakable(); this.setLightLevel(light); this.setUnlocalizedName(name); this.setTickRandomly(true); } @SideOnly(Side.CLIENT) @Override public BlockRenderLayer getBlockLayer() { return BlockRenderLayer.TRANSLUCENT; } @Override public void onEntityCollidedWithBlock(World worldIn, BlockPos pos, IBlockState state, Entity entityIn) { entityIn.attackEntityFrom(DamageSource.cactus, 5.0F); entityIn.setFire(10); } /** * Convert the given metadata into a BlockState for this Block */ public IBlockState getStateFromMeta(int meta) { return this.getDefaultState().withProperty(AGE, Integer.valueOf(meta)); } /** * Convert the BlockState into the correct metadata value */ public int getMetaFromState(IBlockState state) { return ((Integer)state.getValue(AGE)).intValue(); } protected BlockStateContainer createBlockState() { return new BlockStateContainer(this, new IProperty[] {AGE}); } @Override public boolean isOpaqueCube(IBlockState state) { return false; } @Override public boolean isFullCube(IBlockState state) { return false; } @Override public AxisAlignedBB getCollisionBoundingBox(IBlockState blockState, World worldIn, BlockPos pos) { return NULL_AABB; } public int quantityDropped(Random random) { return 0; //Returns 0 item drop on destruction } @Override public boolean canPlaceBlockAt(World worldIn, BlockPos pos) { IBlockState soil = worldIn.getBlockState(pos.down()); return super.canPlaceBlockAt(worldIn, pos) && soil.getBlock().canSustainPlant(soil, worldIn, pos.down(), net.minecraft.util.EnumFacing.UP, this); } @Override protected boolean canSustainBush(IBlockState state) { return true; } @Override public boolean canBlockStay(World worldIn, BlockPos pos, IBlockState state) { if (state.getBlock() == this) { IBlockState soil = worldIn.getBlockState(pos.down()); return soil.getBlock().canSustainPlant(soil, worldIn, pos.down(), net.minecraft.util.EnumFacing.UP, this); } return this.canSustainBush(worldIn.getBlockState(pos.down())); } protected boolean canDie(World worldIn, BlockPos pos) { return worldIn.isRainingAt(pos) || worldIn.isRainingAt(pos.west()) || worldIn.isRainingAt(pos.east()) || worldIn.isRainingAt(pos.north()) || worldIn.isRainingAt(pos.south()); } public boolean requiresUpdates() { return false; } } Why do you extend BlockBush ? In any case, you still haven't overridden updateTick , so although the block is getting random updates it's not doing anything when they arrive.

Look at BlockFire - it uses several of these techniques together. It has setTickRandomly , then an updateTick method which sometimes destroys the block right away and sometimes uses World#scheduleUpdate to create fixed duration until the next update.

There are a few different ways you could do this. I think you could use World#scheduleUpdate when your block is placed. Then you can just set the delay for the update, and destroy your block in its updateTick method. (I've never done this, but it seems to be how redstone components get their updates) Otherwise, you could create a simple TileEntity for your block which just counts ticks and destroys the block once the limit is reached. If you are okay with the timing being slightly random, you could instead set setTickRandomly to true, and then have your block destroy itself in updateTick . Random ticks happen roughly once a minute but there's a lot of random variation.

Could the target BlockPos have a y co-ordinate that's higher than the top of the nether?

By default, BlockContainer renders invisible. If you want it to render from a normal block model you'd need override getRenderType and return EnumBlockRenderType.MODEL . But it is probably best to do as Draco18s recommends and not use BlockContainer at all.

It works because it doesn't have the TE_INVENTORY_SLOT_COUNT added at the beginning like your code in the OP does - so it results in 0, 1, 2, ... 8. Your code results in 9, 10, 11, ... 17. When you add a Slot, you need to give it the index for the inventory it is connected to, not the index of the slot in the container.

Oh well, maybe I didn't explain myself clearly enough. In any case, I think I've solved my own problem now. I'll probably post my code tomorrow in case anyone else wants it, although my solution isn't very elegant.

It's everyone's favourite zero index problem. Slot index = slot count - 1.

Oh I misspoke, I didn't extend SlotCrafting - I just have my own custom output Slot.

On how to implement getRemainingItems to use up more than one of the input ItemStack. It seems to be intended only for things like buckets where one item replaces another. But the reduction in stack size of the input items is actually done in SlotCrafting#onPickupFromSlot . So I need some way to get the information about which input stacks are reduced by which amounts (including the potential for the recipe to be in different positions in the crafting grid), and send that back to the crafting slot (which I have extended with my own class so I can do what I want there) to update it when the output is removed. Maybe a new method in my recipe that's like getRemainingItems but returns an array of ints to subtract from the input stack sizes? The trouble is, getRemainingItems just checks the items individually so the positioning of the recipe is irrelevant. But I'd ideally like to be able to have a recipe requiring any amount of different-sized stacks of the same or different items, which would mean somehow checking the input grid to find the exact position of the recipe, getting the stack size reductions, and then converting that to the size and shape of the crafting grid before returning it to be used by the slot. Seems a bit excessive but I can't think of a simpler way at the moment.