[1.7.10] Messing with stack sizes

[cw84]

Hello,

 

I started playing around with vanilla settings and have learned that when you mess with an Items MaxStackSize, it seems to break the items enchantability...

Items.diamond_sword.setMaxStackSize(;

 

Any reason why this is...? I don't fully understand why commenting out the line above gives me the ability to once again enchant the item.

[brandon3055]

Because part of the way minecraft checks if an item is enchantable is wit this method

public boolean isItemTool(ItemStack p_77616_1_)
{
       return this.getItemStackLimit(p_77616_1_) == 1 && this.isDamageable();
}

to fix your problem you need to override isItemTool in your item class and return true.

[cw84]

Sorry to ask....

I'm still very new to modding Minecraft and this is a new area for me. Can you provide details how overriding isItemTool shiuld be done?

[coolAlias]

Put the same method in your class, and tell it to return something else:

@Override
public boolean isItemTool(ItemStack stack) {
return true;
}

@Override is helpful in that it informs you if you have the correct method (i.e. the method that you think exists in the parent class (Item) actually exists), but is not necessary for functionality. Use it anyway, though, to save yourself a lot of headaches.

[Ernio]

I was gonna write same as above but noticed he's (op) trying to setMaxStackSize() on vanilla item, alredy registered in game.

 

@Override is used for extended classes.

 

Anyway - There is probably ton of things you could do to make this work, but since 1.7 I have no idea how to do this without bytecode manipulation, and that is (i presume) too hard for you for now.

 

In the old times I would make class extending ItemSword and set Items.diamond_sword to MyItemSword. This worked fine and was quite compatybile (in your case it would be 100% comp). But since there is new registry system as of 1.7 idk if similar thinking would work.

 

Sry, this is not answer to question, but somewhat extension to it.

[cw84]

Yes, I was able to do @Override on extended class...

 

I have not reached a point to start learning bytecode yet, however I wouldn't mind being pointed towards a good tutorial that explains it. I'll start that read when I am comfortable with my Java skills...

 

So is there an easy way to override the vanilla without advanced Java scripting?

[Draco18s]

So is there an easy way to override the vanilla without advanced Java scripting?

 

Remove and replace its recipe so that it craft "I can't believe it's not a diamond sword" instead of a diamond sword.

[cw84]

Fair enough. Though, that wouldn't change the items stackability if it were given from say a trade w/ a villager...

 

Is bytecode the way to do this now?

[Draco18s]

Reflection can do anything.

 

Problem is: you have to know how to do reflection.  I don't believe there are any helper functions for this.

[cw84]

I was trying to avoid reflection due to the performance hit. I suppose I will investigate replacing the item with a custom item... is bytecode the best option here?

[coolAlias]

If you're replacing the recipe to return your custom Item (which isn't a terrible solution, at least any more than changing the vanilla class is), why can't you just override whatever methods you need in your custom class? You shouldn't need ASM or Reflection at all unless you are trying to change the vanilla class.

 

Btw, Forge (FML, actually) does have a ReflectionHelper class, but you still need to know what you're doing to use it.

[Draco18s]

Btw, Forge (FML, actually) does have a ReflectionHelper class, but you still need to know what you're doing to use it.

 

I meant a helper for the specific purpose of overwriting vanilla items.  It's a "relatively" common task, but there's no explicit helper function.

[jabelar]

Reflection can do anything.

 

Actually no. There are several limitations of reflection.

 

Reflection mostly allows you to change the scope of private fields and methods so they are visible to your own classes.  However, it does not allow you to change the methods' code to operate differently.  In other words, you can call methods that otherwise would have been private, but you're still stuck with the methods available as they are already written.  Furthermore, you can't change scope of things like static final fields.  And so on.