TheGreyGhost

Hi Try looking in ItemFirework.onItemUse When the rocket goes bang, it is handled by EntityFireworkRocket.handleHealthUpdate which calls in WorldClient: this.mc.effectRenderer.addEffect(new EntityFireworkStarterFX(this, par1, par3, par5, par7, par9, par11, this.mc.effectRenderer, par13NBTTagCompound)); Hopefully there are enough clues in those methods for you to figure out how to do what you want. Cheers TGG

Hi The basepath is related to where your compiled code is located during debugging. Forge determines it automatically. For now, just put your textures into the appropriate folder under basePath. {base path}/assets/{mod name}/textures/items/{Icon name}.png When you release your mod in zip format, the basePath will change to be the zip file and your texture folders should be found automatically in the zip file if you use the same structure. You shouldn't change basePath, I predict that will break all sorts of other code, and it's not necessary. Cheers TGG

Hi again I read your post a bit too fast. Looks like you want to hide the hand as well. I'm not sure if there's an easy way, but tracing the code through from EntityRenderer.renderHand gives me a couple of ideas you might try. No guarantee either of them will work... (1) turn off the GUI this.mc.gameSettings.hideGU and draw the overlays yourself (2) Replace the RenderPlayer class with your own overridden version that does nothing in .renderFirstPersonArm. Overrwrite RenderManager.entityRenderMap(EntityPlayer, RenderPlayer) to (EntityPlayer, MyRenderPlayer) If you decide to give it a try, let me know if it works!! -TGG

Hi This is a start. It wasn't terribly clear to me at first, but might be of some help to you. The key thing about DataWatchers is that the Server code automatically sends them to all nearby Clients whenever they change, so you don't need to worry about that. Just change them on the Server side, and read them on the Client side. http://www.minecraftforge.net/wiki/Datawatcher Cheers TGG

Hi I had the same problem. Very frustrating. I solved it like this http://www.minecraftforge.net/forum/index.php/topic,11963.msg62174.html#msg62174 Cheers TGG

Hi These links might also help http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-standard-blocks-cubes.html http://wuppy29.blogspot.com.au/2013/05/modding-151-sided-textures.html Cheers TGG

Hi These links might help. http://greyminecraftcoder.blogspot.com.au/2013/08/rendering-items.html http://greyminecraftcoder.blogspot.com.au/2013/08/rendering-first-person-view-items.html http://greyminecraftcoder.blogspot.com.au/2013/09/sample-code-for-rendering-items.html Cheers Mythor

Hi I am just guessing because I have never tried this, but it might give you a couple of clues to try: - I suspect that alpha blending might sometimes be turned off for rendering entities. You might need to write a custom renderer for your entity and turn the alpha blending back on GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA); GL11.glEnable(GL11.GL_BLEND); - see EntityRenderer.renderWorld() about halfway through. -TGG

Odd. Are you sure your textures are right? And that your getIcon is actually being called? Perhaps you could try swapping the texture names in your code and seeing if it changes to opaque. ie change to public static final String[][] field_94396_b = new String[][] { { Reference.MOD_ID + ":" + "tealleafopaque" }, { Reference.MOD_ID + ":" + "tealleaf" } } You might also be better off to simplify your Icon selection since you don't need arrays - might be easier to debug; eg private Icon opaqueLeaves; private Icon transparentLeaves; @Override public Icon getIcon(int par1, int par2) { if (iconType == 0) return opaqueLeaves; return transparentLeaves; } @Override public void registerIcons(IconRegister register) { opaqueLeaves = register.registerIcon(Reference.MOD_ID + ":" + "tealleafopaque"); transparentLeaves = register.registerIcon(Reference.MOD_ID + ":" + "tealleaf"); } } } Otherwise, I'm out of ideas... -TGG

Hi Your crash log suggests to me that the server is trying to invoke a NetworkModHandler which hasn't been defined (is NULL) for your custom entity. Normally Forge provides a default one for your entities automatically, I think. FMLNetworkHandler.getEntitySpawningPacket is the place where it retrieves the appropriate NetworkModHandler. After that I get lost... but I suspect it's something to do with your entity being registered differently on the client and the server. The crash occurs when the server tries to create a packet to tell the clients about the new entity. It's nothing to do with the rendering code. Not much help, sorry! I'm still learning this myself. -TGG

Hi What are the symptoms of the problem? Have you tried putting a breakpoint in getIcon and seeing if the correct icon is being returned when you change the fancy graphics? As far as I can tell, overriding getIcon should work fine. You could perhaps simplify the code a bit by registering the two Icons without using arrays, but it should still work ok. NB you should probably also override BlockLeavesBase.shouldSideBeRendered() to correctly handle internal faces between leaf blocks (see vanilla code). I also notice you haven't put @Override in front of the methods you are overriding? (Not essential, but can help pick up subtle problems). If you list the symptoms in a bit more detail, we might be able to help more? -TGG

Hi You might find this link useful, it shows the various coordinate transformations that Minecraft/Forge apply before calling your IItemRenderer, depending on the view. You'll notice that the zpos ("3") face often points in different directions from what you might expect. http://greyminecraftcoder.blogspot.com.au/2013/09/custom-item-rendering-using.html There's also another property for Items I didn't mention.. public boolean Item.shouldRotateAroundWhenRendering() /** * Returns true if this item should be rotated by 180 degrees around the Y axis when being held in an entities * hands. */ -TGG

Hi The error appears to be occurring in your ModelPowerBeam constructor, so have you tried stripping the constructor down to something very simple (or even empty) and then adding the statements back in, one by one? Or setting a breakpoint in the constructor? Perhaps you have initialised one of the shapes in the wrong order? (BTW - in Java it would generally be considered best practice to call your variables shape1 not Shape1 etc). -TGG

Fair enough. Let us know how it works out? -TGG

Sorry I can't help you there, I use IntelliJ. But I'm sure there are some good docs on the web, this one looks promising for example: http://www.vogella.com/articles/EclipseDebugging/article.html Once you've learnt how to set breakpoints, inspect variables, and step through your code one line at a time, your programming life will be so much easier, trust me :-) - TGG

Hi So which variable is NULL? (when you trace through with the debugger, you should be able to tell which object is NULL before it gets a method invoked on it?) I'm pretty sure the x,y,z is just there so that your GUI knows where the player is in the world, in case your code needs to know. I'm also pretty sure it's not the cause of your problem. -TGG

Hi Not so sure about the setHardness method. It would probably work but modifying vanilla blocks doesn't sound like a very robust solution. Apart from anything else, you would have to store the block hardnesses and return them to the original values which might be difficult to get right. I'd suggest the custom packet method. There are a few tutorials around and it looks like it should be pretty straightforward. And robust. eg http://www.minecraftforge.net/wiki/Packet_Handling -TGG

Hi Actually you might not be aware that torches already emit coloured light? It is slightly yellowish... http://greyminecraftcoder.blogspot.com/2013/08/lighting.html has a bit more information. There are a couple of ways I can think of that you might do this. Might be worth a try, but no guarantees... If you don't mind making all torches coloured (including the vanilla torch) you could overwrite the lightmap with your own values before the render. I think there is a forge hook somewhere that is called immediately before rendering (forget what it is though). Alternatively you could use the "coloured air block" idea- the simplest way might be TileEntities which is probably fine so long as you don't have too many of your coloured torches. But you could also do it with a custom air block: 1) Collision and bounding box can be turned off by Block.canCollideCheck() or Block.getCollisionBoundingBoxFromPool 2) Write a custom renderer for your "coloured air block"- either render it in pass1 with a low opacity (render the internal faces not the external), or render the internal faces of the cube by copying the texture from the adjacent block and re-rendering it with a colour multiplier The only problem is that some of these might look a bit strange next to non-cube blocks. The BlockRedstoneWire has some similarities to what you're trying to do. Good luck with it.... TGG

When I traced through the NetServerHandler code which handles Packet202 (created by .sendPlayerAbilities), I found this public Packet202PlayerAbilities(PlayerCapabilities par1PlayerCapabilities) { this.setDisableDamage(par1PlayerCapabilities.disableDamage); this.setFlying(par1PlayerCapabilities.isFlying); this.setAllowFlying(par1PlayerCapabilities.allowFlying); this.setCreativeMode(par1PlayerCapabilities.isCreativeMode); this.setFlySpeed(par1PlayerCapabilities.getFlySpeed()); this.setWalkSpeed(par1PlayerCapabilities.getWalkSpeed()); } i.e. PlayerCapabilities.allowEdit is ignored by Packet202. Which suggests a couple of workarounds... either cancel the event like Lycanus suggests, or write your own custom packet handler which copies allowedit as well as getFlying -TGG

Hi In general - if you want to change a specific block's texture at [x,y,z] this can be done in a couple of ways I can think of off the top of my head i) by changing the block metadata (you will have 16 values to choose from), and overriding the rendering methods to choose the appropriate texture based on the metadata - a number of the vanilla blocks do this, for example BlockWood. ii) by placing a TileEntity at the specific location, and changing the rendering code (see registerTileEntity for a starting point) In your case- as Draco18s said, look at the other thread for details, the easiest way is to add some custom code to the getBlockTexture method for your block. -TGG

I think these links might help. http://greyminecraftcoder.blogspot.com.au/2013/08/rendering-inventory-items.html http://greyminecraftcoder.blogspot.com.au/2013/09/custom-item-rendering-using.html http://greyminecraftcoder.blogspot.com.au/2013/09/sample-code-for-rendering-items.html Perhaps this post too: http://www.minecraftforge.net/forum/index.php?topic=11963.0 -TGG

Hi I had the same problem I think. If your Item's custom renderer uses an icon from the block texture map, make sure that Item.getSpriteNumber() returns 0, otherwise the tessellator will render using the item texture map, i.e. the wrong icons will be used. -TGG

Hi Look in ItemStack.damageItem() --->EntityPlayer.destroyCurrentEquippedItem --> this.inventory.setInventorySlotContents(this.inventory.currentItem, (ItemStack)null); I think this might be what you are after? -TGG

Hi The code for handling left & right mouse clicks is in Minecraft.tick() --> Minecraft.clickMouse(int button) A left click goes to EntityLivingBase.swingItem --> item.onEntitySwing(), so you can probably intercept it here, however the code continues on to do all sorts of other left-click things and you might have trouble stopping it - perhaps overwriting Minecraft.objectMouseOver might do the trick. Depends what you want to do exactly. -TGG

That is very odd because as far as I know the save files don't store any object references. Could you show us the error log? Might give some clues. -TGG