Purple glow on item without enchantments?

Hi,

I was wondering how I could add a purple glow, without adding an enchantment to an item. I'm pretty sure this is possible.. (I've seen it before), but if it isn't, I would also like to know how you can add an enchantment to an item, without having the enchantment's text popping up in the lore (I've experimented with earlier, but for some reason I never managed to remove it from the lore :s).

Thanks in advance!

- Rprrr

 

@Rprrr Comphenix and his plugin ProtocolLib has allowed plugins to remove enchantment effects so it might also help you add them.​

 

I'm not sure how to do it in bukkit but items which are glowing without enchantment have an empty enchantment tag

 

Ye, it's very to do it on that way.

 

ProtocolLib is absolutely not required for this, though it does have an NBT library that can be useful.

Still, here's a method that works without ProtocolLib (download). It does have a significant downside, however:

Code:java

package com.comphenix.example;
 
import java.lang.reflect.Field;
 
import net.minecraft.server.v1_4_R1.ItemStack;
import net.minecraft.server.v1_4_R1.NBTTagCompound;
import net.minecraft.server.v1_4_R1.NBTTagList;
 
import org.bukkit.Material;
import org.bukkit.command.Command;
import org.bukkit.command.CommandSender;
import org.bukkit.craftbukkit.v1_4_R1.inventory.CraftItemStack;
import org.bukkit.entity.Player;
import org.bukkit.plugin.java.JavaPlugin;
 
public class ExampleMod extends JavaPlugin {
    @Override
    public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
        if (sender instanceof Player) {
            Player player = (Player) sender;
            CraftItemStack test = CraftItemStack.asCraftCopy(new org.bukkit.inventory.ItemStack(Material.IRON_AXE, 1));
 
            addGlow(test);
            player.getInventory().addItem(test);
        }
 
        return true;
    }
 
    private void addGlow(org.bukkit.inventory.ItemStack stack) {
        ItemStack nmsStack = (ItemStack) getField(stack, "handle");
        NBTTagCompound compound = nmsStack.tag;
 
        // Initialize the compound if we need to
        if (compound == null) {
            compound = new NBTTagCompound();
            nmsStack.tag = compound;
        }
 
        // Empty enchanting compound
        compound.set("ench", new NBTTagList());
    }
 
    private Object getField(Object obj, String name) {
        try {
            Field field = obj.getClass().getDeclaredField(name);
            field.setAccessible(true);
 
            return field.get(obj);
        } catch (Exception e) {
            // We don't care
            throw new RuntimeException("Unable to retrieve field content.", e);
        }
    }
}

The big problem is that you can't apply an ItemMeta without removing this effect. Any plugin that renames or modifies the name or lore of an item (such as ItemRenamer, etc.) will override the glow effect.

Maybe using ProtocolLib is not such a bad idea after all (download):

Code:java

import org.bukkit.Material;
import org.bukkit.command.Command;
import org.bukkit.command.CommandSender;
import org.bukkit.enchantments.Enchantment;
import org.bukkit.entity.Player;
import org.bukkit.inventory.ItemStack;
import org.bukkit.plugin.java.JavaPlugin;
 
import com.comphenix.protocol.Packets;
import com.comphenix.protocol.ProtocolLibrary;
import com.comphenix.protocol.events.ConnectionSide;
import com.comphenix.protocol.events.ListenerPriority;
import com.comphenix.protocol.events.PacketAdapter;
import com.comphenix.protocol.events.PacketEvent;
import com.comphenix.protocol.utility.MinecraftReflection;
import com.comphenix.protocol.wrappers.nbt.NbtCompound;
import com.comphenix.protocol.wrappers.nbt.NbtFactory;
 
public class ExampleMod extends JavaPlugin {
    @Override
    public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
        if (sender instanceof Player) {
            Player player = (Player) sender;
 
            // Get a CraftItemStack
            ItemStack stack = new ItemStack(Material.IRON_AXE, 1);
            stack = MinecraftReflection.getBukkitItemStack(stack);
 
            // We'll co-op Silk Touch 32 (as it doesn't make much sense) to mark this item as glowing
            stack.addUnsafeEnchantment(Enchantment.SILK_TOUCH, 32);
            player.getInventory().addItem(stack);
        }
 
        return true;
    }
 
    @Override
    public void onEnable() {
        ProtocolLibrary.getProtocolManager().addPacketListener(new PacketAdapter(
                this, ConnectionSide.SERVER_SIDE, ListenerPriority.HIGH, 
                Packets.Server.SET_SLOT, Packets.Server.WINDOW_ITEMS) {
            @Override
            public void onPacketSending(PacketEvent event) {
                if (event.getPacketID() == Packets.Server.SET_SLOT) {
                    addGlow(new ItemStack[] { event.getPacket().getItemModifier().read(0) });
                } else {
                    addGlow(event.getPacket().getItemArrayModifier().read(0));
                }
            }
        });
    }
 
    private void addGlow(ItemStack[] stacks) {
        for (ItemStack stack : stacks) {
            if (stack != null) {
                // Only update those stacks that have our flag enchantment
                if (stack.getEnchantmentLevel(Enchantment.SILK_TOUCH) == 32) {
                    NbtCompound compound = (NbtCompound) NbtFactory.fromItemTag(stack);
                    compound.put(NbtFactory.ofList("ench"));
                }
            }
        }
    }
}

Using ProtocolLib is slightly more complicated, but it does have a few additional advantages: you're no longer tied to a specific CraftBukkit version. That may be a reason enough to use PL.

 

Comphenix
Alright, thanks for the suggestion (also thanks to everyone else that replied). I'll think I'll try ProtcolLib then.

 

I am going to Necropost here (sorry)

Comphenix That works perfectly but as soon as you open your inventory the glow effect is removed and doesn't come back (event after a relog)

 

Looks like this doesn't work in creative mode, as I don't intercept SET_SLOT as I do in ItemRenamer.

But you don't necessarily have to reproduce what ItemRenamer does - instead, you can depend on it using the new API introduced in 2.0.0, and do the following (download):

Code:java

private static final String EXAMPLE_MOD_GLOW = "[ExampleMod]glow";
 
@Override
public void onEnable() {
    RenamerAPI.getAPI().addListener(this, RenamerPriority.POST_NORMAL, new ItemsListener() {
        @Override
        public void onItemsSending(Player player, RenamerSnapshot snapshot) {
            addGlow(snapshot);
        }
    });
}
 
private void addGlow(RenamerSnapshot stacks) {
    for (ItemStack stack : stacks) {
        // Only update those stacks that have our flag lore
        if (stack != null && stack.hasItemMeta()) {
            List<String> lore = stack.getItemMeta().getLore();
 
            if (Arrays.asList(EXAMPLE_MOD_GLOW).equals(lore)) {
                NbtCompound compound = (NbtCompound) NbtFactory.fromItemTag(stack);
                compound.put(NbtFactory.ofList("ench"));
                compound.getCompound("display").remove("Lore");
            }
        }
    }
}

 

Comphenix Make me require all your plugins y don't cha. ;p

So, with ProtocolLib & ItemRenamer what is the difference between the two on the GlowEffect? Besides the registering of Creative Mode.

I would rather not have to depend on both.

 

Heh, yeah, perhaps I got a bit too carried away. The ItemRenamer dependency is not technically necessary, as you can copy what it does in your plugin by looking at its source code.

ProtocolLib is responsible for intercepting packets efficiently and on a wide array of different server types - MCPC+, Spigot, CraftBukkit, while ItemRenamer takes care of processing the inventory packets specifically, and ensures creative mode doesn't accidentally overwrite your items.

You can do all of this yourself, but I would ask that you at least soft-depend on ProtocolLib - that is, revert to using ProtocolLib if its present. Otherwise you will conflict with other plugins that also manipulate the protocol.

How? Take a look at this plugin, specifically InteceptorProtocolLib and InteceptorQueuedPackets. Combining that and ItemRenamer should give you a solution with no dependencies that is still compatible with PL.

 

Comphenix Will this not break when 2 plugins are using it? I'm guessing so but since you surprise me each time with some kind of fix

 

Well, not exactly. If both plugins are using the exact same class, they will create a kind of chain where each list element forwards method calls to the next, until we get to the internal Minecraft list:

Code:

// Plugins are ordered by load order
packets.add() -> plugin2.add() -> plugin1.add() -> minecraft.add()

And most of the time, plugins are unloaded in the exact reverse order they're loaded, so they should clean up the list correctly. Unfortunately, plugins that explicitly reload other plugins (outside the reload command) may break this, so you can't really rely on this behavior.

The second problem is that there's nothing stopping other plugins being difficult (or safe, from their perspective) and either crash or remove your plugin-specific list from the network manager, silently stopping your packet interception. For instance, I think TagAPI should be compatible, but Orebfuscator isn't.

Your best bet is to detect any interference and ask the admin to install ProtocolLib, to avoid any potential conflicts.

 

Comphenix Oh I see... I also have another question about the way you use the FieldSetter. Why? I know it's to detect if the field has been changed by another plugin but why not just use something like:

Code:java

Object fieldValue;
//initialize it here
if(!fieldValue.getClass().getName().equals("your.package.class")
    throw new RuntimeException("Another plugin is fooling around with the networkmanager!");
 

Or wouldn't that work (well) ?