Leaderboard

Thanks for the info. This really helps in my conquest for making mods. And your English is perfect.

Proxies are very important because they allow you to distinguish between the sides of your program. There are parts that you might want to implement only on the client, like GUI Drawing, Rendering of items, keybindings etc. Then there's things that you ONLY want to do on the server. Like sending a message to the player. It wouldn't make sense to have the client send a message to itself. Then there's finally some stuff you might want to send to both, like when the player picks up an item. That way the client and server are perfectly in synch. I'm not sure what version you might be on. But in general you want to make a package with a ClientProxy, a ServerProxy class and a commonproxy class. Your proxy classes simply define where stuff goes. they have the same pre-init, postinit and init your main class should have: public class CommonProxy { public void preInit(FMLPreInitializationEvent e) { } public void init(FMLInitializationEvent e) { } public void postInit(FMLPostInitializationEvent e) { } } public class ServerProxy extends CommonProxy{ @Override public void preInit(FMLPreInitializationEvent e) { super.preInit(e); } @Override public void init(FMLInitializationEvent e) { super.init(e); } @Override public void postInit(FMLPostInitializationEvent e) { super.postInit(e); } } (ClientProxy is the same but called Clientproxy) Register these classes as proxies in your main class (Where your preinit, init etc. are registered) like so: @SidedProxy(clientSide="package.clientproxy", serverSide="package.serverproxy") public static CommonProxy proxy; Since you already registered a static reference to your commonproxy and a bridge to your client and serverproxies by calling sidedproxy you can now call your commonproxy in the main methods. Add Main.proxy.preInit(e); to your Main preInit method like such: @EventHandler public void preInit(FMLPreInitializationEvent e) { Main.proxy.preInit(e); } public static BarPacketHandler packetHandler; @EventHandler public void init(FMLInitializationEvent e) { Main.proxy.init(e); } @EventHandler public void postInit(FMLPostInitializationEvent e) { Main.proxy.postInit(e); } Obviously these are all just basic, rough drafts that you'd have to adapt to your class. But if you know Java to any degree you should be able to figure out what I said (hopefully. English isn't my first language). Now when you want a method in your client only, you add the registry/call to ClientProxy under the right place. CommonProxy will call everything that runs on both and ServerProxy runs on the server.

You can get a current Map<Enchantment, Integer> of the enchantments on your desired item using EnchantmentHelper.getEnchantments. The key of the map is the enchantent, and the value is it's level. You can then remove the desired key-value pair from the map(enchantments are singletons) and re-apply the modified map to your item using EnchantmentHelper.setEnchantments. Alternatively you can manualy get the stack's NBTTagCompound(ItemStack::getTagCompound), get the NBTTagList with a key of ench and a type of NBTTagCompound(10) from it - that is the list of enchantments. Then you can iterate through it's NBTTagCompound tags to find and remove the one you desire. Those NBTTagCompound entries contain 2 tags - a short with a key if id being the numerical enchantment ID and a short with a key of lvl being the enchantment's level. You can't use fields like that in your Item class as items are singletons. This field's value will be shared through all items of DragonShield class. This won't do what you want it to do. NBTBase::getId returns the ID of the NBTBase, not the enchantment ID. => if (!isBlastProtected)

One of the main goals of this is to determine what Java versions are used by players. This will allow us to better determine what versions we should care about supporting. If, for example, after we get a bit of data and we see like <1% is using Java 6, Forge will probably drop support for Java 6 reguardless of what Mojang does. Gracefully with a 'update your java here, or downgrade Forge' message but none the less. It will help us figure out what is best to move forward with. Right now, the stats are extremely biased, as Mercurius is only in some FTB packs, and a couple personal packs. Most of which have other mods that force Java 8. We are working twards getting this packaged/installed with the normal Forge installer so that we can get the best dataset we can. And I just want to reiterate that user privacy is of UPMOST importance to us in this project and we have taken great care to make sure no personally identifiable information is sent anywhere. As well as giving you all of the options we can to allow you to control either you even report things or not.

It's sad to see so many people still using 1.7.10... But I like the idea! This is a good thing to see how many people use which MC version, and which Java version (seriously, 1 guy is already using Java 9...).