Draco18s

D'oh. That's exactly the problem. (And neither should it! I should be cloning the result here). Ah, the limits of human RAM: we can only hold seven objects in memory at once. I'd forgotten that I'd need to do that. (I do love the implications of not cloning it though: the item exists in multiple places at the same time. \o/ And physicists tell us that's not possible. )

Describe how it doesn't work. What seems to be the issue?

If you want where the game is saved (the current world directory, which contains all of the dimension directories): DimensionManager.getCurrentSaveRootDirectory()

1) Oh, sorry, I clipped that line. I'd been meaning to only include the relavent bits when I did that copy/paste and forgot to remove the extra out line. Here's a bunch: Found tile.ore_gold 1xitem.null@1 Raw Gold Ore:1 1xitem.null@1 com.draco18s.ores.item.ItemOreDustSmall@efad89:1 Found tile.ore_redstone 1xitem.redstone@0 Redstone:1 Found tile.ore_gold 1xitem.null@1 Raw Gold Ore:1 1xitem.null@1 com.draco18s.ores.item.ItemOreDustSmall@efad89:1 2) Ah. I override getUnlocalizedName, due to the subItems all needing different names. That makes sense. Any thoughts on why the item entities have an apparent size of 0? Here's the mergeStack function, which is responsible: private void mergeStacks(ItemStack stack) { if(worldObj.isRemote) return; float rx = 0.5F; float ry = rand.nextFloat() * 0.25F + 0.25F; float rz = 0.5F; EntityItem entityItem = new EntityItem(worldObj,xCoord + rx, yCoord + ry, zCoord + rz,stack); float factor = 0.05F; entityItem.motionX = 0; entityItem.motionY = 0; entityItem.motionZ = 0; entityItem.delayBeforeCanPickup = 10; worldObj.spawnEntityInWorld(entityItem); }

The number of the slot you wish to change....and null.

ItemStack NBT is just like TE NBT. They just store different things.

So I was altering how one of my blocks creates items, changing it from dropping the ore to dropping the dust. Previously everything worked fine, but in this change, the item stacks it would push into the world were somehow getting a stack size of 0 (no matter how many of them went into the world, the player would only pick up 1 and the ItemEntity itself would look like a larger stack for a short while before "collapsing" to be a stack of 1). Here's the code OreDataHooks.subOreData(worldObj, xCoord+bestj*24, yCoord, zCoord+bestk*24, b, 16); System.out.println("Found " + b.getUnlocalizedName()); ItemStack is = new ItemStack(b.getItemDropped(0, this.rand, 0), 1, b.damageDropped(0)); //gets the ore chunk from my ore block System.out.println(is + " " + is.getDisplayName() + ":" + is.stackSize); if(is.getItem() != Items.redstone && is.getItemDamage() != 2) { //if its one of the ones that can be ground into dust is = RecipeManager.getMillResult(is); //grind it (makes a stack of 2) is.stackSize = 1; //make the stack size 1 System.out.println(is + " " + is.getItem() + ":" + is.stackSize); } mergeStacks(is); Here's what the printlns print out: 1xitem.redstone@0 Redstone:1 1xitem.null@1 Raw Gold Ore:1 1xitem.null@1 com.draco18s.ores.item.ItemOreDustSmall@efad89:1 What caught my eye was "1xitem.null" part. Huh? They're all registered properly and list their sub items. And why do the dusts end up as a (nearly) empty stack, but the ores don't?

Funnily enough, I saw this exact thing in a modpack someone's putting together (which includes one of my mods). A little searching around found this SAO HUD mod, which has that exact feature you're trying to do. Not saying you shouldn't continue (duplicate effort, etc.), but you could always try asking that guy how he did it.

java.util.List If you import the wrong one, Eclipse will be like, "Hrm, the type I was expecting isn't matching" and throw an error. In which case it can make a better guess and tell you what the right import is (it'll suggest a change, don't do that) and you can ctrl-z and then reimport the right thing.

Yes, look at the Item class and look for functions that deal with those actions. If you want some hints, here's an item that has all the important functions overriden for its purposes.

itemstack.damageItem(1, p); //where p is a reference to the player. It is passed as the last parameter of onItemRightClick.

Its real easy, but takes a few steps. Durability, in your constructor: setMaxStackSize(1); setMaxDamage(128); This prevents two copies from stacking on top of each other and tells the system how much durability the item has. Repair: @Override public boolean getIsRepairable(ItemStack par1ItemStack, ItemStack par2ItemStack) { } Overrideing this function allows you to set custom repair options. par2ItemStack is the repairing object (the iron ingot, etc.) The default method may be sufficient if you're using standard materials (just make sure that your item has the tool material that is appropriate) Damage: This is the simplest way is to use the tool material. Otherwise, @Override public Multimap getAttributeModifiers(ItemStack itemStack) { Multimap multimap = super.getAttributeModifiers(itemStack); multimap.put(SharedMonsterAttributes.attackDamage.getAttributeUnlocalizedName(), new AttributeModifier(field_111210_e, "Weapon modifier", (double)this.weaponDamage, 0));//replace this.weaponDamage with the value desired return multimap; }

It renders a block in a simple manner. It has a lot less overhead than a TESR but also fewer features.

Hopefully! Otherwise my Artifacts mod won't be able to update to 1.8 (I use a ton of textures-by-NBT).

Well. Any and every item should be able to be used to break blocks as if the player was punching (no item in hand).

No idea! That was written weeks ago, my best-guess is I was thinking "this slot is output, shouldn't be putting anything into it!" And I had to change the TransferInSlot method last night because it was still a duplicate of the furnace (it was checking furnace recipes for slot validity). Lots of little stuff that at first blush looks to be working right, but isn't, heh.

Note that the guess can be 100% accurate, as the client does know the full state of the world (plus or minus a second). For example, I was messing with pushing ItemEntities around (similar to liquid flow) and if the code only ran on the server they'd move about a full block at a time, so it was pretty close to short-range teleportation.

Ha, turns out it was my own stupid fault in the TileEntity class: @Override public void setInventorySlotContents(int slot, ItemStack stack) { if(slot == 2) { return; } Amazing what a night's sleep and fresh eyes will find.

This problem only occurs in Slot 2 (the output slot). Every other slot shift-clicks just fine, but slot 2 likes to leave a size-zero stack behind, for no apparent reason. I've double checked my code against other Container classes and nothing seems out of place. @Override public ItemStack transferStackInSlot(EntityPlayer player, int slotNum) { ItemStack itemstack = null; Slot slot = (Slot)this.inventorySlots.get(slotNum); if (slot != null && slot.getHasStack()) { ItemStack itemstack1 = slot.getStack(); itemstack = itemstack1.copy(); if (slotNum > 2) { if (RecipeManager.getSiftResult(itemstack1, false) != null) { if (!this.mergeItemStack(itemstack1, 0, 1, false)) { return null; } } else if (slotNum >= 3 && slotNum < 30) { if (!this.mergeItemStack(itemstack1, 30, 39, false)) { return null; } } else if (slotNum >= 30 && slotNum < 39 && !this.mergeItemStack(itemstack1, 3, 30, false)) { return null; } } else if (!this.mergeItemStack(itemstack1, 3, 39, false)) { return null; } if (itemstack1.stackSize == 0) { slot.putStack((ItemStack)null); } else { slot.onSlotChanged(); } if (itemstack1.stackSize == itemstack.stackSize) { return null; } slot.onPickupFromSlot(player, itemstack1); } return itemstack; }

This is what the OreDictionary is for.

You can try looking at the StringTranslate class.

Entities should totally run their movement code on the client side, as while the server will enforce what it believes is going on, if the client end isn't doing ANYTHING then the entity will jump around as it periodically gets packets from the server correcting its location.

You can also grab NBTExplorer and spy on the tags for any item.

Sorry, your other thread isn't something I can help with. Off-hand I'd guess that the box is too large for the texture or that the UVs are wrong.

No, I mean, why does it need to destroy the water in order to fly through it?