strumshot

Thanks for informing me! I will get right on that. Keep an eye for my update!

Yes, you do have permission! Just mention the mod in any promotional posts, and if you wouldn't ming linking to your server in this thread! Thanks and enjoy.

You should be able to get it now. Maybe the flow would be like: Client presses button(handled in the gui) Gui sends a packet "pressedUpButton" to server Server makes changes to item nbt according to "up button" packet Server responds with a "ichangedthenbt" packet Client changes the local nbt or refreshes from server, etc. to you can see the changes in the gui Eat a cookie

Primed Entity and... RenderingRegistry.registerEntityRenderingHandler(NewTNTPrimed.class, new RenderTNTPrimed()); I don't expect it to help, as again, I'm using the default texture and renderer, but maybe you missed a line of code, and maybe you can just assign a different texture. Good luck!

Yes, that can be tricky! I added a field to store my TE in my container, which I assigned in construction. Then, I was able to access the TE through the container in the client packet handler like such: GuiScreen screen = Minecraft.getMinecraft().currentScreen; if (screen instanceof GuiShopper) { ContainerShopper container = ((GuiShopper) screen).container; container.tileEntity.Cost = message.cost; container.tileEntity.markDirty(); } Your usage will look different, but you get the idea. You are right, you cant access the player simply!

If you plan on doing this sort of thing often, I would suggest making a custom function that takes the desired message and inserts the formatting before every word, because multiple line messages will stop the formatting as of the second line. Some of the code would look like this: String msg="This is the message you want to format correctly so it displays the formatting on multiple lines."; String[] tmp = msg.split(" "); String formatted = ""; for(int x = 0; x < tmp.length; x++){ formatted += EnumChatFormatting.AQUA.toString(); formatted += tmp[x]; formatted += " "; } You would have to mess around with that, and would have to be more creative to use multiple formats in one message, but that's the idea.

I dealt with this recently and solved my issues, however, I was simply replacing the core classes and not the textures, but I still had to address the renderer. If you think my code would help you, I'd be happy to share it.

I can tell you from that error that you haven't numbered your packets correctly - they each need an individual number - or you haven't referenced that number correctly.

Its about time... I always thought that was odd about most people's 1.7 code. I feel like one tutorial chained the calls that way to keep all the code in the main mod file and then many modders/newer programmers just thought that was how it worked!

Well same here lol, but when you request a gui the handler is done through your proxies... it tells the server to open a TileEntity/container and the client the gui item, as gui is only on the client. I will share something when I can.

Wait a sec... does this mean one would be able to connect to a non-debug server? (should I post this in a new thread? not meaning to hijack...)

We may generically have a language issue here. I think we are all debuggers telling you how to discern if a specific block is an instance of an interface, while you are wanting to search for one in your world... is this correct?

This is in the Block base class and can be overridden by any custom block /** * Called whenever an entity is walking on top of this block. Args: world, x, y, z, entity */ public void onEntityWalking(World p_149724_1_, int p_149724_2_, int p_149724_3_, int p_149724_4_, Entity p_149724_5_) {}

And the final version of my renderer, with the rendering from metadata method copied and cleaned up a bit, so I can play with the color. Note: it only changes the color of the inside of the hopper (which is fine enough for what I wanted) but its calling an IIcon which could easily enough be overridden if someone else finds this and needs to do that. @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { Minecraft.getMinecraft().renderEngine.bindTexture(TextureMap.locationBlocksTexture); return this.renderBlockHopperMetadata(renderer, (BlockHopper)block, x, y, z, renderer.blockAccess.getBlockMetadata(x, y, z), false); } public boolean renderBlockHopperMetadata(RenderBlocks renderer, BlockHopper p_147799_1_, int p_147799_2_, int p_147799_3_, int p_147799_4_, int p_147799_5_, boolean p_147799_6_) { Tessellator tessellator = Tessellator.instance; int i1 = BlockHopper.getDirectionFromMetadata(p_147799_5_); double d0 = 0.625D; renderer.setRenderBounds(0.0D, d0, 0.0D, 1.0D, 1.0D, 1.0D); renderer.renderStandardBlock(p_147799_1_, p_147799_2_, p_147799_3_, p_147799_4_); float f1; if (!p_147799_6_) { tessellator.setBrightness(p_147799_1_.getMixedBrightnessForBlock(renderer.blockAccess, p_147799_2_, p_147799_3_, p_147799_4_)); int j1 = p_147799_1_.colorMultiplier(renderer.blockAccess, p_147799_2_, p_147799_3_, p_147799_4_); float f = (float) (j1 >> 16 & 255) / 255.0F; f1 = (float) (j1 >> 8 & 255) / 255.0F; float f2 = (float) (j1 & 255) / 255.0F; if (EntityRenderer.anaglyphEnable) { float f3 = (f * 30.0F + f1 * 59.0F + f2 * 11.0F) / 100.0F; float f4 = (f * 30.0F + f1 * 70.0F) / 100.0F; float f5 = (f * 30.0F + f2 * 70.0F) / 100.0F; f = f3; f1 = f4; f2 = f5; } } IIcon iicon = BlockHopper.getHopperIcon("hopper_outside"); IIcon iicon1 = BlockHopper.getHopperIcon("hopper_inside"); f1 = 0.125F; tessellator.setColorOpaque(150, 25, 25); renderer.renderFaceXPos(p_147799_1_, (double) ((float) p_147799_2_ - 1.0F + f1), (double) p_147799_3_, (double) p_147799_4_, iicon); renderer.renderFaceXNeg(p_147799_1_, (double) ((float) p_147799_2_ + 1.0F - f1), (double) p_147799_3_, (double) p_147799_4_, iicon); renderer.renderFaceZPos(p_147799_1_, (double) p_147799_2_, (double) p_147799_3_, (double) ((float) p_147799_4_ - 1.0F + f1), iicon); renderer.renderFaceZNeg(p_147799_1_, (double) p_147799_2_, (double) p_147799_3_, (double) ((float) p_147799_4_ + 1.0F - f1), iicon); renderer.renderFaceYPos(p_147799_1_, (double) p_147799_2_, (double) ((float) p_147799_3_ - 1.0F) + d0, (double) p_147799_4_, iicon1); renderer.setOverrideBlockTexture(iicon); double d3 = 0.25D; double d4 = 0.25D; renderer.setRenderBounds(d3, d4, d3, 1.0D - d3, d0 - 0.002D, 1.0D - d3); renderer.renderStandardBlock(p_147799_1_, p_147799_2_, p_147799_3_, p_147799_4_); if (!p_147799_6_) { double d1 = 0.375D; double d2 = 0.25D; renderer.setOverrideBlockTexture(iicon); if (i1 == 0) { renderer.setRenderBounds(d1, 0.0D, d1, 1.0D - d1, 0.25D, 1.0D - d1); renderer.renderStandardBlock(p_147799_1_, p_147799_2_, p_147799_3_, p_147799_4_); } if (i1 == 2) { renderer.setRenderBounds(d1, d4, 0.0D, 1.0D - d1, d4 + d2, d3); renderer.renderStandardBlock(p_147799_1_, p_147799_2_, p_147799_3_, p_147799_4_); } if (i1 == 3) { renderer.setRenderBounds(d1, d4, 1.0D - d3, 1.0D - d1, d4 + d2, 1.0D); renderer.renderStandardBlock(p_147799_1_, p_147799_2_, p_147799_3_, p_147799_4_); } if (i1 == 4) { renderer.setRenderBounds(0.0D, d4, d1, d3, d4 + d2, 1.0D - d1); renderer.renderStandardBlock(p_147799_1_, p_147799_2_, p_147799_3_, p_147799_4_); } if (i1 == 5) { renderer.setRenderBounds(1.0D - d3, d4, d1, 1.0D, d4 + d2, 1.0D - d1); renderer.renderStandardBlock(p_147799_1_, p_147799_2_, p_147799_3_, p_147799_4_); } } renderer.clearOverrideBlockTexture(); return true; }

Definitely this! I'd like to note that I was attempting to offer an alternate solution, assuming instanceof "doesn't work" - but as they pointed out, it should.

O.K., I found this on the wiki, and found out how to register properly, which did actually kick it to the rendering class I made. IShop.filter.renderID = RenderingRegistry.getNextAvailableRenderId(); RenderingRegistry.registerBlockHandler(IShop.filter.renderID, new FilterRenderer()); But then, this line had issue in that the Boolean set to false would ignore the blocks directional metadata, and set to true would through a render error that it was already tessellating: return renderer.renderBlockHopperMetadata((BlockHopper)block, x, y, z, modelId, true); So I changed it to @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { // i'm not sure what the last boolean is... 50/50 chance! Minecraft.getMinecraft().renderEngine.bindTexture(TextureMap.locationBlocksTexture); return renderer.renderBlockHopper((BlockHopper)block, x, y, z); } ...and BOOM! Now to get the color change per your suggestion...

Okay, I have to play the noob here... public class FilterRenderer extends TileEntitySpecialRenderer implements ISimpleBlockRenderingHandler { @Override public void renderInventoryBlock(Block block, int metadata, int modelId, RenderBlocks renderer) { } @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { // i'm not sure what the last boolean is... 50/50 chance! Minecraft.getMinecraft().renderEngine.bindTexture(TextureMap.locationBlocksTexture); return renderer.renderBlockHopperMetadata((BlockHopper)block, x, y, z, modelId, true); } @Override public boolean shouldRender3DInInventory(int modelId) { return false; } @Override public int getRenderId() { // ? return Block.getIdFromBlock(IShop.filter); } @Override public void renderTileEntityAt(TileEntity p_147500_1_, double p_147500_2_, double p_147500_4_, double p_147500_6_, float p_147500_8_) { // it made me implement this.... what to do? } } And I tried to register as such... RenderingRegistry.registerBlockHandler(new FilterRenderer()); But how is it impelented? By the ID assignement? Or the render type in the Block class? /** * The type of render function that is called for this block */ public int getRenderType() { return 38; } Here's the whole block class just in case...

something to the effect of invalidCast edit: I probably should have waited till I got in front of my computer, sorry for being short with those responses. Anyway I know this method would work, but back in the day I was taught to avoid catch statements whenever possible, as they were taxing on performance. I'm not sure if that's still the case, or if Java has a specific implementation for the kind of check you are looking for. Maybe someone who drinks more Java can chime in on the %100 official of if this is the best practice, but again, I know it would work. Also, I'm still used to C# at the end of the day where you don't necessarily have to provide the explicit exception type. I was trying to suggest doing it without the try/catch and trying to cast something you know is not IPowerProvider and letting it crash and tell you the exception type; but again, it should be "InvalidCastException", so the code might look like this: try { IPowerProvider p = (IPowerProvider) var; // success, is IPowerProvider } catch(InvalidCastException){ // not IPowerProvider }

I would put a generic Exception, or you could run it once with something you know will fail and it will tell you theeexception type. I dont know right offhand.

Try { IPowerProvider p = (IPowerProvider) var; // success, is IPowerProvider } Catch { // not IPowerProvider } Im on a phone, lol so sorry for any goofed syntax!

I dont know if this is the best way by you could try to cast it as an instance of your interface and wrap it in a try/catch.

This!

See, the first part of your reply is why I thought it would be more involved, like copying the code over and converting to tesselators or wahtever... and the second part is what i dont want to try! But yoi convinced me to try the ISBRH.

Well thats the thing is I'm more of a logic programmer and haven't played with much rendering - MC or otherwise - so advice here can save me literally hours! I thought coming into it using the simple handler wouldn't be so simple, but I may give that a shot.

I would just like to note that capital letters are ONLY o.k. for classes and the fields/methods within. AKA, from the .java file onward, caps are o.k.. Do NOT name your packages or directories - and I would suggest anything that points to them, such as mod ids - with any caps. It can cause serious issues come publish time, as it behaves differently from eclipse than once compiled. Trust me, I learned the hard way. Even if you have no errors and it runs fine, and one or two mods work fine while published. You WILL eventually hit an issue.