I really confused about the error below. I have triple check so it relocate the classes. I can't see any imports use path de.tr7zw.nbtapi.util neither in the mention plug-in or my other api's.

I even debug it inside the Utilitylib-plugin plugin.

System.out.println("MinecraftVersionPackage  " + MinecraftVersion.class.getPackage());
System.out.println("MinecraftVersion clazz  " + MinecraftVersion.class);
//Returns
[23:59:22 INFO]: MinecraftVersionPackage  package org.broken.arrow.pluginutility-api.library.dependencies.nbt.nbtapi.utils
[23:59:22 INFO]: MinecraftVersion clazz  class org.broken.arrow.pluginutility-api.library.dependencies.nbt.nbtapi.utils.MinecraftVersion

[23:59:22 WARN]: [NBTAPI] #########################################- NBTAPI -#########################################
[23:59:22 WARN]: [NBTAPI] The NBT-API inside Utilitylib-plugin is located at 'de.tr7zw.nbtapi.utils'!
[23:59:22 WARN]: [NBTAPI] This package name is reserved for the official NBTAPI plugin, and not intended to be used for shading!
[23:59:22 WARN]: [NBTAPI] Please change the relocate to something else. For example: com.example.util.nbtapi
[23:59:22 WARN]: [NBTAPI] #########################################- NBTAPI -#########################################

<include>de.tr7zw:item-nbt-api-plugin</include>

                <groupId>de.tr7zw</groupId>
                <artifactId>item-nbt-api-plugin</artifactId>
                <version>2.11.3</version>
                <scope>compile</scope>

You are shading the wrong thing, that's why it's tripping the message. It's supposed to trip a different message in this case, but either way it's wrong. See https://github.com/tr7zw/Item-NBT-API/wiki/Using-Maven#option-2-shading-the-nbt-api-into-your-plugin

How does your dependency block in maven look like?

How does your dependency block in maven look like?

I not directly import this inside Utilitylib-plugin(in the maven compile log, it not even find de.tr7zw path).
This is the Utilitylib-plugin: https://pastebin.com/kSRshjug

The api :https://pastebin.com/R5ZPAnKN
The nbt module: https://pastebin.com/GFUCTVUh

If you need more info I do have source code to the api https://github.com/broken1arrow/Utility-Library I don't have the Utilitylib-plugin on github (but it imports from this lib and don't import anything directly self).

Ah right, I think I have the fixed correct warning for people shading the plugin instead of the API currently in the dev branch. So it will be part of the next release/the current snapshots.

<include>de.tr7zw:item-nbt-api-plugin</include>

                <groupId>de.tr7zw</groupId>
                <artifactId>item-nbt-api-plugin</artifactId>
                <version>2.11.3</version>
                <scope>compile</scope>

You are shading the wrong thing, that's why it's tripping the message. It's supposed to trip a different message in this case, but either way it's wrong. See https://github.com/tr7zw/Item-NBT-API/wiki/Using-Maven#option-2-shading-the-nbt-api-into-your-plugin

I'm confused, so I shade wrong part of the library or I'm to tired to connect the dots?

<artifactId>item-nbt-api **-plugin** </artifactId>

Like I state in the documentation:

IMPORTANT: This is not the same artifactId as using it as dependency! Never shade the -plugin artifact!

You are shading the -plugin. That means you get my plugin.yml, nbt-injector and other garbo into your project. You want <artifactId>item-nbt-api</artifactId>, which is the lib designed to be shaded. That also means you need to use the correct imports and relocation pattern described in the documentation.

<artifactId>item-nbt-api **-plugin** </artifactId>

Like I state in the documentation:

IMPORTANT: This is not the same artifactId as using it as dependency! Never shade the -plugin artifact!

You are shading the -plugin. That means you get my plugin.yml, nbt-injector and other garbo into your project. You want <artifactId>item-nbt-api</artifactId>, which is the lib designed to be shaded. That also means you need to use the correct imports and relocation pattern described in the documentation.

🤦‍♂️ tired then, yeah that explain some of the strange behaviour I get. It is a good library you have made, only thing it could be little heavy some methods (if they get called like every 8 tick).

Either way thanks for the support.

Next release will have some performance optimizations for the NBT class, especially when just reading/modifying (block-)entities. You can give that snapshot a try technically. Checking something every 8 ticks sounds a bit... too much?

Next release will have some performance optimizations for the NBT class, especially when just reading/modifying (block-)entities. You can give that snapshot a try technically. Checking something every 8 ticks sounds a bit... too much?

Sounds good. Was to check item get pulled from inventory to hopper, but find other way around it (so it not call item-NBT api so often).

Hm, I guess that only runs if the entity is on an hopper? Then that's not thaaaaat bad. Also checking what exactly, since for the normal hopper/player/entity inventories the spigot API should work well? You can test the dev builds with the improvements by using version 2.12.0-SNAPSHOT and making sure to use NBT.get instead of new NBTItem. Also closing the issue since it's done.

Hm, I guess that only runs if the entity is on an hopper? Then that's not thaaaaat bad. Also checking what exactly, since for the normal hopper/player/entity inventories the spigot API should work well? You can test the dev builds with the improvements by using version 2.12.0-SNAPSHOT and making sure to use NBT.get instead of new NBTItem. Also closing the issue since it's done.

In that case, I'm used it to stop the item from be moved and if it like 30+ different inventory's it will add up fast. Check special set NBT data (not normal meta ).

If you are just setting flags in the persistent data, I'd recommend using the nbt really just as persistent storage(read during chunk load, save during unload), and keep the actual state in a map/set. Then you don't need to check for some boolean or int or whatever every 8 ticks, recreating the nbt of an entity all the time.

If you are just setting flags in the persistent data, I'd recommend using the nbt really just as persistent storage(read during chunk load, save during unload), and keep the actual state in a map/set. Then you don't need to check for some boolean or int or whatever every 8 ticks, recreating the nbt of an entity all the time.

Yeah it was what I did, but needed to retrieve the nbt value also and that I think could not get with spigot api. Either way I use other solution instead.

I will check your snapshot version and see if I can notes the performance difference :)