hoverItem works on every supported version
Three pages still said it throws on 1.17 through 1.18.1. That gap closed when
ItemNbtProvider gained those two tiers, and VersionedComponent's javadoc now
reads "Supported on every version from 1.8".
The Damage limitation below 1.13 is unaffected and stays on both pages that
carry it.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Item text is written upright without a decoration call
KamiCommon suppresses the default italic on custom item names and lore, so the
guidance to turn it off by hand described work the library now does. The
example taught a call that has no effect.
Only the unset case is suppressed, so an explicit request for italics is
honoured, which the replacement says.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Document hoverItem and texttest, and drop the immutable-prototype claim
Nine places said the ItemBuilder prototype is immutable. The reference is final
and the ItemStack is not: the constructor stores the stack it is given without
copying, and getPrototype() returns that same instance, so mutating it changes
every item the builder produces. Checked at pre-v5.0.0-alpha.18 as well, where
the constructor and getter are byte for byte the same, so the alpha.17 page was
not period-accurate either and is corrected rather than left alone.
VersionedComponent#hoverItem had no page at all. Two constraints decide whether
a plugin using it works, so both are stated where a reader meets the method:
it throws on 1.17 through 1.18.1, which have neither the pre-1.17 item NBT nor
an Adventure of their own, and on 1.8 through 1.12 the hover carries id, count
and tag alone, so a top-level Damage value has nowhere to go and red wool
hovers as white. Name, lore and enchantments are inside tag and survive. The
Text page also now says hovers and clicks arrive below 1.18.2, where the
component is handed to the server's own bungee-chat.
/kc texttest is documented beside the other diagnostics on the NmsAPI page,
both modes: the console assertions with their PASS, FAIL and RESULT lines, and
the player pass that answers the question a wire assertion cannot.
Four gaps that the code is now correct enough to describe: the glow methods
and what setGlow(false) does not do, the two drag toggles and their true
defaults, the space-to-underscore rule for modules.<name> and features.<name>,
and the plugins/<plugin>/internal/adventure.jar path a server owner sees below
1.18.2, on both pages that describe the nested jar without saying where it goes.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Drop the em dashes, and stop discouraging a supported shading path
Ninety-six em dashes across seventeen pages, plus four en dashes in version
ranges and a handful of filler words. All removed, rewritten as periods, commas
or restructured sentences rather than swapped for another dash. The formal,
informative tone and the existing page structure are unchanged.
The Spigot module guidance was also wrong in framing. It presented spigot-utils
and spigot-jar as two deployment models where one was recommended and the other
merely tolerated, and said outright that spigot-jar "can be shaded, but you
inherit all 19 MB". Shading spigot-jar is a supported path that works when wired
up correctly, and the page now says so.
There are three options, not two: shade spigot-utils for a smaller payload,
depend on spigot-jar when the plugin is already installed on the server, or shade
spigot-jar to take the whole toolkit in one dependency with no relocation work.
The third gets its own section with the PluginSource wiring, and the Getting
Started decision table gets a third row.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Document v5: entry pages, topic pages, and the changes since alpha.20
The v5 section had no topic pages at all. Its only feature documentation was the
nine v3 pages, which teach APIs that v4 and v5 both replaced, so anyone following
the only documentation that existed wrote code that did not compile. Getting
Started was a placeholder reading "API documentation and getting started content
will be added here".
Fifteen new pages. Three cover setup: how to depend on the library, which of the
six modules to pick, what shading obliges you to do, and the Java 8 floor with its
one Java 11 exception. Seven replace the v3 topic pages for KamiPlugin,
KamiCommand, menus, menu configuration, ItemBuilder, configuration and subsystems.
Five cover ground the wiki has never had in any version: the VersionedComponent
text API, which Adventure a server actually uses and where the 1.18.2 boundary
falls, NmsAPI, Redis and Database.
The migration guide had three entries that were actively wrong rather than
missing. It told readers to update imports to three integration classes that a
later section of the same page said were removed. It presented MaterialData to
XMaterialData as a rename when five things differ, one of them silently because
XMaterialData has no equals or hashCode. And it named the EventManager removal
without saying that no replacement exists, so the seven lines of removed logic are
now published for reimplementation. Four omitted changes were added, of which
AbstractBlockUtil.setBlock is a hard compile break.
Everything after alpha.20 was documented nowhere. Readers coming from 4.0.0 are
routed to the topic pages, since for them it is new capability rather than
renames. Readers who tracked the pre-releases get a dedicated alpha.20 to 5.0.0
guide covering the whole window.
Written as though 5.0.0 is live, so no dated stamps outside the historical
alpha.17 page, version placeholders rather than hardcoded numbers, and the Home
status no longer says active development.
A review against the source caught nineteen defects before this landed, most of
them examples that would not compile: the shading bootstrap was wrong on three
pages, registerModule was documented taking a class when it takes an instance, and
ConfigObserver's package was wrong everywhere it appeared. All are corrected here.
Every internal link and cross-page anchor is verified, including three v3 links
that were missing their v3 prefix.
Co-Authored-By: Claude Code <noreply@anthropic.com>