TheGreyGhost

Hi You have pretty much two choices - (1) like Draco says, you can use the Block Render if you notifyBlockChange every time you want to re-render the block (i.e. because the NBT has changed). or (2) use a TESR, which is re-rendered every frame. If there are only a couple of different gauge positions, or they only change very slowly, then a Block Renderer would be fine. Otherwise, a TESR is probably better. -TGG

Hi I'm not sure I understand - if you have commented out the code in renderIventoryBlock, how were you expecting it to render in the inventory? Am I missing something? @Override public void renderInventoryBlock(Block block, int metadata, int modelID, RenderBlocks renderBlocks) { /** Tessellator tessellator = Tessellator.instance; GL11.glTranslatef(-0.5F, -0.5F, -0.5F); tessellator.startDrawingQuads(); renderBlocksOfAsphalt_Yellow_0(0, 0, 0, renderBlocks); tessellator.draw(); GL11.glTranslatef(0.5F, 0.5F, 0.5F); */ } You should be able to use more-or-less the same rendering code in your renderInventoryBlock as in your renderWorldBlock, except that you will have to supply the TileEntity information some other way, since the Block passed in doesn't have a valid one. Give it a shot and if you get an error, post it here and we can try to help more? -TGG

Hi. I think the WaveFront object file parser could be improved. For example the vertexPattern is given private static Pattern vertexPattern = Pattern.compile("(v( (\\-){0,1}\\d+\\.\\d+){3,4} *\\n)|(v( (\\-){0,1}\\d+\\.\\d+){3,4} *$)"); So it expects to find a vertex in the form v followed by three or four numbers made up of: an optional -, followed by digits, followed by ., followed by more digits. but some wavefront files don't match this pattern in some cases i.e. they don't have a decimal point v -1.5 0 1.5 Perhaps there is a better pattern based around eg v( ( (\\-){0,1}\\d+\\.\\d+ ) | ( (\\-){0,1}\\d+ ) ) {3,4} or similar? -TGG

Hi do you mean, there are different types of ore with different dusts, eg like birch tree becomes birch wood, or do you mean - you get a different type of ore every time you harvest the same block, eg you break the rainbow block and you randomly wind up with a red, an orange, or a yellow, etc dust. Block.getBlockDropped is your friend here. Just return a random ItemStack. -TGG

Hi Perhaps because you added two TargetTasks with priority 1? Re damage- just a random guess, make the 50 smaller? return par1Entity.attackEntityFrom(DamageSource.causeMobDamage(this), 50); I'm not sure why you haven't tried this already? -TGG

Hi THis link might be of use http://greyminecraftcoder.blogspot.com.au/2013/08/rendering-third-person-view-items.html .isFull3D() affects the item orientation as per the screenshots. -TGG

Hi It looks like a couple of methods in EntityPlayer might have been accidentally swapped The method that used to be called dropPlayerItem is now called dropPlayerItemWithRandomChoice. The method that used to be called dropPlayerItemWithRandomChoice is now obfuscated func_146097_a There is no method called dropPlayerItem. -TGG

Hi That's curious The code that used to be called dropPlayerItem is now called dropPlayerItemWithRandomChoice. And the code that used to be called dropPlayerItemWithRandomChoice is now obfuscated func_146097_a Probably best in the meantime to just call return ForgeHooks.onPlayerTossEvent(this, par1ItemStack, false); -TGG

Try some of these? http://blog.sherifmansour.com/?p=207 Reinstall forge....? -TGG

Hi Since you seem to know how to use ISimpleBlockRenderingHandler (true?), I would use that. @Override public void renderInventoryBlock(Block block, int metadata, int modelID, RenderBlocks renderer) { TileEntitySpecialRenderer tileentityspecialrenderer = this.getSpecialRendererForClass(TileEntityCrystal.class); if (tileentityspecialrenderer instanceof TileEntityCrystalRenderer) { // it should be, but doesn't hurt to make sure TileEntityCrystalRenderer tileEntityCrystalRenderer = (TileEntityCrystalRenderer)tileentityspecialrenderer; tileentityspecialrenderer.renderParticularModel(metadata, 0.0f, 0.0f, 0.0f, 1.0f); } } -TGG

Hi The ItemTooltipEvent might also be of some use. If you hook into it, you could use the Item as a key to search your "lore" descriptions for that Item. All your lore descriptions are then kept in a single class, you can add lore for vanilla items, and you can keep your Item classes completely separate if you want. -TGG

Hi I think it's been replaced by ItemCraftedEvent -TGG

Hi If you are using an IBSRH then it gives you the metadata in the parameter list public abstract void renderInventoryBlock(Block block, int metadata, int modelID, RenderBlocks renderer); If you're using a different Item renderer: An Item in your inventory is actually an ItemStack. An ItemStack has a "damage" value which is used instead of metadata (say - for coloured wool). So you use the ItemStack.getDisplayDamage() as your "metadata" A bit more info here http://greyminecraftcoder.blogspot.com.au/2013/12/items.html -TGG

Hi Looking at WavefrontObject, it uses the following regular expression to find vertices in the wavefront file private static Pattern vertexPattern = Pattern.compile("(v( (\\-){0,1}\\d+\\.\\d+){3,4} *\\n)|(v( (\\-){0,1}\\d+\\.\\d+){3,4} *$)"); http://www.tutorialspoint.com/java/java_regular_expressions.htm So it expects to find a vertex in the form v followed by three or four numbers made up of: an optional -, followed by digits, followed by ., followed by more digits. Yours clearly doesn't match this pattern v -1.5 0 1.5 i.e. it needs to be v -1.5 0.0 1.5 I can think of a few ways around it - (1) if your model doesn't have too many vertices you could find-replace with text editor (2) your cinema 4D might have an option to output in fixed decimal place format (3) you could move your model in cinema 4D ever so slightly (say - by 0.001) so that there are no integers in the output file. -TGG

Hi When you render in a TESR, the origin is set to the player's head and the function parameters provide the x,y,z offset to the actual position of the TileEntity. You need to translate before drawing the model. One way of doing this is public void renderTileEntityAt(TileEntity par1TileEntity, double dx, double dy, double dz, float partialTickTime) { GL11.glTranslatef((float)dx, (float)dy, (float)dz); // now render your model here You may need to tweak the translate slightly to put the model in exactly the right position. -TGG

Hi Yeah you can also use the inbuilt minecraft logging package (based on the standard Java Logger class), it's more flexible and for logging runtime errors in your permanent code it's great. Vanilla code is sprinkled with it. I just use System.out.println for temporary debugging stuff because it's what I'm used to, no other reason. -TGG

Dude, why does your item code need to call TileEntityRenderer.renderTileEntityAt at all? Why not just call an appropriate rendering method in your TileEntitySpecialRenderer? @Override public void renderTileEntityAt(TileEntity te, double x, double y, double z, float scale) { int blockmeta = te.getBlockMetadata(); renderParticularModel(blockmeta, x, y, z, scale); } public void renderParticularModel(int meta, double x, double y, double z, float scale) { this.model.meta = meta; GL11.glPushMatrix(); GL11.glTranslatef((float) x + 0.5F, (float) y + 1.5F, (float) z + 0.5F); ResourceLocation textures = (new ResourceLocation("mymod:textures/blocks/texture.png")); Minecraft.getMinecraft().renderEngine.bindTexture(textures); GL11.glPushMatrix(); GL11.glRotatef(180F, 0.0F, 0.0F, 1.0F); GL11.glEnable(GL11.GL_BLEND); this.model.render((Entity)null, 0.0F, 0.0F, -0.1F, 0.0F, 0.0F, 0.0625F); GL11.glDisable(GL11.GL_BLEND); GL11.glPopMatrix(); GL11.glPopMatrix(); } and in your Item renderer public void renderInventoryBlock(Block block, int metadata, int modelID, RenderBlocks renderer) { myTESR.renderParticularModel(XPOS, YPOS, ZPOS, metadata); } } (Haven't tried to compile this stub, but you get the idea I mean?) -TGG

Hi ResourceLocation is in package net.minecraft.util; no idea why you can't import it. -TGG

Hi From the command line: /debug start and when you're finished /debug stop When you stop it will save to a file in .\debug eg forge\mcp\jars\debug\profile-results-2014-01-28_00.21.46.txt It typically looks like this so if you leave it run for a minute or so at the start, then again for another minute when your server is getting really laggy, you might see an obvious difference in one of the sections. That might be enough of a clue to narrow it down. Of course, if your IDE supports profiling then that's probably even better... -TGG

Hi When it crashes, what does the error message say? Can you use your IDE Profiler to tell where the server is spending all of its time? The vanilla code is also sprinkled with a lot of debugging logfile statements, every time it (eg) starts a tick or updates or entity - if you look at the log you might get a clue from that, if certain parts are taking an increasingly long time. -TGG

Hi Integrated debuggers are awesome, once you know how to use them you'll never look back. Track exactly what your code is doing, look at the contents of variables, set a breakpoint to check whether your code is actually being called. Are you using Eclipse? Good introduction here... http://www.vogella.com/tutorials/EclipseDebugging/article.html -TGG

Hi I haven't looked at your code in detail, but a possible clue: The vanilla furnace changes its blockID to make itself active. But depending on how you change the blockID, it's not always visible, i.e. it might still look like the inactive furnace. As a general strategy I would suggest you add breakpoints or System.out.println to the appropriate parts of your code to help gather more symptoms and narrow down what's happening, eg is the code which makes the furnace go active actually being called? is the blockID actually being changed? does my active furnace look any different to the inactive furnace? etc -TGG

Hi Making progress step by step ... I am told that the forge wavefront parser is a bit picky about the formatting of the instructions in the file, and that it doesn't support all of the information that Blender might put in there. That's all I know. You could perhaps start a new thread about the specific error net.minecraftforge.client.model.ModelFormatException: Error parsing entry ('v -1.5 0 1.5', line 5) in file '/assets/dwadventures/OBJ/Tardis/Model11thDoctorTardis.obj' - Incorrect format You could also try asking on a Blender forum, they might have more clues. -TGG

Hi Like nearly all Blocks, gravel has a corresponding ItemBlock, it is automatically created in the static initialiser for Block. So like dieSieben says, if you use ItemStack you can pass in gravel. new ItemStack(theBlock.blockID, 1, theBlock.damageDropped(metadata)) (where metadata is for eg different colours of carpet) -TGG

Hi Is your renderInventoryBlock method still commented out? -TGG