Libraries Updated:

• XSeries (11.0.0) - XSeries removed methods for matching material integer ids. IBuilder has mirrored this change and dropped the constructor support for integer ids.
• NBT-API (2.13.0) - No breaking changes

Other Changes:

• The KamiCommon class has been mostly migrated to PluginSource. KamiCommon is now just a loader when spigot-jar is installed on a server.
• For developers who wish to use KamiCommon without a depend (shading it into your own library) - you can now shade the spigot-jar module and use PluginSource.onEnable/onDisable to enable KamiCommon on your own.

Support for 1.20.5
- Reminder: since 1.17 this API has been built on Paper. For 1.20.5+ it only supports their mojang-mapped runtime.

See github for changes
3.0.0.0 release soon

See github commit log for changes, a few minor changes as the 2.x series is developed for better functionality. Probably will break things if you update from the old 2.0.0 series

- See Github for Details
- Should be no minor/breaking changes

See GitHub for changes

- Incremented major version from 7 to 8
- Simplification of KamiMenu and other menu building classes (BREAKING CHANGES)
- See Github commits for more details.

Migrating from 1.7.x.x to 1.8.2.9:
- PageItem & KamiMenu no longer use generics (must remove <...> when using now)
- PageItem's constructor requires an ItemBuilder, you can wrap existing ItemStacks using new ItemBuilder(itemStack)

-Fixes a bug where doubles would store like "100d" but when retrieving doubles it expected "100D". Now case in-sensitive

Adds 1.20.1 support

See github ( https://github.com/Jake-Moore/KamiCommon/commits/master) commits for details

- Essentially recent updates have updated SnakeYaml to 2.0 and implemented their Node system so that it can detect and save comments from default config streams (resources files) and insert them automatically into the server's config.

Fixes last commit for setting slab types.

View GitHub commit log for details.

See github commit history for details.
1.19.4 supported with latest versions of common

Adds back support for more variations of auto update.

Update v1.6.1
- KamiSubCommands now requires a JavaPlugin object so that the version subcommand can access the appropriate jar file when finding the version.json resource.

-Adds 1.19.4 support for the new 1.19 R3
-Found and fixed a bug with 1.18+ teleporter methods (The name obfuscation varies for >1.17 versions)

Now using what seems to be the standard translations in the form:
&#000000

Fixed converting 1.8.8 to a double
(1.8.8 is now 188)
(1.16.3 is now 1163)
(1.16 is now 1160)

setBlockSuperFast is now better for higher versions.
Found a good way to set 1.17+ blocks.

check github for changes

v1.5.16
- Adds NmsManager.getTeleporter (an ITeleporter) with ITeleporter.teleportWithoutEvent

Would be a good idea, if it could support 1.8 to 1.19.3. Using WE / FAWE is more efficient in that case.

Fixed a typo rendering the XMaterial useless in ItemBuilder
oops

A tiny change in IBuilder, using the XMaterial.parseItem instead of grabbing it's raw material, incase it has byte data on the current version.

Adds NmsManager.getBlockUtil() which returns a IBlockUtil
With the method .setBlockSuperFast(...)

Working on 1.8 variants, skipped logic for 1.9-1.16 (will add later)
Experimental logic for 1.17+

Makes KamiSubCommand.fromName public

Some updates, 1.19.3 compatible.

v1.5.4 - IAItemBuilder.java (allows you to build Items with materials that are IA namespaced ids, if you have IA installed.)

in the config you could do
material: "myitems:item" (namespaced ItemsAdder id)

And it will find the item from ItemsAdder before adding the rest of the details.

Update 1.5.3 - MenuManager's listeners were not being registered when I swapped this to a spigot plugin, fixed.

KamiConfig has been split up into KamiConfig and StandaloneConfig.
The KamiConfig now requires a Plugin object as it is meant for servers with plugins, the StandaloneConfig is meant for jars that aren't related to Minecraft servers.

After thorough review, al classes should be safe to use, if they involve spigot their methods will require some spigot object.
For instance StringUtil has been split as well, StringUtil does not use any bukkit or spigot classes, and can be used in a standalone jar.
StringUtilP on the other hand can translate PAPI placeholders when you use any of the p() methods. They require a player object so you can't mistakenly use them.