TheGreyGhost

Hi Unfortunately I think the answer is almost certainly "no". But you could copy the Ender Dragon to a set of new classes and change the textures to whatever you want. Won't be easy, the dragon is complicated. -TGG

Hi Well I found it The culprit is not in your code at all. It's here in EntityTrackerEntry: public void sendLocationToAllClients(List par1List) { // ...etc ... if (this.ticks > 0 || this.myEntity instanceof EntityArrow) // this line here { if (j1 >= -128 && j1 < 128 && k1 >= -128 && k1 < 128 && l1 >= -128 && l1 < 128 && this.ticksSinceLastForcedTeleport <= 400 && !this.ridingEntity) { if (flag && flag1) { object = new Packet33RelEntityMoveLook(this.myEntity.entityId, (byte)j1, (byte)k1, (byte)l1, (byte)l, (byte)i1); } else if (flag) { object = new Packet31RelEntityMove(this.myEntity.entityId, (byte)j1, (byte)k1, (byte)l1); } else if (flag1) { object = new Packet32EntityLook(this.myEntity.entityId, (byte)l, (byte)i1); } } else { this.ticksSinceLastForcedTeleport = 0; object = new Packet34EntityTeleport(this.myEntity.entityId, i, j, k, (byte)l, (byte)i1); } } // etc This controls when the server sends position updates to the client. In order to save packet size, it usually sends the change in position (eg "increase x by 2"), not the actual position ("set x = 53.4"). this.ticks is the length of time that this tracker has been tracking the entity. The server normally doesn't send a position update for the entity unless it has had at least one tick (this.ticks > 0). But for some reason, EntityArrow is designed differently. It must send a position update even on the first tick. If it doesn't, the first position change is lost and from then on the position is wrong on the client, which is what you're seeing. So rather than fix the problem properly, the code author introduced a "dirty" fix ("kludge") to solve the symptoms, i.e. the check for instance of EntityArrow. If I change that line to if (this.ticks > 0 || this.myEntity instanceof EntityArrow || this.myEntity instanceof EntityWoodArrow) // this line here then the problem disappears. A more practical solution for you is to make sure you define your EntityWoodArrow as class EntityWoodArrow extends EntityArrow. -TGG

Hi I see two ways forward then- (1) If you create a custom button, when you push the button, your code can follow the redstone trail to the corresponding block and checks its power level. (2) if you just want the block to change its appearance based on its power level, that's relatively easy: (a) if your block has less than 17 power levels, you can save your power level in the metadata and override the Block.getIcon method to change its appearance based on the metadata. This might or might not work depending on whether you need to change the power level depending on what happens to other blocks nearby. (b) if your block needs more than 17 power levels or it depends on other blocks which are not right next to it, you will probably need to implement a TileEntity and TileEntitySpecialRenderer. This link has a number of pages which talk about some of the concepts, in case I'm using jargon you haven't heard of yet. There are also a number of tutorials around the web and minecraft forge site on each of these things. http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html (see especially http://greyminecraftcoder.blogspot.com/2013/10/the-most-important-minecraft-classes_9.html http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-standard-blocks-cubes.html) ) -TGG

Hi In that case, your BlockDetector will need to find a way to tell who pushed the button. That isn't easy because the propagation of a redstone signal can be very complicated and it doesn't keep track of who initially started the signal. And in some cases, nobody started the signal (eg light detector, or a mob). Why do you want to use a BlockDetector to send a message to the person who pushes the button? It might be better to make your own button that sends a chat message directly, instead of trying to link the button to your BlockDetector using redstone? -TGG

Hi I think it might be clearer if you could give a concrete example of what you want. For example (1) "James" places the BlockDetector. He wires it up to a button 10 blocks away using redstone. (2) "Peter" pushes the button. (3) A chat message "Signal Detected" gets sent to "James". If that's what you want to do, it's pretty easy. Store the name of the player who placed the block in a corresponding TileEntity. If instead you want the chat message to go to "Peter", then you've got more of a challenge. Not impossible but I'd be suggesting that you think of a different way to achieve what you want from a gameplay perspective. -TGG

Hi Random guess - do your particles have an appropriate onUpdate method, and if so have you tested whether it's being called? See for example EntitySpellParticleFX.onUpdate -TGG

Hi There's a few things here about custom rendering that might help (see the Block Rendering sections) http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html Are you rendering in pass 0 or pass 1? From looking at your code I don't see an obvious problem A couple of suggestions to try - * you could try rendering in pass 1 - all faces are double-sided in pass 1 unlike pass 0 - so you only need to render one * you could try turning off cull face GL11.glDisable(GL11.GL_CULL_FACE); (don't forget to reenable after) GL11.glEnable(GL11.GL_CULL_FACE); * you could try moving the two faces slightly apart tessellator.addTranslation(f19, 0.0F,0.0F); r.renderFaceXNeg(block, (double)x, (double)y, (double)z, r.getBlockIcon(block, r.blockAccess, x, y, z, 0)); tessellator.addTranslation(0.001F, 0.0F, 0.0F); r.renderFaceXPos(block, (double)x, (double)y, (double)z, r.getBlockIcon(block, r.blockAccess, x, y, z, 0)); tessellator.addTranslation(-f19-0.001F, 0.0F,0.0F); -TGG

Hi The symptom you're seeing is generally caused by the lighting settings. I'm not sure why you're seeing this because your call to renderStandardBlocks immediately before the renderFaceYpos should have set the lighting up properly already. Some more info here (but it's pretty complicated and I'm not sure it will help to be honest) http://greyminecraftcoder.blogspot.com.au/2013/08/lighting.html It looks to me like you don't actually need to render the arrow separately from the asphalt block? Why not just draw the arrow and block as a single icon? see here http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-standard-blocks-cubes.html Just override getIcon to return the faces you want (with/without arrow, and pointing in correct direction). You'll need a custom renderer for your item like Enkey said. More information on item rendering here (see the "Items" section) http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html -TGG

Hi I've managed to download and compile your code and I can recreate the problem you're seeing. It's bedtime for me now but I will give it a crack tomorrow night. -TGG

Hi no worries, glad I could help. So if you want to start the animation when you right-click the block, you need to set the animationOffset so that the slider position is zero when you right click the block. in other words, time is zero long time = (System.currentTimeMillis() + animationOffset) % CYCLE_TIME_IN_MS; so in the right click you need to set your animationOffset equal to -System.currentTimeMillis(), so that System.currentTimeMillis() + animationOffset == 0. the initialisation in the constructor was just to provide a random starting point so the blocks are not all synchronised, there's nothing special about it. animationOffset = System.nanoTime() % 40000; Your onBlockActivated should have something like this in it: public boolean onBlockActivated(World par1World, int x, int y, int z, EntityPlayer par5EntityPlayer, int par6, float par7, float par8, float par9) { if (par1World.isRemote) { TileEntity tileEntity = par1World.getBlockTileEntity(x, y, z); if (tileEntity != null && tileEntity instanceof TileEntityExtractor) { ((TileEntityExtractor)tileEntity).animationOffset = - System.currentTimeMillis(); } } // etc } -TGG

Ah, my bad, the slide code is using integer arithmetic instead of float so it's rounding off the position. Try changing them to (time / (float)HALF_CYCLE_TIME_IN_MS) -TGG

nice one :-)

Hi I think there is a PlayerSleepInBedEvent which might help - that will at least tell you when the player has gone to bed so that you can heal him instantly. The server knows how many players are connected. To get all players on the server, use ServerConfigurationManager.playerEntityList() For all players in a particular dimension, use worldServer.playerEntities, where you get worldServer using MinecraftServer.getServer().worldServerForDimension or DimensionManager.getWorld() -TGG

Hi In that case, I think you're in luck. I'd suggest create your class BlockMyNewDoor extends BlockDoor add a constructor add icon member variables (copy the ones from BlockDoor) override public void registerIcons(IconRegister par1IconRegister) to register your new icons/textures into BlockMyNewDoor member variables (the BlockDoor ones are private unfortunately) and override public Icon getBlockTexture(IBlockAccess par1IBlockAccess, int par2, int par3, int par4, int par5) copy the code from BlockDoor.getBlockTexture into BlockMyNewDoor.getBlockTexture and change the references to the icon fields to your own icon texture member variables. The material is in the constructor so it's relatively easy - and if you want your stone door to act like a wooden door (i.e. players can open it) then you probably don't need to change onBlockActivated either. -TGG

Hi This link has a fair bit of info on how to render items and blocks. Plus some sample code. http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html See the Block Rendering and Item Rendering sections. -TGG

Hi What do you mean exactly by "destroyed"? Do you mean when World.onEntityRemoved is called (entity is unloaded / freed)? If so, I don't think there is any such hook. You could perhaps use ITickHandler to search the EntityTracker in WorldServer to see if your entity of interest has been removed. Depends what you want to do, really. -TGG

Hi Could you post a zip of all your code somewhere, or share it on GitHub? If so I'll download it and try it myself in the next day. You've got my Sherlock Holmes neurons quivering now :-) -TGG

Hi Why not just use the existing door? i.e. what do you want to do differently? Door is a bit complicated because it needs its own renderer and it's made up of two blocks not one. It's also got a pile of logic related to opening & closing, whether entities can pass through it or not, changes to the bounding box, etc. If you want to tweak something simple, like the sound it makes when it opens, then it's easy. Otherwise it's going to take a fair bit of skill and knowledge about the vanilla door and renderers in particular. -TGG

Hi The long value in the code I suggested is based on your pump animation code, which appeared to be designed to go through a full animation cycle once every 40 seconds using a value from 0 to 39999. Now that I look at it more closely I see that time isn't actually used at all. Guess I should have read it more thoroughly. As you've got it currently, the slider will move by a fixed amount every time pump is called, so if the framerate is uneven or you have multiple sliders it will be choppy public static void pump(){ if(slider1.offsetY > 0.0){ down = true; } if(slider1.offsetY < -0.5){ down = false; } long time = System.currentTimeMillis() % 40000L; if(down){ slider1.offsetY -= 0.01; } if(!down){ slider1.offsetY += 0.01; } slider2.offsetY = slider1.offsetY; } } If you want your slider position to animate like this: (1) start at slider position 0 (2) over 2 seconds, decrease evenly to -0.5 (3) over the next 2 seconds, increase evenly to 0 (4) repeat from 2 then something like this should work: public void pump(long animationOffset){ final long CYCLE_TIME_IN_MS = 2000; final long HALF_CYCLE_TIME_IN_MS = CYCLE_TIME_IN_MS / 2; final float START_SLIDER_POS = 0.0; final float MID_CYCLE_SLIDER_POS = -0.5; long time = (System.currentTimeMillis() + animationOffset) % CYCLE_TIME_IN_MS; if (time < HALF_CYCLE_TIME_IN_MS) { slider1.offsetY = START_SLIDER_POS + (time / HALF_CYCLE_TIME_IN_MS) * (MID_CYCLE_SLIDER_POS - START_SLIDER_POS); } else { time -= HALF_CYCLE_TIME_IN_MS; slider1.offsetY = MID_CYCLE_SLIDER_POS + (time / HALF_CYCLE_TIME_IN_MS) * (START_SLIDER_POS - MID_CYCLE_SLIDER_POS); } } -TGG

Hi Your code currently renders from [0,0,0] to [1,1,1] instead of from [x,y,z] to [x+1, y+1, z+1]. Did you try that [x,y,z] to [x+1, y+1, z+1] already? I think the tes.setTranslation(x, y, z) won't work because the caller has set the viewpoint and translation relative to the chunk coordinates, not relative to an origin of [0,0,0] -TGG

Hi Start from Packet3Chat and go from there- NetClientHandler.handleChat -> Forge event ClientChatReceivedEvent Have you heard of Forge events before? EntityClientPlayerMP.sendChatMessage to send the message. Can get EntityClientPlayerMP from Minecraft.getMinecraft().thePlayer -TGG

Hi I'd suggest something like - change your public static void pump(){ to be public void pump(long animationOffset) with long time = (System.currentTimeMillis() + animationOffset) % 40000L; add a field to your TileEntityExtractor long animationOffset; in the default constructor for your TileEntityExtractor add animationOffset = System.nanoTime % 40000; in your renderTileEntityAt add this.model.pump(te.animationOffset); this.model.render((Entity) null, 0.0F, 0.0F, -0.1F, 0.0F, 0.0F, 0.0625F); Disclaimer - I haven't tried to compile this code so bits of the syntax might not be 100% right -TGG

That smells very much like a client-server mismatch to me. The server periodically resynchronises the position of all entities to the client using Packet34EntityTeleport (every 20 seconds in fact) - EntityTrackerEntry.sendLocationToAllClients(). This part of the code in onUpdate should cause the arrow to stick in the block. if (axisalignedbb != null && axisalignedbb.isVecInside(this.worldObj.getWorldVec3Pool().getVecFromPool(this.posX, this.posY, this.posZ))) { this.inGround = true; } It's not clear to me why it's not working properly. Probably either the arrow is bouncing off for a frame or two before it stops moving, or your renderer is actually taking the arrow's position immediately before it hit the wall, but I can't see from the code which. You might gain some insight by adding System.out.println to various parts of the onUpdate code to see what's happening to the position every tick. -TGG

Hi I think Mazetar is probably right, your code is effectively calling itself in a loop. You could confirm this by adding a few more logging statements to your PlayBackgroundMusicEvent. Or a breakpoint. -TGG

Hi Some thoughts- What do you mean "bounding boxes" - i.e. which bounding boxes? just the ones that highlight when your mouse is over the block? or used for collisions as well? I'd suggest a general approach of using a single bounding box that encompasses all of the smaller bounding boxes, then if a "hit" is detected, perform more extensive checking to see if any of the smaller multiple bounding boxes is hit. You can change the block highlight code by tapping into DrawBlockHighlightEvent and drawing the highlights yourself (or none at all, if you want to remove them). Best way to change the boxes with a TileEntity is to store the information in the TileEntity itself (NBT data). This are reasonably advanced techniques by the way. Are you sure you really need multiple bounding boxes? -TGG