[SOLVED] Getting Tile Entities for Crop Type Renderers

[defiant810]

In my mod I am trying to make a block that has a render Id of 6 (crops), but also has a TileEntity associated with it to store what growth stage it is in (it is a support structure that can grow different kinds of vines on it). This means that I also want to be able to return a different texture based on the growth stage and type of vine that it is growing. The problem is that in the RenderBlocks class, when it is time to get the texture needed for the icon, all blocks with render type 6 have "getIcon(int, int)" called, which does not allow me to access the TileEntity at the given point and use it to return the proper icon. The method I need is "getBlockTexture(IBlockAccess, int, int, int, int)" since that allows me to access the TileEntity stored at that point, but it is never called for all blocks of render Id 6.

 

I know that you can access the RenderBlocks and therefore its IBlockAccess field using "Minecraft.getMinecraft().renderGlobal.globalRenderBlocks.blockAccess", but there is no way to get the current position that the renderer is rendering at, so I still cant access the proper TileEntity. I have also tried making a custom TESR that just overrides the active texture and then calls the renderBlockCrop() method in RenderBlocks, but then the block appears invisible.

 

My question would be how to get around this without making a new TESR and basically copying the rendering code for crops, which I could do but would like to avoid if possible.

[robustus]

How many stages is your crop?  If not more than 16 you probably don't need a tile entity.  Each metadata can represent a stage of the crop

[defiant810]

No we specifically made it to have a TileEntity, because there are 4 growth stages (empty, growing, grown, and flowered), as well as we have 6 or 7 different types of vines, with more planned. The empty stage is not tied to a vine type, but every other growth stage is, so that is 3 stages for each of the types of vine. We are also compacting all of them into a single block to save on block ids, and to make it simpler to manage.

[robustus]

Block IDs are going to be obsolete in the next Forge, you might as well just use extra blocks

[defiant810]

What do you mean BlockIds are going to be obsolete in the next forge? Could you give me a link to that, or at least explain it.

 

Also I would prefer a way to do this is if it is possible, for simplicity.

[ShetiPhian]

BlockIDs are not obsolete, you just have no control of or access to them anymore, and they can also be different per world.

There is still an internal array thus still a limit. (32000 items, including the 4096 blocks)

'Unlimited' never exists, there will ALWAYS be a limit, this one is in place based off the save format.

Don't use more then you need

 

 

As for rendering, you'll need to code a custom renderer.

No need to code it from scratch, you could copy the minecraft code into your own render class and make the needed changes to it.

[TheGreyGhost]

Hi

 

I'd suggest you stick with one Block per type of vine, with metadata for the growth stage.  The reason I say that is because TileEntities take up a lot more memory and are significantly slower to render if you have a lot of them.  They're also harder to program properly.  If you're worried about keeping your code conceptually simple, you could create a base BlockMyVineBase and derive all your different types of vine from those.

 

If you want to use the TileEntity approach, you can either render your block using a TileEntitySpecialRenderer, or alternatively (similar to your original idea), you can use an ISimpleBlockRenderingHandler, which is given the [x,y,z] when the rendering method is called.  A bit more info here:

http://greyminecraftcoder.blogspot.com.au/2013/07/block-rendering.html

 

-TGG

 

 

[defiant810]

I have never even heard of ISimpleBlockRenderingHandler. I took a look at it, it was super easy to implement. This is exactly what I needed! Thanks a ton.