TheGreyGhost

Hi The name of the despawn method is actually a bit misleading. It just checks for whether the entity needs to be despawned (i.e. because it's too far away from the player); usually it doesn't do anything. Try putting the breakpoint into setDead() instead, and posting us the stack trace from there. -TGG

Hi normal only works if the item lighting (opengl light sources) are on, and even then it can be hard to get right. I think the easiest way is just to change the color for different faces, i.e. for example .color(this.particleRed * faceGrey, this.particleGreen * faceGrey, this.particleBlue * faceGrey, this.particleAlpha).lightmap(j, k) where faceGrey = (say) 0.8 for north and south, 0.6 for east and west, 1.0 for up, 0.5 for down Some more info here http://greyminecraftcoder.blogspot.com.au/2014/12/lighting-18.html -TGG

Hi The lag between server and client isn't anything particular to worry about at this stage, I think. I think you need to figure out what's causing your entity to despawn in such a hurry. I can't tell what those obfuscated methods are (and MCPBot is not talking to me today, not sure why!), but in any case I would suggest you put a breakpoint in the server despawn instead. Or run your test in an integrated server from Eclipse (or IDEA) instead of a built version in dedicated server. -TGG

Hi I think the first place to start is to see if you can figure out why the entity despawns. Try adding System.out.println("XXX:side=" + (this.worldObj.isRemote ? "client" : "server")); to suitable places in your entity code (for example onUpdate(), setDead()). Or breakpoints. -TGG

Hi Are you sure that the direction property is being reloaded correctly? It sounds to me like you are not saving it properly, or it's being reloaded on the server but not transferred to the client. You can test this by putting a System.out.println into your render code. When you rotate an object, it rotates around the origin. If the origin isn't in the middle of the object, the object will move (translate) as well as change its orientation. So the steps are: translate the object so its desired centre of rotation is at the origin (normally for items, this is already in the centre). Then rotate it. Then translate it back to its origin position again. This will change the orientation of the object without translating it. You can then translate it to the desired position. The trick is - with OpenGL sometimes you have to do it in reverse order, depending on the setup. So try doing your translate calls before the rotate calls. The same player.posX trick works well for getting the translate right as well, being able to vary it interactively really helps understand what the code is doing. -TGG

Hi You might find this working example useful https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe11_item_variants -TGG

Hi Lambda In order to help you, we really need a more detailed description of the problems you're having ie. What you expect to happen vs What actually happens (detailed symptoms, error logs, etc). -TGG

Hi It looks like you're on the right track, you just need to figure out the correct rotations of the sword so that it points down? A technique I've found useful for this is to link the rotation to something in-game. For example GlStateManager.rotate(angle, 0, 0, 1); where angle = (player.posX % 7.2) * 360.0/72.0 and System.out.println("angle:"+angle); Then I look at the sword and strafe the player left<-->right until the appearance is correct. Works well with player position, and also the stackcount of items placed in each slot of your inventory bar (eg a stack of 32 stone in the leftmost inventory slot). -TGG

Hi I think you mean - return a new ItemStack with a damage value of 1 less than the itemStack's damage value? You'll also need to make the recipe so that it ignores the damage of your item. See here for more information https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe35_recipes/StartupCommon.java example © and http://greyminecraftcoder.blogspot.com/2015/02/recipes.html -TGG

Hi Try Rebuild All on your project. -TGG

Hi I find that drawing a diagram helps me a lot. Sometime I've resorted to lego, placed on a piece of graph paper with the x and z axes marked on it. Then I physically rotate the lego and see what the new coordinates are. By the way your AABB_NORTH seems wrong; 1+2*F is bigger than 1 which isn't allowed. -TGG

Hi If you want the line of blocks to spread itself slowly, you could use BLock.updateTick() with worldIn.scheduleUpdate(); Look in BlockFire.updateTick() for more clues - the fire spreads itself in a very similar way to what you want. -TGG

Hi What I have successfully used before: In your TileEntity.update(), read the value of the blockstate, then store it in the TileEntity eg IBlockState iblockstate = this.worldObj.getBlockState(pos); In the TESR.renderTileEntityAt, retrieve the stored blockstate from the TileEntity. -TGG

Hi Well this would be the second (third?) time that Mojang have changed "eye height" (relative to entity position) on the server and/or the client, so I think your guess is as good as mine -TGG

Hi Have you done the genIntelliJRuns task? IntelliJ debug works great for me. If you can't get it to work, perhaps show some screenshots of what you've tried and how it didn't work? -TGG

Hi This line in the crash report tells you exactly where to start looking for the error: If you're looking at that line and it's not obvious what's causing it, you can use your debugger to set a breakpoint at that line, and inspect the variables. You can also use a breakpoint on ArithmeticException, i.e. when ArithmeticException is about to be thrown, the program execution stops and lets you look at what's happening. http://www.vogella.com/tutorials/EclipseDebugging/article.html or https://www.jetbrains.com/idea/webhelp/debugging.html and -TGG

Hmmm I'm not so familiar with ForgeBlockStates, but at a guess: try replacing "textures": { "texture": "fe:blocks/anc_stone_brick_def" }, with "textures": { "all": "fe:blocks/anc_stone_brick_def" }, The method you're using should work; at least it worked for me with vanilla. Perhaps your model file isn't the one you think it is. i.e. { //"parent": "block/cube_all" <--whether this is here or not error persists "textures": { "all": "#texture" } } isn't being properly referred to by your blockstates? -TGG

Hi I suggest you go simpler still, take the registering out of the Block constructor, and just register it line by line in the Mod class methods, as per previous post In particular this makes me nervous- it might be fine, but looking at it I'm not so sure: public BlockBase(Material material, String name){ super(material); this.name = name; this.register(); } private void register(){ ItemUtil.registerBlock(this, this.getItemBlock(), this.getBaseName(), this.shouldAddCreative()); // this isn't constructed yet this.registerRendering(this.getItemBlock(), 0); } Calling methods and passing this, before the class is fully constructed, is always risky. And it also appears you might be trying to retrieve an ItemBlock before you have registered the block itself, which also could be bad news. I didn't understand what you mean here "- Block & Item(not ItemBlock) textures are registering - ItemBlock still 'unregistered' (default texture) " The Item is the ItemBlock, or not? Normally you have a Block, an ItemBlock, and that's it. -TGG

Hi No, I think the best place would be in the TileEntitySpecialRenderer (you are using a TileEntity to store the information about the Items, yeah?). When the TESR is called, you check to see whether the items is the same as the last time you rendered. If not, you draw the items to a FrameBuffer object, cache it for next time, and use it as a texture to render a quad inside your chest. MapItemRenderer can give you some clues (it creates a texture with code and then binds the texture before rendering the map), also this code for 1.8 which gives clues on how to render to a FrameBuffer and then use that as a texture for rendering: https://github.com/TheGreyGhost/SpeedyTools/blob/master/src/main/java/speedytools/clientside/selections/SelectionBlockTextures.java But I should warn you it's fairly heavy going, there are quite a few unusual concepts you'd have to master (if you haven't already) and troubleshooting is very painful because it's hard to tell whether your code is working or not (i.e. it either works perfectly, or you get a black texture with no other symptoms at all). -TGG

Hi when you say "not registering" I guess you mean that you get a purple-and-black chequered cube when you're holding the block, and when it's in the inventory? Does your itemblock look correct when it's placed in the world? My first comment is- I think your registration code is making your life difficult with the method calls and assembling the name strings from pieces - hard to spot things being missed or called out of order or names being wrong. I'd suggest you put the registration code directly into preInit and Init and use literal strings for the names, etc, and once that is working, move it back out /change it back one piece at a time till you figure out the problem. eg in your mod preInit: { // each instance of your block should have two names: // 1) a registry name that is used to uniquely identify this block. Should be unique within your mod. use lower case. // 2) an 'unlocalised name' that is used to retrieve the text name of your block in the player's language. For example- // the unlocalised name might be "water", which is printed on the user's screen as "Wasser" in German or // "aqua" in Italian. // // Multiple blocks can have the same unlocalised name - for example // +----RegistryName----+---UnlocalisedName----+ // | flowing_water + water | // | stationary_water + water | // +--------------------+----------------------+ // blockSimple = (BlockSimple)(new BlockSimple().setUnlocalizedName("mbe01_block_simple_unlocalised_name")); blockSimple.setRegistryName("mbe01_block_simple_registry_name"); GameRegistry.register(blockSimple); // We also need to create and register an ItemBlock for this block otherwise it won't appear in the inventory itemBlockSimple = new ItemBlock(blockSimple); itemBlockSimple.setRegistryName(blockSimple.getRegistryName()); GameRegistry.register(itemBlockSimple); } and then in your client preinit, which must be called after common preinit, ModelResourceLocation itemModelResourceLocation = new ModelResourceLocation("minecraftbyexample:mbe01_block_simple", "inventory"); final int DEFAULT_ITEM_SUBTYPE = 0; ModelLoader.setCustomModelResourceLocation(StartupCommon.itemBlockSimple, DEFAULT_ITEM_SUBTYPE, itemModelResourceLocation); -TGG

Hi I think the best way is to override the entity movement and collision code with your own so that the projectile passes through blocks without impact, and destroys the blocks as it goes. EntityFireball.onUpdate() is pretty close to what you want, I think; see also eg EntitySmallFireball.onImpact -TGG

Hi If you're happy with a 2D appearance for your items (i.e. no thickness) you can render the items to a frame buffer object, then use that as the texture for the inside of the cabinet. i.e. your cabinet has a single quad inside which uses the prerendered texture. That is much faster than rendering all the quads for the all the items, and you only need to update it once, when the items inside the cabinet change. Draco's idea might be plenty fast enough, try that first I think. -TGG

Hi I'd suggest you probably don't need AI for this. AI is great for complicated behaviours that an Entity might switch between, but probably overkill for a rock which just needs to float to where the player is. If you want to make it go around obstacles, you could consider 'cheating' by making a record of where the player has been for (say) the last 30 seconds and following that path, if there's something in the way of direct-line-of-sight You could look at EntityShulkerBullet for inspiration. Otherwise, if you're keen to explore AI, I'd suggest you try getting it to follow the owner along the ground like a wolf does, i.e. by using a vanilla AI task. Once that works, you can modify to follow through the air. Air should be a lot easier than ground because most of the terrain is not relevant. AI can be tricky to get right. It will help a lot to add statements that print to the console (or even better a screen overlay) so you can tell what's happening without having to pause the game. This mod has some good AI examples in it https://github.com/ata4/dragon-mounts/tree/master/src/main/java/info/ata4/minecraft/dragon/server/entity/ai -TGG

Hi Does the console show any missing texture errors or similar? -TGG

Hi This tutorial project has an example of something very similar to what you're describing https://github.com/TheGreyGhost/MinecraftByExample Try looking at mbe11 first, and if that doesn't meet your needs, try mbe15 Forge blockstates might also be suitable depending on exactly what you're trying to do. -TGG