WildBamaBoy

It's for 1.6, but maybe this will help: https://github.com/WildBamaBoy/modjam-dec-2013/blob/master/Forge/mcp/src/minecraft/spellbound/item/ItemBookOfSpells.java

Hey, thanks for the fast reply. I'll definitely be looking into that. By "items can have many localized names", did you mean unlocalized? Which item does this? If you meant localized, then wouldn't it be simpler to enforce unlocalized names as registry names since they do not change? While I can't think of any benefit to this right now (except in my situation), it might be helpful for something we're not thinking of at the moment.

Once a player logs in, I have to assign a client entity's inventory so that their held item, worn armor, etc. shows up immediately to the player instead of when their inventory is eventually accessed and assigned by Minecraft's S2FPacketSetSlot packet. The player can place any item or block in this inventory, so the entity is basically a moving chest. The player can also change out their weapon, armor, etc. which will be displayed for all clients. Since item IDs are a thing of the past, this has been broken. My method before was to tell the client about the inventory items on login by sending a string for each occupied slot: [slot ID]:[item ID]:[stack size]:[stack damage] Where a damaged iron chestplate in slot 6, for example, would have the values: 6:307:1:40 The client would parse this information and add the item to the inventory for displaying purposes. Now, I've tried identifying the item by replacing the item ID with the item's unlocalized name. I strip off the "item." and ".name," leaving the base item name. Turning the string I send into: [slot ID]:[item name]:[stack size]:[stack damage] Which, for the same iron chestplate, would now translate to: 6:chestplateIron:1:40 But the iron chestplate in the item registry doesn't have that name. It is called "iron_chestplate". Because of this, I've had to resort to using item IDs anyway. Server-side: Item.getIdFromItem(stack.getItem()) Client-side: Item.getItemById(itemId) And it works. To my understanding, this could be a problem with mod items if the server or connected clients do not share the same underlying item IDs, right? Unless there's some other unique identifier for an item that can be sent across the network (i.e. its "name" that is added to the item registry), this is my only option. There doesn't seem to be a reliable way to get an item via its name constant from the item registry since the name constant on that item doesn't seem to be remembered in the item itself, like the unlocalized name is. Granted, some name constants do match the item's base unlocalized name, but most do not. Ensuring that they do would provide a solution to this problem.

Actually, just forget it. I'm quite happy with my own build script. Thanks for your help though.

I really appreciate your help. This is all new to me, remember. I'm not familiar with gradle, maven, or anything like that. The core was published, apparently, but gradle still doesn't know where it is when building MCA. I'm not sure what else to tell it, or how. This is a lot more frustrating than it has to be, but I'm probably making it more complicated than it really is. I may end up modifying my original build script to copy the core's source where it needs to be and then build, if that would work. Although I'd like others to know how to implement the core correctly since it's open source.

Something like this? It can't find the core. It's in a completely separate folder with another copy of gradlew, the minecraft source, etc. and its src/main/java is a linked folder in MCA's eclipse workspace. I don't understand how it is supposed to know where "com.radixshock.radixcore" is supposed to be, or how to tell it that. The core's relevant build.gradle section: [...] apply plugin: 'forge' version = "1.0.0" group= "com.radixshock.radixcore" archivesBaseName = "RadixCore" [...] MCA's relevant section [...] dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:1.1-SNAPSHOT' classpath 'com.radixshock.radixcore:RadixCore:1.0.0' } [...]

Trying to build MCA using Gradle. It now uses another separate "mod" that contains core functions, interfaces, etc. that I plan to reuse. When building, Gradle can't find any references to this other mod. How do I point it in the right direction? My file setup is probably very weird. I'm not sure what it's generally supposed to be with multiple mods, plus I'm using Git and I'm not very experienced with it. Gradle |_src |_main |_ java |_ mca |_ [mca's packages] |_ radixcore (this is the other mod's repository from GitHub) My Eclipse workspace is as follows: Minecraft |_ src/main/java |_ [mca's packages] |_ src/main/resources |_ [mca's resorces] |_ radixcore (Shortcut to the src/main/java folder of the radixcore project)

I'm adding a sapling class with twelve different sub-blocks. The saplings show the correct texture when placed in the world, but when in the inventory they always show the icon of the first sapling. I've checked and getIcon() is always being given a metadata value of zero. If I change meta to any other appropriate number then that sapling's icon is shown. I cannot figure out why this is happening. I do the exact same thing with my leaves and logs and it works great. Sapling class: package arrowsplus; import java.util.List; import net.minecraft.block.Block; import net.minecraft.block.BlockFlower; import net.minecraft.client.renderer.texture.IconRegister; import net.minecraft.creativetab.CreativeTabs; import net.minecraft.item.ItemStack; import net.minecraft.util.Icon; import cpw.mods.fml.relauncher.Side; import cpw.mods.fml.relauncher.SideOnly; public class BlockArrowTreeSapling extends BlockFlower { public static final String[] woodType = new String[] {"aspen", "cottonwood", "alder", "sycamore", "gum", "softmaple", "ash", "beech", "hardmaple", "hickory", "mahogany", "sypherus"}; @SideOnly(Side.CLIENT) private Icon[] saplingIcon; protected BlockArrowTreeSapling(int par1) { super(par1); this.setCreativeTab(ArrowsPlus.instance.tabArrowsPlus); this.setTickRandomly(true); } @Override public Block func_111022_d(String par1Str) { this.field_111026_f = "arrowsPlus:tree"; return this; } @SideOnly(Side.CLIENT) public Icon getIcon(int side, int meta) { //-----------------> Meta is always zero. return this.saplingIcon[meta]; } public int damageDropped(int meta) { return meta; } @SideOnly(Side.CLIENT) public void getSubBlocks(int itemId, CreativeTabs creativeTab, List listSubBlocks) { listSubBlocks.add(new ItemStack(itemId, 1, 0)); listSubBlocks.add(new ItemStack(itemId, 1, 1)); listSubBlocks.add(new ItemStack(itemId, 1, 2)); listSubBlocks.add(new ItemStack(itemId, 1, 3)); listSubBlocks.add(new ItemStack(itemId, 1, 4)); listSubBlocks.add(new ItemStack(itemId, 1, 5)); listSubBlocks.add(new ItemStack(itemId, 1, 6)); listSubBlocks.add(new ItemStack(itemId, 1, 7)); listSubBlocks.add(new ItemStack(itemId, 1, ); listSubBlocks.add(new ItemStack(itemId, 1, 9)); listSubBlocks.add(new ItemStack(itemId, 1, 10)); listSubBlocks.add(new ItemStack(itemId, 1, 11)); } @SideOnly(Side.CLIENT) public void registerIcons(IconRegister iconRegister) { this.saplingIcon = new Icon[woodType.length]; for (int i = 0; i < this.saplingIcon.length; ++i) { this.saplingIcon[i] = iconRegister.registerIcon(this.func_111023_E() + "_" + woodType[i] + "_sapling"); } } } They are registered as such in preInit() blockArrowTreeSapling = new BlockArrowTreeSapling(modPropertiesManager.modProperties.blockId_ArrowLogSapling).func_111022_d("tree"); GameRegistry.registerBlock(blockArrowTreeSapling, ItemBlockSapling.class, "Arrow Saplings"); for (int i = 0; i < 12; i++) { ItemStack saplingStack = new ItemStack(blockArrowTreeSapling, 1, i); LanguageRegistry.addName(saplingStack, saplingNames[i]); } The ItemBlock for the saplings package arrowsplus; import net.minecraft.item.ItemBlock; import net.minecraft.item.ItemStack; public class ItemBlockSapling extends ItemBlock { public static final String[] saplingNames = new String[] {"Aspen Sapling", "Cottonwood Sapling", "Alder Sapling", "Sycamore Sapling", "Gum Sapling", "Soft Maple Sapling", "Ash Sapling", "Beech Sapling", "Hard Maple Sapling", "Hickory Sapling", "Mahogany Sapling", "Sypherus Sapling"}; public ItemBlockSapling(int id) { super(id); setHasSubtypes(true); setUnlocalizedName("ItemBlockSapling"); } @Override public int getMetadata(int damageValue) { ArrowsPlus.instance.log(damageValue); return damageValue; } public String getUnlocalizedName(ItemStack par1ItemStack) { return saplingNames[par1ItemStack.getItemDamage()]; } }

Nice!

If I could be pointed to some documentation of these "facilities" I'd gladly use them. And I know my method is bad, but it does/has worked without networking issues until now. Guess it has to go.

Problems with Minecraft Comes Alive: Users of my mod that have Forge 7.7.1.624 and above (so far) report problems that are not present on the recommended version that I link them to: 7.7.1.611. Description I use a certain packet to update the client with the same randomly selected information that the server selected and keep it updated. This is the process: Client entity doesn't have a texture -> Sends "sync request" packet to Server containing entity id -> Server handles "sync request" by serializing and sending back the entity with the provided id -> Client searches for entity with the same id as the one that was just received and deserialized -> ERROR. ID doesn't match any entities on the client. Client side entity is never updated. Packet is not properly handled. This problem was fixed by adding the entity id to the sync packet by itself, alongside the entity that was serialized. The client side entity was successfully updated but still did not receive its texture. Instead it used the default char.png. I specifically tell my entities to write their textures and entityIds when being serialized; for some reason this data wasn't written correctly. /** * Writes this object to an object output stream. (Serialization) * * @param out The object output stream that this object should be written to. * * @throws IOException This exception should never happen. */ private void writeObject(ObjectOutputStream out) throws IOException { out.defaultWriteObject(); out.writeObject(texture); out.writeObject(entityId); } /** * Reads this object from an object input stream. (Deserialization) * * @param in The object input stream that this object should be read from. * * @throws IOException This exception should never happen. * @throws ClassNotFoundException This exception should never happen. */ private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { in.defaultReadObject(); texture = (String)in.readObject(); entityId = (Integer)in.readObject(); } Log verifying that some error has occurred with the entity id. They do not match when on previous versions they do! To see this output, you must use the command "/mca.debug on" before allowing a villager from the mod to spawn. After I fixed the problem with the entity ID, I also had to add the texture to the packet so that the client would actually receive the right texture data. My writeObject and readObject methods are being skipped. Why? More verification that these methods are skipped: the entity's inventory must also be serialized and sent back and forth. When I try to serialize the inventory for a packet, I get a NotSerializableException on a field. I override the serialization with writeObject and readObject, and I do not allow defaultWriteObject() to run so that I won't have the problem with a field not being serializable. It only writes what I tell it to. This is the error I get when trying to serialize an Inventory: 2013-04-04 23:10:27 [iNFO] [sTDERR] java.io.NotSerializableException: net.minecraft.item.ItemStack 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.writeObject0(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.writeArray(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.writeObject0(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.writeSerialData(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.writeObject0(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.io.ObjectOutputStream.writeObject(Unknown Source) 2013-04-04 23:10:27 [iNFO] [sTDERR] at mods.MCA.PacketCreator.createInventoryPacket(PacketCreator.java:432) 2013-04-04 23:10:27 [iNFO] [sTDERR] at mods.MCA.EntityVillagerAdult.interact(EntityVillagerAdult.java:678) 2013-04-04 23:10:27 [iNFO] [sTDERR] at net.minecraft.entity.player.EntityPlayer.interactWith(EntityPlayer.java:1222) 2013-04-04 23:10:27 [iNFO] [sTDERR] at net.minecraft.client.multiplayer.PlayerControllerMP.func_78768_b(PlayerControllerMP.java:462) 2013-04-04 23:10:27 [iNFO] [sTDERR] at net.minecraft.client.Minecraft.clickMouse(Minecraft.java:1291) 2013-04-04 23:10:27 [iNFO] [sTDERR] at net.minecraft.client.Minecraft.runTick(Minecraft.java:1796) 2013-04-04 23:10:27 [iNFO] [sTDERR] at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:831) 2013-04-04 23:10:27 [iNFO] [sTDERR] at net.minecraft.client.Minecraft.run(Minecraft.java:756) 2013-04-04 23:10:27 [iNFO] [sTDERR] at java.lang.Thread.run(Unknown Source) I specifically include the writeObject() method in Inventory to skip the default serialization and prevent this problem. You can view this for yourself in both versions of the source code. Why does this happen? And why only on later versions of Forge? Source Code (Broken on 624+, perfect on 611-) - https://dl.dropbox.com/u/64124307/Broken%20Source.zip Source Code (Semi-Fixed for later Forge versions, Inventory packet kills the game. Gift a sword to a villager.) - https://dl.dropbox.com/u/64124307/Semi-Fixed%20Source.zip Files of interest: PacketHandler.java, createSyncPacket(), createSyncRequestPacket(), createInventoryPacket() PacketCreator.java, handleSync(), handleSyncRequest(), handleInventory() EntityVillagerAdult.java, interact() EntityBase.java, writeObject(), readObject() Inventory.java, writeObject(), readObject() While it seems entirely wrong to blame Forge for what appears to be a problem with serialization (I have no idea how you can screw with built-in java), the exact same code works flawlessly on Forge 611 and has been working for months! I don't know what else to blame.

Bump

GameRegistry. Don't use ModLoader.

Take the check for world.isRemote off. A block change must happen both client (world.isRemote) and server (!world.isRemote) side in order for it to stay there.

Bump