Hiding Enchantments (with NMS)

Hey,

I've been going through some threads but there wasn't a (currently working) way of hiding enchantments in the lore, let's say a "Protection I" tag.

How can we hide this "Protection I" tag, without losing the effect such an enchantment would cause (resistance): just hiding it from the lore. I don't want to use libs to depend on (ProtocolLib, for one) and I'm searching for a way through (Craft)Bukkit.

Anyone know a way to achieve this, perhaps with NMS?

Thanks in advance!

 

AFAIK, there isn't a way to hide an enchantment without using packets. But, you could probably write some reflection code to make your plugin cross-compatible between MC versions.

 

What packets are used when the item receives the enchantments? I just need that packet to hide the enchantments, so I find using ProtocolLib quite sloppy for such a small visual feature.

 

I can't find any packets pertaining to a player receiving ItemMeta, but I did find this class. It basically modifies the NBT of the ItemStack so that a glow effect is added. However, I believe it stopped working shortly after it was last updated. Still, it might point you in the right direction.

 

Hmm, I see. The enchantments only go with id and level in a tag, so I'm not bright enough to think of a solution with NBT tags.. any idea? D:

 

I'm afraid not. I'm actually not even sure if it's possible.

 

ShadyPotato i already search for that , i spend a lot of time on it... And yes(99% percent sure) there is no way of hiding them . MAybe in 1.8... i'm not sure but i think they add a posibility to create tools that have enchantments but that are not showing.. so maybe bukkit will implements it?

 

You can always remove the enchantments from the item and save them. So that you can create a listener, and check if a player get damaged and he has protection you will remove the amount of health that is equal to the enchantment.

 

Well, you always can write packet interceptor, and change all outgoing packets... but why you want to do this, if there is a ProtocolLib? There is nothing bad to use an external library, their usage is common in programming.

 

Inside vanila minecraft, you can spawn a sword using the following command:
/summon Item ~ ~ ~ {Item:{id:minecraft:diamond_sword,Count:1,tag:{HideFlags:1}}}
If you do this, then you won't see any enchantment on this item, while they still work. Now we need only a method to convert this to bukkit (I think it will take a looooong time before bukkit implements the /summon command)

 

rsod That's of course a proper way to do it, but as it is a minigame, the requester doesn't want it to depend on external libraries.

ferrybig the HideFlags tag is for 1.8, sadly

 

Bartoke
you can just pack protocollib into your jar file and provide it as is (upd: I'm not sure if it's actually possible with protocollib, but you might give it a try). If requester puts such a requirement he is zero in programming.
Another way is just discard this order and pick something else. I don't think you will lose that much money from that order.

 

First - please don't do that. It will significantly inflate your plugin, and likely conflict with a regular installation of ProtocolLib. Is sacrificing plugin compatibility really worth the convenience of no explicit dependencies?

You should try using TinyProtocol, if depending on ProtocolLib is not an option. It will allow you to intercept the WINDOW_ITEMS and SET_SLOT server packets, and also the CREATIVE_INVENTORY_ACTION client packet sent by creative players when they create a new item stack. Then you could adapt what I do in ItemRenamer to TinyProtocol. In fact, ItemRenamer actually supports hiding enchantments using its configuration format or API ...

The only real difficulty here is creative players. Their CREATIVE_INVENTORY_ACTION packet is actually sent for EVERY inventory action, not just when they're creating new items. So - if you send them an item with no enchantments, they'll send it back, and the server will accept that version as the new item - removing the enchantments on the server side as well.

My general solution to this problem in ItemRenamer was to store the original item in a custom NBT tag, and restore it before the packet gets received by the server. Which, because Bukkit removes custom NBT tags, is actually a bit complicated - I have to intercept the raw packet data and read the item stack that way, instead of reflection as normal. But there might be easier solutions in your case, like disabling creative mode or tagging the item stacks with an attribute.