MrCaracal

I've been having the same issue. Just for fun, I switched my fluid block to extend from Vanilla's BlockLiquid rather than BlockFluidClassic, and to my great surprise, it fixed this rendering issue. There's a method in net.minecraft.Block, getRenderType that returns an integer value based on the rendering type that Minecraft should use to render the block. In BlockFluidClassic's superclass, BlockFluidBase, this method is overridden to return a value from the Fluid Registry, renderIDFluid. The value defaults to -1. I don't see anywhere this value can otherwise be set (since there's no registerFluid method that sets this value for the fluid anywhere I can find), but this makes Minecraft not render the interior faces of the fluid block. By overriding this method in my fluid block implementation to return 4 (which is what Vanilla's BlockLiquid class does), I managed to fix the rendering issue, and now the interior faces of the fluid block display properly and with the correct texture. If a veteran knows the "correct" way of setting the Fluid's renderIDFluid value for mod fluids, please step in! IMPORTANT: This will cause a crash if your fluid's Material is anything other than Material.water. EDIT: I just looked again and noticed that renderIdFluid is a static value, so obviously cannot itself be changed per fluid block. Looks like overriding getRenderType is the way to go, but doesn't seem to work for custom fluid materials.

SOLUTION: I have discovered the source of my issue. After much investigation I have discovered that Vanilla's ItemBlock renderer does not care at all about any of the getIcon method family, and instead is based entirely on the associated Block's rendering. A custom renderer is required for what I am trying to accomplish. Hello all! I'm having a bit of trouble with a custom ItemBlock implementation. I have a multi pass rendered Block that has multiple subtypes using metadata. The first pass renders vanilla's stone brick texture, and the second pass renders a texture on top of it based on my Block's metadata. The block implementation is working as expected, but I cannot seem to get the ItemBlock's rendering to behave. I have registered the custom ItemBlock in the GameRegistry alongside its Block counterpart as per the norm; The ItemBlock code is as follows: public class ItemBlockTest extends ItemBlock { public ItemBlockTest(Block passedBlock) { super(passedBlock); this.setHasSubtypes(true); } @Override public int getMetadata(int metadata) { return metadata; } @Override @SideOnly(Side.CLIENT) public boolean requiresMultipleRenderPasses() { return true; } @Override @SideOnly(Side.CLIENT) public int getRenderPasses(int metadata) { return 2; } // DEBUG! @Override public IIcon getIconFromDamage(int passedMetadata) { return Blocks.dirt.getBlockTextureFromSide(passedMetadata); } } I have the ItemBlock's getIconFromDamage method returning Dirt's texture as a debugging measure, but this is not the case in game. The ItemBlock is instead only rendering the texture from the parent Block's second render pass, no matter what I put in the getIconFromDamage method. I know the method is being called, I had previously put a System.out.println in there; the return value just doesn't seem to be used. My hunch is that the getIconFromDamage method is used for ItemBlocks that have a sprite texture and don't render as a cube, but then why wouldn't the inventory render simply show the dirt texture as a flat plane? My other hunch is that I might need a special rendering handler to accomplish what I want here: An ItemBlock that has the texture of stone bricks, with another texture overlaid based on the ItemBlock's metadata. This is probably just a major derp on my part, could anybody shed some light here?

Thanks for the great input! I actually did try the modulo thing before, but I left it out of the OP because I was most curious about the design reason for why the client increments whereas the server is clamped. I just can't figure out why it works this way and was wondering whether anybody with more experience knew. As far as the "non-coterminal" thing: I tried it again, paying closer attention, and this time noticed the only times the angles diverged by any noticeable quantity (still less than 10° usually) was when the block was placed while the player was currently moving, or immediately after a log-in. If I'm reading you right, jabelar, this can be explained by the fact that the client will have the value nearly instantly, while the server is waiting for a packet to place the block, whereupon it checks the entity's rotation?

Hello all! I was toodling around with a block I had made, and inserted the following code into the Block class for the purposes of figuring out how entity rotation worked. The block, when placed, outputs the raw rotationYaw value of the placing entity to the console, once for the Client and once for the internal Server. The relevant function is below, everything else is standard boilerplate for a basic block class extending Block: However, when run, I noticed something that struck me as odd. As I rotate my character in place, the Client rotationYaw simply increases and increases seemingly forever, whereas the Server rotationYaw seems constrained within 0-360. Logging in and out does not seem to "synchronize" these values, and eventually results in angles that are not coterminal. (The Client rotationYaw minus a multiple of 360 does not always equal the Server rotationYaw). An example log output is below: I'm just curious as to how this value is set, whether the client value is at all useful and whether it's simply the convention to test for server/client if rotationYaw is needed. Thank you in advance for your time! I am extremely new to modding in general so I apologize if this is a stupid line of questioning. I am running FML 7.2.156.1060 for Minecraft 1.7.2 on Java 64-Bit Server VM, version 1.6.0_65 on OSX.

In your RoadsShapedRecipe class, the for loops within your matches method (lines 46 and 48) are checking "i <= 5"; shouldn't this be "i < 5" for a 5x5 grid?