Leaderboard

Well if you look at the drawStringWithShadow() method you'll see it ends up calling drawString() with shadow parameter which has code that does enableAlpha() as well as resetStyles(). It seems that the resetStyles() should only affect text. But the enableAlpha() I suppose could affect things afterwards. Maybe you can check alpha setting before your code and then restore it afterwards to preserve the setting value for whatever renders afterwards. Also, the overlay event has multiple sub-events. Maybe it would be "safer" to handle the Text event or the Chat event or one of those, where maybe there is a better clean up of any settings changes.

And actually I don't think it needs to be strictly called in the constructor or when creating the object. It should be able to be set at any time (of course prior to trying to repair it). I would probably do it to vanilla items either during item registration or even recipe registration and even init or post init should work. Basically just sometime during loading after vanilla instances exist. @uni52724sorry we're being a bit rude about the Java, but the use would be obvious if you were strong in programming. Let me teach you on how I take a suggestion and figure out the rest of the situation. First of all you should have found the implementation of the method in Item class and you'd see that it is a simple setter method (with chaining as it returns the item instance). Next I would use the call hierarchy to see how it is used. However, interestingly that method is never used in vanilla! But that is okay, that happens sometimes as there are some methods abandoned and some added by Forge. But it means we need to do more investigation to understand how it works. So, then I look at the actual field that the setter sets called canRepair. It is protected in scope so can't be accessed directly, but can by extended classes. I look at it's call hierarchy to see if it is accessed directly by vanilla, but it is not. So basically it means that all Items default to canRepair = true since that is the default value. Now you still need to know how recipes use this. It might be possible that it gets used during recipe registration or something, so you want to understand if the timing of the setNoRepair() matters much. In the call hierarchy for canRepair you can see that in addition to the setNoRepair() method there is a isRepairable() method -- this is the getter function. By following the call hierarchy for that method you can see that it is used by the RecipeRepairItem. Perfect -- so we know that we're on the right track. However, it is a good idea to confirm the implementation of the isRepairable() so I look at its declaration. It does check canRepair field but also need isDamageable() to be true. So checking the declaration of that method shows it just checks that the item isn't using damage for sub-types and also that there is a maxDamage field that > 0. Now this is in fact quite interesting because it means that another way to prevent repair is to set the maxDamage value to 0 (or less). If you follow the call hierarchy for maxDamage, there is a setter called setMaxDamage() and it is actually called on a lot of vanilla items. If you look at something you know is not damageable like ItemBed you see that it calls setMaxDamage(0) in the constructor. Therefore, all this means that vanilla items actually make things no repair by setMaxDamage(0) and do not actually use the setNoRepair() method. However, the setNoRepair() is equally valid. This is often the case in Minecraft because frankly the coding interface wasn't well managed over time and so there are often duplicate methods that achieve similar (but not always exactly) the same effect. So that is the type of investigation someone strong in Java does when given a hint like "use setNoRepair()". I just did all this investigation myself. It is important because you really need to trace the implementations and uses otherwise you can get fooled as the name of the function may not match what you think it does, and you might find other implementation details like I did. So hopefully that teaches you some techniques to help you solidify your own investigations into hints you get here.

Yes No

List<T>#toArray() And again: public void learnedSpell(int spellLearned) { this.SPELL_ID = spellLearned; this.knownSpells.add(SPELL_ID); serializeNBT(); } Why are you calling serializeNBT here? You're telling it to create an NBTcompound and then throwing the result away. Commenting that line out would have the same result.

The if-statement will never be true. Remove it. Just write the array. Except you have a List<int> which is not an int[], you need to convert. There is a method to do this for you already.

In your Clientproxy class you made a mistake here: public class ClientProxy extends CommonProxy { public void registerItemRender(ItemBase item, int meta, String id) { ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(item.getRegistryName(), id)); } } Change ItemBase to Item. I could replicate your problem with this method and changing it to Item solved it. Don't know why you use ItemBase here.

public void learnedSpell(int spellLearned) writeNBT(); } Why are you calling writeNBT here? private NBTTagCompound writeNBT(NBTTagIntArray listSpells) { NBTTagCompound nbt = new NBTTagCompound(); return null; } You aren't writing anything at all And returning null. Why? Why do you make coding puppy sad?