Ok, I understand, but even directly sending a packet to the client, for example, the setslot packet, won't work. That's why I thought there's some filter in place. I understand why the API isn't allowing it, but to my understanding, just sending a packet shouldn't have anything to do with the API. However, the item will still just show up without the invalid tags.

Yes, the API isn't meant to break across versions.

OK then, but even if Mojang removes that functionality, would it be so hard to remove that part of the API?

Mods don't represent Mojang. I'm a mod on their tracker also..

Screenshot with a quote by a mod: http://i.imgur.com/dgCd827.png

>And then how do you remove these enchants if they aren't ever returned by the API?

I guess you could just remove them using NMS. Remember they are not actual enchants, and therefore won't influence anything (besides the enchantment glint) even if never removed.

>Since you're already hacking into the API with reflection, why not just hack further and register them properly in the server as enchants so they actually work. You've incorrectly used reflection to hack around the API and then complaining it doesn't work because you didn't do it properly or fully.

I managed to do that already. However, but I was just looking for a way to allow invalid enchantments (via commands if possible - eg: the /give command).

>It's not that simple, the NBT tag isn't ever stored. It is fully deserialized to Bukkit and then later re-serialized, which is why you need to actually register them to the server (see next point).

I understand, and I also see that it's not up to me how this is implemented, I just made a suggestion.

>The way they recommended me to do that currently is by using invalid enchants
Source? I doubt a Mojang developer would suggest that.

>Also, why would it be hard to edit the API so it will only return the valid enchantments on the item? You should just check if their ids are registered, and if not, simply don't return them, but leave them in the nbt tag.
And then how do you remove these enchants if they aren't ever returned by the API?

>You should just check if their ids are registered, and if not, simply don't return them, but leave them in the nbt tag.
It's not that simple, the NBT tag isn't ever stored. It is fully deserialized to Bukkit and then later re-serialized, which is why you need to actually register them to the server (see next point).

> I used reflection to set the acceptingNew field to true
Since you're already hacking into the API with reflection, why not just hack further and register them properly in the server as enchants so they actually work. You've incorrectly used reflection to hack around the API and then complaining it doesn't work because you didn't do it properly or fully.

The Bukkit API will not support custom blocks/entities/items/enchants/whatever because it is a plugin, not modding API.

For the first part, I gotta admit I used reflection to set the acceptingNew field to true. As for mojang stopping to accept invalid enchants, I highly doubt it. I mean, I've reported the 1.11 change (the one that made empty ench:[] tags still not display the item glow for clients) and they said it was an intended change. The way they recommended me to do that currently is by using invalid enchants, and that is currently the only way to add glow to unenchanted items, therefore I highly doubt they will remove it. Also, why would it be hard to edit the API so it will only return the valid enchantments on the item? You should just check if their ids are registered, and if not, simply don't return them, but leave them in the nbt tag.

1)

java.lang.IllegalStateException: No longer accepting new enchantments (can only be done by the server implementation)
	at org.bukkit.enchantments.Enchantment.registerEnchantment(Enchantment.java:287) ~[classes/:?]
	at net.md_5.TestPlugin.onEnable(TestPlugin.java:32) ~[?:?]
	at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:271) ~[classes/:?]
	at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:337) [classes/:?]
	at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:405) [classes/:?]
	at org.bukkit.craftbukkit.CraftServer.enablePlugin(CraftServer.java:376) [classes/:?]
	at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:326) [classes/:?]
	at net.minecraft.server.MinecraftServer.t(MinecraftServer.java:419) [classes/:?]
	at net.minecraft.server.MinecraftServer.l(MinecraftServer.java:380) [classes/:?]
	at net.minecraft.server.MinecraftServer.a(MinecraftServer.java:335) [classes/:?]
	at net.minecraft.server.DedicatedServer.init(DedicatedServer.java:272) [classes/:?]
	at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:542) [classes/:?]
	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_111]

java.lang.IllegalStateException: No longer accepting new enchantments (can only be done by the server implementation)

I don't even know how you're using that method.
2) Creating code in the API to ignore invalid enchants, even though there is no valid way of getting them
3) Sure, Mojang does it all the time. All it requires is for them to stop accepting invalid enchants and the whole API goes kapoof
4) The difference is the custom NBT data currently stored is meant to be custom - lore, custom names etc. Enchants are not. Bukkit has no way of assigning IDs or having any sort of handling for custom content. Enchants are no exception to this. Bukkit will not support custom enchants.

1) What is that method for than? Or why is it exposed as a public method to other plugins? Actually, the JavaDocs say it's for no purpose. Anyways, let's be honest: It's a really useful method and it's used by many, especially plugins who try to implement "custom" enchantments features tied in as much as possible to vanilla enchantments.

2) I don't really understand how am I really "special casing the API". Can you detail please?

3) The ability for adding custom enchants? I really can't understand why would that happen, and how it could possibly be considered a bug...

4) Well the vanilla server does seem to store invalid enchants, and I don't see why Bukkit wouldn't do the same. It already saves custom NBT data on items, so why wouldn't it also save invalid enchant data? - It's also in it's NBT. I understand that Bukkit is NOT a modding platform in the way many look at it, like Forge, for instance, which allows addition of custom blocks, entities, etc. However, Bukkit supports changing the behavior of anything that is already in the game. Adding a custom enchantment for only server-side use, which plugins can later read and use (rather than using stupid improvisations, like writing information in the item's lore or using custom NBT tags), won't require new assets for the client (models, sounds, textures, etc. - although this can also be done nowadays through the use of resource packs), but could at the same time extend the functionality of vanilla enchantments in a mod-like way.

1) not aware of any supported method to register custom enchants, what method are you using? The javadocs make it clear that the registerEnchantment method is not for this purpose.
2) then you're special casing the API for something that's not possible via the API
3) this ability is likely to be removed by Mojang at any time (like many many other similar things) because it is essentially a bug. A well designed API should never break as a result of changes from Mojang, but this is literally asking for it.
4) it's not as simple as "stop filtering invalid enchants" - if an enchantment exists and is properly registered it will be fine (how can you expect to store an enchantment when it doesn't exist), but there is no API to properly register enchants because Bukkit doesn't support custom blocks, entities or enchants. If you have an elegant fix you are welcome to submit it. It's not being filtered, the behaviour you are asking for literally isn't part of the Bukkit API because Bukkit is a plugin, not modding platform.

Bukkit does not support custom enchants. There is no way to obtain the stack you are describing via the Bukkit API.

I am aware of that. However, you could obtain it using the /give command or NMS code. Also, the first part is not entirely true. The enchantment class exposes a public method which allows you to register custom enchants.

Allowing such a stack to exist would break plugins which depend on only valid API.

I honestly can't see how that might happen. If the plugins depend only on the Bukkit API, then any method they might use, for instance, the getEnchantments method on an ItemStack, should only return the valid enchantments present on the item, ignoring the invalid ones. It is actually more likely for the current way the API works to break such plugins. Allowing the registration of custom enchantments (don't get me wrong, that's a nice feature and I'm sure I'm not the only one who uses it) through the API might have plugins that expect receiving a list of only vanilla enchants after using getEnchantments actually get a list including one or more custom enchants, which they might not know how to handle.

Therefore, in my opinion, I feel like removing that invalid enchantment filter would not only allow both plugin developers and map-makers to create glowing items (for map-makers that's the only way currently, as they can't register custom enchantments through the API and use the "temporary" fix described by me in my first comment), but wouldn't affect other plugins only depending on the Bukkit API.
Thanks for understanding.

Bukkit does not support custom enchants. There is no way to obtain the stack you are describing via the Bukkit API.
In addition to this, the stack you are describing, when used via the Bukkit API is not compatible with the Bukkit API as it contains enchants which are not part of the Bukkit API. Allowing such a stack to exist would break plugins which depend on only valid API. I don't see any sort of solution to this issue - if you have one you are free to post it.

Because players will be able to see that enchantment, unless I add the HideEnchants flag to the item. In that case, however, players would also not see the enchants they might try to add to the item later, so it's definitely something that wouldn't work.
Another thing that DOES work is to register a custom enchantment, add it to the item and send it to the client. The client won't display the enchant (but will still add the glow), as it will consider it invalid, but on server-side it would be considered valid as it's registered. However, this only seems to me like a temporary fix. I think that filter should really be removed.

Why don't you use an existing enchantment that has no use for the item? Like "Fire Protection" for weapons.