hotrods20

No, my other mod ObsidianTools does it the same exact way without error.

Lol, thank you for that. On the topic of fixing it, it is for the latest for 1.5.2. Not sure if latest so just in case: 5.2.23.737

This baffles me completely. I get an error when I use the GameRegistry with my new item but if I don't register it, it works just fine. All Code needed: The items code. public static Item joint = new ItemFood(3420, -1, 0.1F, false).setPotionEffect(Potion.hunger.id, 90, 0, 1.0F).setAlwaysEdible().setCreativeTab(tabPotMod).setUnlocalizedName("joint"); The actual code that registers it. @Init public void load(FMLInitializationEvent evt) { LanguageRegistry.addName(joint, "Joint"); GameRegistry.registerItem(joint, "joint"); LanguageRegistry.instance().addStringLocalization("itemGroup.tabPotMod", "en_US", "Pot Mod"); } Error Report:

I did try adding classes for each item I am adding but it still didn't help. It seems like the enchantment table just doesn't get the value for my item. Has any mods made items that can be enchanted via enchantment table?

public static EnumToolMaterial obsidian = EnumHelper.addToolMaterial("OBSIDIAN", 3, -1, 6.0F, 2, 12); public static Item oSword = new ItemSword(3500, obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oSword"); public static Item oAxe = new ItemAxe(3501, obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oAxe"); public static Item oHoe = new ItemHoe(3502, obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oHoe"); public static Item oPickaxe = new ItemPickaxe(3503, obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oPickaxe"); public static Item oSpade = new ItemSpade(3504, obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oSpade"); That is all the code that I have created in the sense of creating the items. I have already registered the items and all that. The sword code can be found in ItemSword in net.minecraft.item.

I've come to the conclusion that when the ItemSword class is looking for a material, it will only accept materials that have been declared in EnumToolMaterial because I had my Obsidian material just copy the EnumToolMaterial.IRON and it let my tool be enchanted. Is it possibly how the material is added to the game?

Yeah, it seems like it.

I just use the ItemSword.java which is a vanilla class. By using that and using my custom tool material, it should work. The code from ItemSword.java: public int getItemEnchantability() { return this.toolMaterial.getEnchantability(); }[/Code] This should work because it gets the ability to be enchanted from the material. My material: [Code]public static EnumToolMaterial obsidian = EnumHelper.addToolMaterial("OBSIDIAN", 3, -1, 6.0F, 2, 14);[/Code] The last number in my code is the ability for the item to be enchanted's factor. That one is equal to iron. Gold having the highest of course.

My items are tools and weapons, so shouldn't they default to being able to be enchanted?

I am currently developing a mod that adds some custom weapons. I am not entirely sure on what is wrong so I'll post code. public static EnumToolMaterial obsidian = EnumHelper.addToolMaterial("OBSIDIAN", 3, -1, 6.0F, 2, 14); public static Item oSword = new ItemSword(3500, OTMain.obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oSword"); public static Item oAxe = new ItemAxe(3501, OTMain.obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oAxe"); public static Item oHoe = new ItemHoe(3502, OTMain.obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oHoe"); public static Item oPickaxe = new ItemPickaxe(3503, OTMain.obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oPickaxe"); public static Item oSpade = new ItemSpade(3504, OTMain.obsidian).setCreativeTab(tabObsidianTools).setUnlocalizedName("oSpade"); The problem I am having is when I place the items in the enchantment table, no enchantments show up. I can do /enchant and I can place them in Anvils and enchant them. Any suggestions or anyone know how to get enchantments to appear for these items? Solution: So, if a tool material has 0 or lower amount of uses, then it won't be able to be enchanted in a enchantment table. Solution is to modify the tool in its own class to not take any damage from anything. That means if you want to have items that don't suffer from durability loss, you need to have: @Override public boolean hitEntity(ItemStack par1ItemStack, EntityLiving par2EntityLiving, EntityLiving par3EntityLiving) { par1ItemStack.damageItem(0, par3EntityLiving); return true; } @Override public boolean onBlockDestroyed(ItemStack par1ItemStack, World par2World, int par3, int par4, int par5, int par6, EntityLiving par7EntityLiving) { par1ItemStack.damageItem(0, par7EntityLiving); return true; } In each items class file or in a main tools file they all read file.

Converting Bytes to ints is easy but the problem is compatibility is gone. The sad truth is that Mojang would have to release an MC update that fixes the world generation for all mods to get along with it.

for(int i = Item.itemList.length; i > 0; --i) { if(Item.itemList == null) { //Declare Item with ID that is free. } }

I have been working on the fix for awhile but it still has major problems. I would like to know what others think could work as a fix without throwing out compatibility. The main problem I see is generation and writing to the save file. I did mess with the NBT stuff but it didn't help. So, what are some ideas people have to fix this error? Would someone else be willing to test the code too? EDIT: More Detail of problem: I converted the code to use ints instead of bytes for the blocks and such but it is still using bytes and all that nonsense. The block ID of 592 converted to a byte is 80. 80 is the ID of the block of snow. This caused snow blocks to generate in my world instead of my block. The point is this, somewhere it is stuck with the -128 and +127 byte code. Could someone help me locate this problem and figure out a way around it?

@Coders: I have a version that technically is working but first an error we should discuss and I would like to fix before I pass the code over to the Forge team or anyone who wants to use the code in a API. Important: This is currently being coded for Minecraft 1.2.5 because it was started on there and will be converted to the latest Minecraft after it is confirmed to work for 1.2.5 The error: The error is a NullPointerException that gets caused by the getBlockMaterial method in the world class. The error log reports the error is stemming from line 719 of the world class. Code on the line: return var4 == 0 ? Material.air : Block.blocksList[var4].blockMaterial; I have confirmed the block I am trying to generate has a material set. I will supply the code to users who want to help fix this since the code is considered incomplete and I don't want any idiots running around releasing code that isn't guaranteed to work. EDIT: Found different error that isn't helping either. Come back later.

Might I also say that you should make sure it isn't 2 mods that conflict and not Forge/ModLoader. Forge is compatible with all the mods I have tried. Did you read the errors it produced or did you just assume it was Forge's fault? If the error said anything along the lines of conflicting IDs, then your mods don't play friendly. Simple as that.

Yes a short would be enough but everything numerical is usually set as a int. I want variable to play as friendly as possible. The code already has a bunch of variables and converting numbers. Might as well use something more common among modders. Plus, block IDs are ints. This will make it so you don't have to throw it as a short when you pass it into the topBlock code. Trying to remove as much of that stupid "conversion" stuff as possible. Main problem is still getting it to spawn but I am pretty sure I found the answer to that too.

Sad part, this is one of the hardest pieces of codes if I don't want to throw out compatibility but it is a pain in the ass that I have to deal with. Current concept I am trying: You change the topBlock and fillerBlock to int and compatibility won't be shot to shit but can't get higher than 256 block IDs to work still. Currently converting a lot of code to int and trying new things.

The only reasons I haven't updated and probably a few friends haven't gotten deep into modding is: Waiting for stability Looking for free time Learning the new code Learning other Java based things (Started learning LWJGL) Just wait a wee bit and all your precious mods will be out.

Depends on the lines. If it is possible, you could use setPrivateValue.

I would think it would be as easy as copying ItemBow and EntityArrow with just a few bits of code change and such... What have you exactly tried?

I am working on it. It is gonna take a while, so hold on. You can't just convert a bunch of code and call it a fix. Gotta make it work and keep compatibility with ML mods.

^^^ That Anyways, the fix I am writing will make it so bytes still work but users would have to define that it is a short if they are making it that way with a new boolean that doesn't need to be changed unless you use shorts and use the new variables since the default variables are bytes.

To simplify, I am converting code and editing a lot of base classes(something I don't like doing). So right now, you will have to hold on till I finish the fix.

Right now I am writing up a fix that could work for you and might even be put into Forge if Lex and the other members of Forge find it useful. Currently ran into a problem but I am working on fixing it. I see what error you came across. It is pretty messed up.

If you would wish/want, I could look into rewriting the code and still have compatibility. In my rewrite of ChunkProviderGenerate, I made it so you still have an array of bytes for the world generation of structures, mines, and strongholds. I then created a new array of shorts for the replaceBlocksForBiome method so that is gets the same exact array but as a short[]. It was a quick fix but overall changing the normal code would/could be possible while maintaining compatibility with non-Forge. Just gotta do it the right way. EDIT: Quick idea for a fix that could/would work with the code I wrote and wouldn't change much at all. You could have a boolean variable in BiomeGenBase that says if it will require a byte or a short, defaulting to false(for byte) it could be used so old mods still have compatibility and would accept mods that use shorts. I'm going to write a quick example and put the source on this thread for the classes I changed.