TheGreyGhost

Ha, well I'm not sure about the great coder stuff but thanks for the positive feedback anyhow, glad you found it easy to understand About the example - based on the order you're defining your slots you will have 0 = te slot 0 1 = te slot 1 2 = te slot 2 3 = te slot 3 defined with SlotCrypticInfuser 4 - 30 = player inventory slots 31 - 39 = player hotbar slots So: if slotNumber is 0 -3 (clicked on a furnace slot) , you should mergeItemStack(sourceStack, 4, 40, false) (i.e. into the player inv slots, or the hotbar if it's full) if slotNumber is 4 - 39 (clicked on a player inv or hotbar slot), you should mergeItemStack into 0, 1, 2, or 3 depending on where you want the item to transfer to. the .getSmeltingResult returns null if there's no recipe for that input. So just call your custom recipe class with the input to see if it produces an output. The logic is the same. -TGG

Hi Brandon and I have written a 'MinecraftByExample' project for 1.8, one of the examples is a custom furnace. It's a lot better documented than the vanilla code and the shift-click works exactly the same as 1.7. You could look at it here transferStackInSlot() ) for some clues. https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe31_inventory_furnace/ContainerInventoryFurnace.java The main thing is - you must be very careful to keep track of which slot is which, it is easy to mix up the slot numbers of your combined container (eg 0-38) with the slot numbers of the components (i.e. player inventory 0 - 35 and your tile entity 0 - 2) -TGG

Hi Yeah the 'issues' on GitHub is fine. Or you can also post to http://www.minecraftforge.net/forum/index.php/board,15.0.htm. Lex & collaborators see them either way. -TGG

Hi I saw a very similar bug a year ago. It was caused by some vanilla code which treats projectiles differently from others, by checking for instance of EntityArrow Perhaps yours is the same bug. Try changing your EntityModelArrow extends Entity to EntityModelArrow extends EntityArrow see here for more info http://www.minecraftforge.net/forum/index.php/topic,14315.msg73758.html#msg73758 -TGG

From memory the "checkPosition < toCheckCount" is related to lighting calculations. I once did troubleshooting on a mod which had extreme lag during startup and world generation, it was caused because he had a lot of objects in the sky and rather poor initial guess for the skylight grid. The way lighting calculations are done causes a recursive cascade of updates to the lighting values of blocks and their neighbours, which is extremely slow. -TGG

Hi It's been a while since I worked on packets but I don't see an obvious problem. It looks to me like the handler hasn't even reached your code yet, and given that this works in single player makes me suspicious that it might be a FML bug. FML should automatically add a discriminator byte to the buffer so it should always have at least one byte in it. You could try upgrading Forge to the latest version and seeing if that fixes it. Otherwise, you could add System.out.println to the handlers, the message constructors and toBytes() & fromBytes try to track which methods were actually called, it might give you a clue. Good luck with it; last time I had a Network handler issue (caused by incorrect registration) it took me the whole day to track it down. I'm about to try and work up an example Network handler, if you haven't cracked it in a couple of days I might practice on your project, but no promises -TGG

Hi You could be right, I haven't tried it in the last couple of weeks. I'll give it a go. Edit: I just tried it, you still need it. You get a missing texture otherwise (no error in the console but the model renders as the missing model cube). -TGG

Hi A few suggestions MovingObjectPosition mop = Minecraft.getMinecraft().renderViewEntity.rayTrace(200, 1.0F); This line shouldn't be executed on the server side, it will crash if you try it on a dedicated server. If I recall correctly, there isn't an equivalent rayTrace code on the server side, you could copy it into your own class, but I have a feeling that the targeting might not work right. You could try it and see. The best solution is probably to use a packet from the client to the server saying "I have targeted entity X, shoot it". When you spawn entities, it should be on the server side only, which means you should wrap it in if (!world.isRemote) { // spawn stuff } Spawning stuff on the client side and the server side can lead to all sorts of strange things happening. Lightning is spawned differently from normal entities, use world.addWeatherEffect(..) instead. -TGG

No worries, we all have to start somewhere. Show your code and perhaps we can nudge you in the right direction -TGG

Hi There is a fair bit of information about item and block rendering here; http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html see the sections under Blocks and under Items. There is also a working example project here - see example MBE01 https://github.com/TheGreyGhost/MinecraftByExample/tree/master Sigurd is right, there is no such thing as setTexture anymore. What sigurd has below is right except for a minor detail block model should be in /blockstates/<blockid>.json and should have You also need to register the block and (at the moment) manually register the item model with the mesher Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(itemBlockSimple, DEFAULT_ITEM_SUBTYPE, itemModelResourceLocation); -TGG

Hi Show your code? -TGG

ah, I see you fixed it before I replied. curious.

Hi Well that's odd. The lightning summoning event (CommandSummon) you talked about does world.addWeatherEffect(new EntityLightningBolt(world, d0, d1, d2)); are you sure you're using the correct block [x,y,z]? You should only spawn it on the server side, i.e. as below, but I can't see why that would cause your symptom. Perhaps try a breakpoint in EntityLightningBolt.onUpdate() and RenderLightningBolt.doRender and inspect some of the variables /trace it through to see what is wrong. if (!world.isRemote) { world.addWeatherEffect(new EntityLightningBolt(world, (double)pos.getX()+0.5, (double)pos.getY()+1, (double)pos.getZ()+0.5)); } -TGG

Show your render code? -TGG

> why does the light value persist, albeit sporadically, even between doing things like placing blocks around it and reopening the world? Because the recalculation is very expensive, one block can cause cascading updates to others around it, so vanilla tries to avoid updating lighting unless it absolutely has to Light values are saved with the world and aren't automatically recalculated on load. Generally it's caused by placing of a block next to it, or by a semi-random recalculation. If you stand near your "dark" block for a while, you'll eventually see it pop back to the proper calculated value, just by itself > Also, as far as forcing a re-render, isn't that what I was doing with event.world.markBlockRangeForRenderUpdate(event.x, event.y, event.z, 15, 15, 15); Yes, I think. I have personally used this instead, which worked fine for me: if (cachedNumberOfBurningSlots != numberBurning) { cachedNumberOfBurningSlots = numberBurning; if (worldObj.isRemote) { worldObj.markBlockForUpdate(pos); } worldObj.updateLightByType(EnumSkyBlock.BLOCK, x, y, z); } -TGG

Hi Try Block:: @SideOnly(Side.CLIENT) public IIcon getIcon(IBlockAccess iba, int x, int y, int z, int side) { return this.getIcon(side, iba.getBlockMetadata(x, y, z)); // vanilla - change to get your texture based on TE data } You can retrieve the TileEntity using iba.getTileEntity(x,y,z) -TGG

Hi > Sidenote- could someone confirm or deny for me that there is only one instance of each type of block The answer is "yes" and "no" For example - There is only one instance of BlockDirt. But there are seven instances of BlockOre, one for each "type" of ore, eg gold, iron, diamond, etc. Regardless of how many diamond ores you place in the world, there is only ever one instance of the diamon BlockOre. Look in Blocks for a list, this is where all the instances are. The instances are created in Block.registerBlocks(). You might be interested in this link about blocks http://greyminecraftcoder.blogspot.com.au/2013/07/blocks.html and about Lighting http://greyminecraftcoder.blogspot.com.au/2014/12/lighting-18.html The short explanation about lighting is that you can't just set the light value using setLightValue, because it gets overwritten when the lighting is recalculated. Instead, you need to override the Block method getLightValue() and return a different value depending on whether your block is glowing or not. Your block will need to have some way of knowing whether it should glow. You really only have a few choices: 1) use a different block which looks the same but has a different instance (the furnace does this, for example) 2) use a block with metadata 3) use a TileEntity attached to the block which stores the light value (probably unneccessary for 4) use some sort of logic eg - is the block within a certain distance? or - record a list of the recent blocks in a custom data structure of your own, stored separately, and refer to that You will need to force the blocks to re-render when their lighting changes, otherwise you won't see any change. /** * Get a light value for the block at the specified coordinates, normal ranges are between 0 and 15 * * @param world The current world * @param x X Position * @param y Y position * @param z Z position * @return The light value */ public int getLightValue(IBlockAccess world, int x, int y, int z) { Block block = world.getBlock(x, y, z); if (block != this) { return block.getLightValue(world, x, y, z); } /** * Gets the light value of the specified block coords. Args: x, y, z */ return getLightValue(); } -TGG

Hi Lighting is not an entity same as mobs, you need to spawn it differently Vanilla uses this in WorldServer:: if (this.canLightningStrike(blockpos)) { this.addWeatherEffect(new EntityLightningBolt(this, (double)blockpos.getX(), (double)blockpos.getY(), (double)blockpos.getZ())); } or this in CommandSummon:: world.addWeatherEffect(new EntityLightningBolt(world, d0, d1, d2)); -TGG

Hi Here's an example of how an item might use and update NBT. The item is a "gem" that stores your current [x,y,z] location when you shift-click. When you 'use' it, it retrieves those coordinates and teleports there. There should be enough there for you to figure out how to store and retrieve your integer (eg nbtTagCompound.setInteger()) MyItem:: // called when the player starts holding right click; // --> if the gem is unbound, store the current location // if the gem is bound, start the charge up sequence @Override public ItemStack onItemRightClick(ItemStack itemStackIn, World worldIn, EntityPlayer playerIn) { NBTTagCompound nbtTagCompound = itemStackIn.getTagCompound(); if (playerIn.isSneaking()) { // shift pressed; save (or overwrite) current location if (nbtTagCompound == null) { nbtTagCompound = new NBTTagCompound(); itemStackIn.setTagCompound(nbtTagCompound); } nbtTagCompound.setBoolean("Bound", true); nbtTagCompound.setDouble("X", (int) playerIn.posX); nbtTagCompound.setDouble("Y", (int)playerIn.posY); nbtTagCompound.setDouble("Z", (int)playerIn.posZ); } else { // attempting to use gem teleport boolean bound = false; if (nbtTagCompound != null && nbtTagCompound.hasKey("Bound") ) { bound = nbtTagCompound.getBoolean("Bound"); } if (bound) { playerIn.setItemInUse(itemStackIn, this.getMaxItemUseDuration(itemStackIn)); // start the charge up sequence } else { if (worldIn.isRemote) { // only on the client side, else you will get two messages.. playerIn.addChatComponentMessage(new ChatComponentText("Gem doesn't have a stored location! Shift right click to store your current location")); } } } return itemStackIn; } // called when the player has held down the right click for the full charge-up duration // in this case - destroy the item @Override public ItemStack onItemUseFinish(ItemStack stack, World worldIn, EntityPlayer playerIn) { NBTTagCompound nbtTagCompound = stack.getTagCompound(); if (nbtTagCompound == null || !nbtTagCompound.hasKey("Bound") || nbtTagCompound.getBoolean("Bound") != true ) { return stack; } // teleport if (!worldIn.isRemote) { // server side only - will automatically update to client double x = nbtTagCompound.getDouble("X"); // returns a default if not present double y = nbtTagCompound.getDouble("Y"); double z = nbtTagCompound.getDouble("Z"); if (playerIn instanceof EntityPlayerMP) { // should be an EntityPlayerMP check first just to be sure to avoid crash EntityPlayerMP entityPlayerMP = (EntityPlayerMP) playerIn; entityPlayerMP.playerNetServerHandler.setPlayerLocation(x, y, z, entityPlayerMP.rotationYaw, entityPlayerMP.rotationPitch); worldIn.playSoundEffect(x, y, z, "mob.endermen.portal", 1.0F, 1.0F); } } return null; // for items with multiple count, decrease stack size and return the itemstack, eg // stack.stackSize--; // return stack; } // adds 'tooltip' text @SideOnly(Side.CLIENT) @SuppressWarnings("unchecked") @Override public void addInformation(ItemStack stack, EntityPlayer playerIn, List tooltip, boolean advanced) { NBTTagCompound nbtTagCompound = stack.getTagCompound(); if (nbtTagCompound != null && nbtTagCompound.hasKey("Bound") && nbtTagCompound.getBoolean("Bound") == true ) { tooltip.add("Stored destination="); tooltip.add("X: " + nbtTagCompound.getInteger("X")); tooltip.add("Y: " + nbtTagCompound.getInteger("Y")); tooltip.add("Z: " + nbtTagCompound.getInteger("Z")); } else { tooltip.add("Hold down shift and then right click to store your current location"); } } } -TGG

I'm out of ideas, sorry! -TGG

Hi In 1.8, blocks are single layer only. Items have multiple layers. Some more info here http://greyminecraftcoder.blogspot.com.au/2014/12/block-rendering-18.html and here http://greyminecraftcoder.blogspot.com.au/2014/12/item-rendering-18.html I don't know of any inbuilt way yet to render blocks in 2 layers without using the TileEntitySpecialRenderer. It is possible to add two-layer block rendering if you use ASM+Reflection to modify the vanilla code, that is pretty advanced. It might be added to Forge in the near future if enough people ask. -TGG

Hi unfortunately I still don't understand what you're trying to do and what the symptoms of the problem are. The picture looks strange, but I don't know what you expect it to look like. -TGG

Hi Well that's odd, I don't see an obvious problem. Are you sure it's not working? i.e. if you change particle to lapis blue, is your break block particles blue? If not, I suggest a couple of things to try First try a breakpoint in EntityDiggingFX to find out what texture your block is actually using protected EntityDiggingFX(World worldIn, double p_i46280_2_, double p_i46280_4_, double p_i46280_6_, double p_i46280_8_, double p_i46280_10_, double p_i46280_12_, IBlockState p_i46280_14_) { super(worldIn, p_i46280_2_, p_i46280_4_, p_i46280_6_, p_i46280_8_, p_i46280_10_, p_i46280_12_); this.field_174847_a = p_i46280_14_; this.func_180435_a(Minecraft.getMinecraft().getBlockRendererDispatcher().getBlockModelShapes().getTexture(p_i46280_14_)); //<---- breakpoint here this.particleGravity = p_i46280_14_.getBlock().blockParticleGravity; this.particleRed = this.particleGreen = this.particleBlue = 0.6F; this.particleScale /= 2.0F; } If the block model is right but the texture is wrong, you will need to dig deeper into the loading of your model. ModelBakery.bakeModel is where it looks for your texture in the parsed list of textures at this line private IBakedModel bakeModel(ModelBlock modelBlockIn, ModelRotation modelRotationIn, boolean uvLocked) { TextureAtlasSprite textureatlassprite = (TextureAtlasSprite)this.sprites.get(new ResourceLocation(modelBlockIn.resolveTextureName("particle"))); // here SimpleBakedModel.Builder builder = (new SimpleBakedModel.Builder(modelBlockIn)).setTexture(textureatlassprite); You will need to add a conditional breakpoint (eg modelBlockIn.name.contains("bektor") == true) because this method is used by the vanilla blocks too and there are hundreds. -TGG

For the benefit of later folks, in 1.8 this has been replaced: Tickable TileEntities (eg TileEntityDaylightDetector) now implement IUpdatePlayerListBox Non-tickable TileEntities (eg TileEntitySign) don't. -TGG

FMLcommonHandler.instance().getEffectiveSide() returns Side.SERVER or Side.CLIENT. This might be what you need. I've never had to use it myself, and it has a disclaimer that it might be unreliable, but it might be all you can get. It might be better to refactor your code so it doesn't need to tell which side it is on, or uses a source of information other than the method parameters it gets. Might be more robust. Hard to know without more specific info... -TGG