| Age | Commit message (Collapse) | Author |
|---|
|
Serializing the display name into the legacy text let its color run into
everything after it, and legacy text cannot hold hex colors or hover and
click events, so names styled by other plugins came out wrong. The name is
now spliced into the parsed component instead.
{role} is resolved only when the format uses it, since the default
formats do not and it costs a member scan and a lookup per message.
/lc channel status now shows the same localized role names instead of a
second, hard-coded [OWNER] / [MOD] vocabulary that only one of the two
places translated.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
Placeholder names were spelled as string literals in three handlers, and
each handler also chose its own way of turning the result into a
Component. Adding a placeholder meant finding every call site by hand, with
nothing to catch a format left without its value.
ChatPlaceholder now owns the names, and each format has an entry point whose
parameters are exactly the placeholders it accepts, so the compiler points
at the callers when one is added. Substitution happens in a single pass, so
a value that itself contains "{message}" is no longer replaced again by the
next placeholder. All three formats now deserialize section signs into
styles, which leaves what players see unchanged.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
The fix is a bug fix only, so it goes under a v1.4.1 heading. The tag scheme
notes now say "up to v1.4.0" instead of naming v1.5.0, because the next Paper
release is a patch and the boundary would otherwise point at a version that
may never ship.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
A vX.Y.Z tag used to ship both JARs under the Paper version number, so the
Velocity version never appeared in a tag. Changelog download links guessed
paper/ and velocity/ tags that did not exist and returned 404, and the same
JAR resurfaced under several releases.
Paper now releases on vX.Y.Z and Velocity on velocity/vX.Y.Z, which matches
the CHANGELOG.md headings one to one. Paper keeps the bare form rather than
moving to paper/vX.Y.Z because the update checker in already-deployed Paper
builds only understands that form. Both workflows call a shared reusable
workflow, since the two had drifted into near-identical copies.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
feat: Release LunaticChat v1.4.0
|
|
|
|
A nightly JAR was named after the bare release version, so a build from
main and the release of the same base version were indistinguishable in
the JAR file name, /plugins and bug reports; only build-info.properties
knew the difference, and Velocity does not even ship that file.
The x script tried to express this with -Pversion, but each module
assigns its own version from paperVersion/velocityVersion, so the
override never took effect.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
Changing a message format meant taking the server down, because config.yml
was read once in onEnable and every consumer held the value it was built
with. Operators tune these formats far more often than anything else in the
file, and a restart is a disproportionate price for a colour code.
Only messageFormat is applied. The rest of config.yml settles things once,
at startup - which services exist, which commands and listeners are
registered, which files are opened - and none of that can be redone while
the server runs: Paper registers commands only through its COMMANDS
lifecycle event, Bukkit cannot unregister a listener, and the conversion
cache saver keeps no task handle to cancel. Rebuilding the services would
leave the old ones still wired up, so a changed setting the server cannot
pick up is reported back as needing a restart rather than silently ignored.
MessageFormatHolder is deliberately narrower than LunaticChatConfiguration:
taking it says the value is live, taking the configuration says it was
frozen at startup. A holder over the whole tree would hold a configuration
matching no version of the file, since only messageFormat is ever swapped.
Reload reads config.yml more strictly than startup does, because it has an
option startup does not - leaving the running configuration alone. Startup
falls a single unreadable setting back to its default so the server can come
up; reload refuses the file, names every unreadable setting at once, and
keeps what the server already had. A document holding no settings is refused
for the same reason: it cannot be told apart from a config.yml caught
halfway through being written, and resetting every format over that is worse
than doing nothing.
Closes #266
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
The badge read `v1.3.0~`, pointing at a Velocity release that does not exist.
The feature needs both halves, and the Velocity half first shipped as 1.2.0
inside the unified v1.3.0 release, so a reader hunting for Velocity v1.3.0 finds
nothing and cannot tell which proxy build carries the relay.
Also refreshes the gradle.properties example, which still showed the versions
current when it was written.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
Several statements were wrong rather than merely thin, and each would have set
the wrong expectation:
- the conversion example implied romaji replaces the input, when the result is
appended in parentheses and both are sent
- the handshake was described as happening at startup, when it waits for the
first player to join, so a DISCONNECTED status on an empty server read as a
fault
- cache eviction was called oldest-first, which the unordered in-memory map
cannot provide
- the Velocity settings table omitted crossServerDirectMessage
- ConfigManager was described as reading Bukkit's FileConfiguration, and the
settings storage as recovering from a backup that does not exist
It also documents behaviour that had no mention anywhere: the `!` force-global
prefix, that spy sees channel messages and not only DMs, the nightly build
warnings, the overall 1000ms conversion budget that makes api.timeout above it
ineffective, and the data files the plugin writes.
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
support
Velocity moved to the 4.x generation while platform-velocity still compiled
against 3.5.1, so the debug environment had to pin an older proxy than the one
most users now run.
The migration needed no source changes. Comparing every one of the 213 classes in
the API jar with javap shows 4.0.0 is identical to 3.5.1 in its public
signatures; the supported protocol range is unchanged too. The one real
difference is the POM, which moves adventure-bom from 4.26.1 to 5.2.0.
Support for 3.5.x is dropped even though the JAR would still load there, because
keeping it meant Adventure 4.26.1 could be the runtime and engine had to stay
inside the API surface both Adventure majors share -- a constraint no build step
could check. Narrowing to 4.x makes every supported runtime ship Adventure 5.2.0,
matching what engine already compiles against, so the constraint is gone rather
than merely documented. Nothing enforces the requirement in code, matching how
dropping 3.4.0 was handled in v1.1.0.
Also drops two dead dependencies: kaml, declared but never imported, worth about
1 MB of shaded JAR, and the velocity-api annotationProcessor, which does nothing
without Java sources or kapt.
|
|
Paper 26.2 bundles Adventure 5.2.0, a major bump from the 4.26.1 shipped by 26.1.
Adventure 5 makes ClickEvent generic, so the raw type in
CommandContext.replyWithEvent no longer compiled. Auditing the rest of the
Adventure 5 removals found no other affected usage.
api-version is raised to 26.2, dropping 26.1 support: the two Adventure majors
are not binary compatible, so claiming 26.1 compatibility would be a lie.
Also fixes two problems found while verifying on a real server: the Velocity
healthcheck invoked mc-health, which does not exist in the mc-proxy image, so the
container had never once passed its check; and the debug environments pinned no
build at all, which meant the proxy came up as 4.1.0-SNAPSHOT while the plugin is
compiled against velocity-api 3.5.1. Server versions are now derived by x from
the Gradle coordinates so they cannot drift from what the plugin targets.
|
|
* docs: add developer design/architecture guide (EN/JA)
The docs site covered features and reference but had no entry point for
the codebase's design. Add a Developer Guide section describing the
module structure (engine shared kernel, platform-paper, platform-velocity),
the protocol-version compatibility model, and the Service Container /
Feature Gating pattern, so contributors can understand the architecture
without reading the source first.
Co-Authored-By: Claude <noreply@anthropic.com>
* docs: mirror cross-server DM docs into English (#231)
PR #231 added the cross-server direct messaging feature but updated only
the Japanese docs. Port the same additions to the English pages
(configuration, direct-message, velocity, commands) so both locales stay
in sync.
Co-Authored-By: Claude <noreply@anthropic.com>
* style: apply biome formatting to ja.ts sidebar config
The developer-guide sidebar entries were not biome-formatted, failing the
build_docs CI check (format:check). Apply the formatter.
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
|
