TheGreyGhost

Ha ha that's funny Looks like a decompiler problem (the minimum value is almost, but not quite, zero - perhaps a roundoff error in the decompiler) --> anyway if that's in the Forge (Minecraft) code then it's a forge problem, I suggest submitting a bug report. -TGG

Hi Using GitHub is really easy, the site has some excellent tutorials and set-by-step instructions. The harder part is getting your git to synchronise the local repository with the remote (i.e. GitHub), it took me a while to figure it out. I did it using IntelliJ instead of Eclipse, so if Jabelar recommends SourceTree, I'd so go for that. -TGG

the Necromancer raises a zombie from the grave!

Hi Yeah ITickHandler is gone; replaced by Forge Events See here and http://www.wuppy29.com/minecraft/modding-tutorials/wuppys-minecraft-forge-modding-tutorials-for-1-7-events/#sthash.0vnz61rP.dpbs You want ClientTickEvent, which needs to be registered using FMLCommonHandler.instance().bus().register(); -TGG

Hi THis post might be useful http://www.minecraftforge.net/forum/index.php/topic,13727.msg70723.html#msg70723 It was for 1.6.4, not sure if it still works, but is worth a try. Basic idea is - intercept the movement keys by replace this.thePlayer.movementInput (class = MovementInputFromOptions) with your own class -TGG

Hi I'd suggest you set a breakpoint in your debugger to break on IllegalArgumentException, and see what the RangedAttribute is. That should narrow it down pretty quickly. Are you familiar with those? In case not- Eclipse http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fviews%2Fbreakpoints%2Fref-addexception_viewaction.htm IntelliJ http://www.jetbrains.com/idea/webhelp/creating-exception-breakpoints.html -TGG

Hi After spending a couple of hours using VisualVM to trace things through, it looks to me like the massive lag is caused by all the block and sky light recalculations that take place. Every time the lighting for a given block needs to be updated, it spends a long time cascading the changes to all nearby blocks. This becomes very costly very quickly. The reason it's so bad for your planetoid is because normally the world is almost all sky right down to the ground, then beneath the ground the blocks are usually solid and there are only a few caves open to the sky. In your case, your whole sky is effectively "underground" with lots of "caves" open to the sky, which means that the skylight has to propagate itself sideways from the columns which are directly underneath the sky. I think the best way to speed it up is to make sure that your chunk provider makes a good approximation for the initial skylight map. The default vanilla one you use, chunk.generateSkylightMap(); in PlanetoidChunkProvider.provideChunk() does a great job down to the top surface and it's rubbish underneath that. Based on your knowledge of where the Planetoids are placed, you can easily initialise the Skylight of the air underneath the planetoids based on a simple non-iterative formula in 2 dimensions instead of three (imagine looking down from the top - a circle which is bright at the edges, tapering to dark in the middle.) You can then generate vertical columns of skylight underneath the planetoid based on this circle, perhaps with tweaking for planetoids which overlap. I think that a good initial approximation will help a lot. You might be able to get it even better (eg the few layers of air underneath the sphere) if you let vanilla calculate the light map for a variety of planetoid sizes, then dump it to disk and make a lookup database of initial skylight against planetoid size. This is all guesswork since I haven't tried it myself, but I'm pretty confident that's the problem. I tested it by making all your planetoids spawn as glass blocks (which are transparent to skylight, so the initial skymap is good) and it was very fast. -TGG

Hi I suggest to put System.out.println("rendering"); into your renderTileEntityAt() If it prints nothing, you probably have a registration problem If it prints, you probably have a rendering problem. That will narrow it down a lot. -TGG

Are you sure about that? I'm pretty certain that display lists can include glBindTexture without a problem. @CosmicDan Have you tried executing tessellator.draw() as your first command, changing the texture sheet, drawing your icon, binding back to the block texture again, then executing Tessellator.instance.startDrawingQuads(); ? The problem with your rendering is that your item rendering is still using the block texture sheet because you haven't issued a tessellator.draw(), so your drawing commands don't get added to the display list until after you've changed texture sheet back again. i.e. start the render list change to block texture sheet start tessellator drawing draw some blocks with tessellator ----- change to icon sheet {issue campfire tessellator commands which don't get written to the render list immediately} change back to block texture sheet ----- draw some more blocks with tessellator tessellator.draw() {which writes all the draw commands to the render list} So the openGL render list winds up looking like start list----------- change to block sheet change to icon sheet change to block sheet draw blocks draw campfire draw more blocks end list------- The size of the block and icon textures sheets isn't the same, but your texture coordinates are all in decimals, so using the texture coordinates for icons with the texture sheet for blocks leads to icons which are shrunken down. Having said all that I agree that a TileEntityRenderer should work fine given that you aren't going to have entire landscapes made of campfires. A couple of links on rendering you might find interesting.. http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-world-more-details-including.html http://greyminecraftcoder.blogspot.com.au/2013/08/the-tessellator.html -TGG

Hi Leaves decay when updateTick is called. UpdateTick is called pseudo-randomly in WorldServer.tickBlocksAndAmbience under the "tickTiles" section. If you added your own Server Tick, and then perform your own random ticking in the same way (checking to see if the block is a leaf block before calling it) this will speed up the decay. -TGG

No worries, you're welcome

I wonder if you have done something wrong with the entity AI. When you have paused it, if you step out of the methods one at a time, does it eventually go all the way back out to WorldServer.updateEntities? If not, what method is it stuck in? -TGG

Hi OK I understand now. If you want to find the 16 x 16 blocks in a chunk, you can calculate it from the player x,z position using code something like this minWX = playerXpos & ~0x0f; // throws away the bottom four bits, i.e. truncates to the next lowest multiple of 16, eg 32, 16, 0, -16, -32 etc minWZ = playerZpos & ~0x0f; maxWX = minWX + 15; maxWZ = minWZ + 15; for (wx = minWX; wx <= maxWX; ++wx) { for (wz = minWZ; wz <= mazWZ; ++wz) { // setblock (wx, playerYpos - 1, wz) -TGG

Hi Show your latest code? I am surprised that the code I put in my last post doesn't work. -TGG

Hi Try splitting this line into several so you can see exactly which one is null GameRegistry.addRecipe(new ItemStack(halotech.AdvancedPlateBender, 1), "zaz","yxy","zbz", 'y', Items.getItem("iridiumPlate"), 'z', OreDictionary.getOres("gearElectrum"), 'x', OreDictionary.getOres("bender"), 'a', Items.getItem("lapotronCrystal"), 'b', OreDictionary.getOres("circuitElite")); eg ItemStack apb = new ItemStack(halotech.AdvancedPlateBender, 1); System.out.println("apb:" + apb); Item iridiumPlate = Items.getItem("iridiumPlate"); // ..etc.. You might find that one of them is null, for example if you have misspelled the name. -TGG

Hi I don't really understand what you mean "set blocks in a chunk based on the user's Y level". And why do you need to access the chunk directly, why not just use the world instead? -TGG

Hi Hmmm Thread [server thread] (Suspended) WorldServer(World).selectEntitiesWithinAABB(Class, AxisAlignedBB, IEntitySelector) line: 3489 WorldServer(World).getEntitiesWithinAABB(Class, AxisAlignedBB) line: 3476 WorldServer(World).findNearestEntityWithinAABB(Class, AxisAlignedBB, Entity) line: 3503 EntityAIWatchClosest.shouldExecute() line: 59 // ... etc // EntityGlitch(EntityLivingBase).onLivingUpdate() line: 1993 EntityGlitch(EntityLiving).onLivingUpdate() line: 431 EntityGlitch(EntityMob).onLivingUpdate() line: 39 EntityGlitch.onLivingUpdate() line: 177 EntityGlitch(EntityLivingBase).onUpdate() line: 1826 EntityGlitch(EntityLiving).onUpdate() line: 250 EntityGlitch(EntityMob).onUpdate() line: 47 The fact that it paused in a method related to your Entity makes me suspicious. If you pause it several times, is it always in your onUpdate()? -TGG

Hi I think that TileEntities only get put onto that list if they need updating i.e. the world needs to call tileEntity.updateEntity(). I don't think there is a client-side list for all tileEntities including those that don't need updating. Are these your own TIleEntities you're looking for? Or do you need to find vanilla as well? -TGG

Hi If the server is stuck in an infinite loop, use your debugger to pause execution and look at the stack frames (i.e. the method it is currently in on the server thread) to see what it is doing-? -TGG

Hi Try wrapping your rendering code in this GL11.glPushAttrib(GL11.GL_ENABLE_BIT); // render here GL11.glPopAttrib(); This will save & restore the state of most of the lighting settings. If that doesn't work, you could try putting RenderHelper.enableStandardItemLighting(); after your render (not before) -TGG

Hi This is a useful link for events Show your code? -TGG

Hi The slot might be empty. If it is, the stack will be null. If you call .getItem() on a null, you will get this crash. This link might be helpful http://www.terryanderson.ca/debugging/run.html -TGG

Hi I'm having trouble following the formatting in your mod class so I'm not sure whether your initialisation is happening in a static initialiser. But anyway it shouldn't. This is not right, it should be FMLPreInitializationEvent for the preinit. @EventHandler public void prinit(FMLInitializationEvent event) { You need to split your initialisation up into FMLPreInitializationEvent: Register all your blocks FMLInitializationEvent: Register your recipes Currently your code doesn't do that, which I think is why it doesn't work. I reckon the crash is almost certainly caused by your halotech.AdvancedPlateBender not being initialised before you add the Recipe. -TGG

Hi Are you sure those two blocks are registered with the GameRegistry before the generation starts? -TGG

Hi Looks like a same problem i.e. Blocks.blocksList is null public Material getBlockMaterial(int par1, int par2, int par3) { int l = this.getBlockId(par1, par2, par3); return l == 0 ? Material.air : Block.blocksList[l].blockMaterial; } I seem to remember something that world generation must not use blocks with an ID >= 256, perhaps it is related to that (I'm really not sure). Do you know how to use breakpoints in your debugger? You could add a breakpoint on Null Pointer Exception, and when it pauses at that line, inspect which block it is trying to access. That will probably give useful clues. -TGG