TheGreyGhost

Hi Looks like your this.worldObj.canBlockSeeTheSky(i, j, k) and && footprint.canPlaceBlockAt(this.worldObj, i, j, k)) { are not giving the expected results. Based on this code from BlockGrass for spreading grass to adjacent dirt I think dirt blocks can't see the sky, you should test for dirt at [i,j,k] and see sky at [i,j+1,k] if (p_149674_1_.getBlock(i1, j1, k1) == Blocks.dirt && p_149674_1_.getBlockMetadata(i1, j1, k1) == 0 // dirt not podzol && p_149674_1_.getBlockLightValue(i1, j1 + 1, k1) >= 4 && p_149674_1_.getBlockLightOpacity(i1, j1 + 1, k1) <= 2) { p_149674_1_.setBlock(i1, j1, k1, Blocks.grass); } >The previous post showed the coordinates of the dirt block where the entity is standing at I meant, if you click F3, and point at the block the entity was standing on, what are its coordinates? That's the point of the System.out.println, to check that your [i,j,k] actually returns the block you need rather than (say) a block buried one deep below the surface. But it doesn't matter now. -TGG

Hi Since renderTileEntityAt isn't printed to the console it means that your render function is never called, so probably you haven't registered your table properly (although it looks ok to me.) Try creating a flat world, putting your TileEntity down, then placing a breakpoint in these two places below, then trace through the code. That will tell you if the TileEntity is being detected, whether the renderer is being found (and if not - why not). RenderGlobal. this.theWorld.theProfiler.endStartSection("blockentities"); RenderHelper.enableStandardItemLighting(); for (i = 0; i < this.tileEntities.size(); ++i) { TileEntity tile = (TileEntity)this.tileEntities.get(i); // BREAKPOINT HERE if (tile.shouldRenderInPass(pass) && p_147589_2_.isBoundingBoxInFrustum(tile.getRenderBoundingBox())) { TileEntityRendererDispatcher.instance.renderTileEntity(tile, p_147589_3_); } } TileEntityRendererDispatcher.renderTileEntityAt() /** * Render this TileEntity at a given set of coordinates */ public void renderTileEntityAt(TileEntity p_147549_1_, double p_147549_2_, double p_147549_4_, double p_147549_6_, float p_147549_8_) { TileEntitySpecialRenderer tileentityspecialrenderer = this.getSpecialRenderer(p_147549_1_); // BREAKPOINT here if (tileentityspecialrenderer != null) { try { tileentityspecialrenderer.renderTileEntityAt(p_147549_1_, p_147549_2_, p_147549_4_, p_147549_6_, p_147549_8_); } -TGG

Unfortunately I think you've got a pretty accurate idea of what it's like. At every major release, and many minor releases, a whole lot of changes occur which often break large parts of your code which then needs significant rewrites. It's not a trivial exercise to update them, and it takes a long time (~ 4 months) before the deobfuscation is reasonably complete and a new version of Forge is available). Then you've got a few weeks of fun to get your mod to recompile, change your methods (and sometimes entire algorithms), test, and re-release. The landscape is littered with good mods whose authors just got burned out by the grind. You can insulate yourself a reasonable amount by relying on the Forge methods as much as you can (Events for example) because these tend to be more stable. Personally, I try to encapsulate my code as much as possible and reduce its interaction with vanilla (and Forge) objects as much as possible. This has a few benefits- 1) Changes to Vanilla or Forge tend to break only small parts of the code and it's much easier to code an adapter if necessary 2) It's much easier to write test code to perform automated testing of your classes, i.e. to discover what has been broken by the update and to test your fixes. The lack of documentation (and the large amounts of misleading or outdated information) are initially a problem but after a few months you'll get used to it and won't really need it much anymore. You should start with 1.7.10 I think. -TGG

Hi 1) You forgot to add the second println statement System.out.println(" " + l + " -->[" + i + ", " + j + ", " + k + "]: " + this.worldObj.getBlock(i, j, k).getUnlocalizedName() + " seeSky:" + this.worldObj.canBlockSeeTheSky(i, j, k) + " placeAt: + Blocks.grass.canPlaceBlockAt(this.worldObj, i, j, k); 2) Please tell us the coordinates of the dirt block that you're standing on when you do it 3) "The offset code didn't do anything" OK. Don't worry about that now. Add the second println and post again? -TGG

Hi I'd suggest that you do a two-step collision process 1) Have a cuboid collision box exactly like the normal entity, that encloses the entire entity parts 2) When the entity is hit, do a more detailed check on each body part to see if any / which one is hit. One thing though; Minecraft isn't designed for this kind of multiplayer FPS, no lag compensation or motion prediction etc, so you might be disappointed with the results when your target is moving around because it will often look like a crit when there isn't one, and vica versa, due to the game and network lag. -TGG

Hi Try adding these println, and show us what the console output is? Also, please tell us the coordinates of the dirt block that you're standing on when you do it. public void onLivingUpdate() { super.onLivingUpdate(); System.out.println("Grass: [" + this.posX + ", " + this.posY + ", " + this.posZ"] "; for (int l = 0; l < 4; ++l) { int i = MathHelper.floor_double(this.posX + (double)((float)(l % 2 * 2 - 1) * 0.25F)); int j = MathHelper.floor_double(this.posY); int k = MathHelper.floor_double(this.posZ + (double)((float)(l / 2 % 2 * 2 - 1) * 0.25F)); System.out.println(" " + l + " -->[" + i + ", " + j + ", " + k + "]: " + this.worldObj.getBlock(i, j, k).getUnlocalizedName() + " seeSky:" + this.worldObj.canBlockSeeTheSky(i, j, k) + " placeAt: + Blocks.grass.canPlaceBlockAt(this.worldObj, i, j, k); I suspect the difference is because snow is placed on top of dirt, but grass replaces dirt. Your entity y coordinate might not be what you think it is. It needs to be below your feet, as one of the other posters already said. Also a suggestion - this is very hard to understand when reading the code (float)(l % 2 * 2 - 1) * 0.25F) perhaps it would be clearer if you used two for loops instead of your modulus trick, the equivalent code is for (int xOffset =0; xOffset <= 1; ++xOffset) { for (int zOffset = 0; zOffset <= 1; ++zOffset) { } } I suspect you probably actually want for (int xOffset = -1; xOffset <= 1; ++xOffset) { for (int zOffset = -1; zOffset <= 1; ++zOffset) { } } -TGG

Hi "Copying" a vanilla texture is easy. Just look at the vanilla block and use the same texture name for your own block. If you want to use it on a non-block (say - a tileentity or an entity), you can Bind the block texture sheet, this.mc.getTextureManager().bindTexture(TextureMap.locationBlocksTexture); Retrieve the vanilla block's IIcon eg Blocks.wool getIcon Retrieve the texture coordinates from the IIcon get U and get V methods, then Render the face using the tessellator http://greyminecraftcoder.blogspot.com.au/2013/08/the-tessellator.html Re 1.8: http://www.minecraftforge.net/forum/index.php/topic,24376.0.html -TGG

Hi Unfortunately the list doesn't exist. There are some partial lists, mostly out of date. You can browse through the forgeSrc packages; some of it is well documented, some of it isn't. The way I find usually works well is 1) think of something in vanilla that works similar to what I want (eg I want to make a tomato plant that grows like wheat) 2) find out where wheat is in the vanilla code. A full text search on the package usually gives good results. For blocks and items you can browse through the Blocks and Items classes to see a list. 3) go look at the vanilla code to see which methods it overrides and what the various methods do, if they call other classes. 4) write some test code based on the vanilla code, test it, swear a lot, look at some more vanilla code, tweak my code again, perhaps read the forum, keep trying until the test code works or it reaches 2am and it's time to go to sleep. My biggest hint is - take baby steps, don't try to do it all at once. Do something simple, test it till it works, then add a bit more code, test it till it works, etc. It's much quicker that way. -TGG

Hi Try a System.out.println("renderTileEntityAt: ["+ x + ", " + y + ", " + z + "]" ); here: @Override public void renderTileEntityAt(TileEntity tileentity, double x, double y, double z, float f) { System.out.println("renderTileEntityAt: ["+ x + ", " + y + ", " + z + "]" ); What do you see in the console output? -TGG

Dude! [Gosaints said]: > "The object net.sciencecraft.machines.Grinder@7c1f7ea has been registered twice for the same name ScienceCraft:GrinderIdle" The error log says: > java.lang.IllegalStateException: Can't free registry slot 165 occupied by net.minecraft.item.ItemBlock@4f7b27a0 .... > at net.sciencecraft.main.ScienceCraft.Load(ScienceCraft.java:362) [scienceCraft.class:?] ScienceCraft line 362: 362: GameRegistry.registerBlock(GrinderIdle, "GrinderIdle"); Search code for "GrinderIdle" gives, like I said in my previous post, [TGG said]: 207: GameRegistry.registerBlock(GrinderIdle, "GrinderIdle"); -TGG

Hi Show the rest of the block class? Also, how are you rendering it? is it just an ordinary icon? how are you using the transparent field? -TGG

Hi When you render in a tile entity, the origin is at your eyes (yours, not the player's), and the dx,dy,dz in the renderAt method tells you where the tileentity is relative to your eyes. So for example, if your cube only has four sides: east (+x), west(-x), north (-z), south (+z), then you need to look at the relativex (dx) and relativez (dz) http://greyminecraftcoder.blogspot.com.au/2013/07/blocks.html The cube is 1 wide (x) by 1 deep (z) If we consider just the east/west faces: if dx > 0, then the cubeis to the east of our eyes, so we see the west face closest --> draw the west face last if dx < -1, then the cube is to the west of our eyes, so we see the east face closest --> draw the east face last if dx is between -1 and 0, then our eyes are between the two faces and they can't possibly overlap each other so it doesn't matter which one we draw last. They can't possibly overlap any of the other faces either so we can always draw them first. Similar logic for north/south (z) and up/down (dy). For a cube (or rectangular prism) it's pretty straightforward. If you're between two faces (eg -1 < dx < 0) then draw those first. Next, draw all the furthest-away faces Last, draw all the closest faces. Other shapes are harder and usually need maths calcs. -TGG

Hi Do you mean "System.out.println prints something, but the block is still invisible" or "System.out.println doesn't print anything, and block is still invisible" -TGG

Hi Like Brandon says, you probably have an infinite loop in that while statement if minX and maxX are equal. There are also a number of mistakes in the distance logic I think. What I suggest: 1) calculate the distance between the two particles using the square root formula for distance http://www.mathsisfun.com/algebra/distance-2-points.html 2) divide that distance by dbp (first check dbp is something reasonable (say) >= 0.1 ); this gives the number of particles to draw. Check it is reasonable (say < 100) 3) calculate the stepDeltaX = (finishX - startX) / number of particles. Repeat for stepDeltaY and stepDeltaZ 4) run a for loop from 1 to number of particles. Starting from x = startX, each loop calculate x += stepDeltaX. Do the same for stepDeltaY and stepDeltaZ. No chance of infinite loop that way, and it will handle all cases of start and end points properly. -TGG

Hi What is the issue? I.e. what are the symptoms? Could you show screenshot of what it looks like, compared with what it's supposed to look like? -TGG

No... Ah ok. GL11.glDisable(GL11.GL_DEPTH_TEST); makes your object draw on top of everything that has been drawn previously, i.e. it ignores the depth of everything that has already been drawn. GL11.glDepthMask(false); turns off writing to the depth buffer when you're drawing an object, so that anything you draw afterwards doesn't know the object is there and writes over the top of it, regardless of whether depth_test is true or not. -TGG

Hi >Now there is another problem. You can also see in the screenshot, that the inside of the pipe itself looks slightly strange, there are bits of the inside that are missing, and this is only from certain angles, the missing bits move when looked at from another angle. This is probably the same rendering-order problem again. When you render your TileEntity, draw the rearmost faces first, i.e. the face that is furthest from the player. As the player moves around the pipe, the "rearmost" face will change. This might be difficult with a model; you may need to split the model into the six flat faces. > the item renders fine, without any transparency issues, but is rendered behind the pipe That's because you have turned off writing to the depth buffer during rendering of the item (GL11.glDepthMask(false); ), so when you draw the model, it draws over the top of your item since the depth buffer doesn't know the item is there. Just to check - do you understand the difference between GL11.glDisable(GL11.GL_DEPTH_TEST); and GL11.glDepthMask(false); -TGG

Hi You might be interested in this class, it does pretty much exactly that. https://github.com/TheGreyGhost/SpeedyTools/blob/master/src/main/java/speedytools/serverside/worldmanipulation/WorldFragment.java There's a fair bit of stuff in there you don't need to worry about (it places asynchronously and also rotates/flips during placement) but writeToWorldAsynchronous_do() shows the key steps. -TGG

Hi Falling sand is an entity, not a block any more. You can rotate it, but Minecraft collision boxes always stay aligned to the x,y,z axes, so you would need to write your own collision detection code. Might as well stick with a TE to render the rotating parts and in its update tick perform your custom collision check on any nearby entities which have wandered into its range. -TGG

Hi if you used setupDecompWorkspace, they are there. Look under reference libraries, there is a library there called forgeSrc-{version info here} or something similar. Open that and you'll see the vanilla classes. Alternatively, you can search for classes by name in all libraries (ctrl N in IntelliJ, don't know in Eclipse) -TGG

Hi Teleportation to another dimension is a bit more complicated than that There are a couple of other topics on this forum lately that are talking about the same thing which might be of help. Alternatively you could dig through the portal code or the teleport player command for inspiration. -TGG

Hi I've sent you a PM -TGG

Ah, I think I might have confused you. When I wrote ^2 I meant 'squared', but that's not what the ^ operator does in Java. Try this instead squareDistance = (x-centre)*(x-centre) + (y-centre)*(y-centre) + (z-centre)*(z-centre); You've got a typo here which is probably causing your problem for(z = centre + radius -TGG

I used to think that, but I've been doing a lot with structure generation lately and found that with very simple code (just loop through an array and place bocks indicated) it can create perceptible lag on structures of any decent size. I actually changed my code to only do one layer per tick in order to improve this. I think a sphere the size he's showing could actually show a bit of lag. Generally though that won't be too noticeable if it happens during chunk generation because players are used to some lag from that, but if you generate the structure in response to player action (like using a tool), it can be noticeable. Anyway, I was surprised that it could lag, but I think the thing is that the volume of a structure gets large very fast -- a sphere as large as shown in the OP's picture has 5000 blocks! And I think the block placement requires fair bit of processing as well as client server sync notification. Just giving my observation... Hi Jabelar I agree with you, it will take a long time to place that many blocks. I'm just about to release a mod that copies up to 256x256x256 blocks and it can take up to a minute or more. What I meant was - I've seen other folks try to optimise out some of the "squareDistance" checks. That's a total waste of mental effort. -TGG

Hi I am extremely suspicious of this line } else if (tileMachine != null) { Where is tileMachine stored? I think you have a likely "all machines will face the same way" bug there. About your original question: > they default to the "blockIcon" IIcon, which I use as the back icon That's probably because your tileMachine is null and it drops through to your final statement. You need to handle the null case properly. Or better yet, fix the tileMachine bug, eg use meta instead. -TGG