Tags
Creators
Details
5.3.2
Compatibility
Changes
5.3.2
5.3.2 is compared directly with the 5.3.1 release baseline. It keeps the 5.3.0 configuration schema and Relay Protocol 2.2 while refining Poll/Recruitment Events, mobile file handling, minimized/mobile window behavior, personal blocking, and emoji-favorites stability.
Added
- Feature-first multilingual documentation and in-product help: the English Wiki and
docs/en,docs/ko,docs/ja, anddocs/zh-CNnow share a feature-first navigation model. Each feature guide starts with normal use, then configuration/operation, then implementation notes. The Web account panel adds a localized Help button beside Profile that opens the current UI language documentation. Game commands/kchat docs [en|ko|ja|zh]and/kchat wiki [en|ko|ja|zh]expose the same entry points;/kchat wikidefaults to the English Wiki while explicit non-English languages use the localized docs mirror. - Poll multi-select mode: Poll creation can choose single-select or multi-select voting. Multi-select Polls may optionally limit the number of choices per voter;
0means unlimited. Choices are de-duplicated per voter, response-count automatic end continues to count unique voters, persisted selections survive restart, and existing 5.3.1 single-choice Poll data remains readable. - Participant/vote cancellation: Lottery participants may withdraw while registration is still open/ready, First-come participants may withdraw only while the event is still open before capacity auto-completes it, and Poll creation now has a default-ON Allow vote cancellation policy. An allowed Poll voter may fully withdraw the current single/multi selection before close and vote again later; counts and unique-voter auto-end state are updated immediately. Web, Minecraft (
/kchat game leave//kchat game unvote), API, persistence, and Relay action handling use the same lifecycle rules.
Changed
- Recruitment application and confirmation policies: multiple-role application is disabled by default, preserving the 5.3.1 one-active-role behavior; applying to another role changes the existing application. Operators may allow applications to several different roles while duplicate application to the same role remains blocked. When multi-role application is enabled, Recruitment can use either single confirmation (one confirmed role per user) or multiple confirmation (several confirmed roles per user). Role-specific withdrawal and waiting-queue rebalance preserve the user's other applications.
- Private-chat cleanup preview removed: the unreliable DM/Group cleanup-preview counters and preview workflow are removed. Retention periods, locks, actual cleanup, and automatic-delete exclusion remain available.
Fixed
- Mobile multi-file upload omissions: on Android/iOS, public-chat, DM, Group, and administrator-emoji multi-file selections are materialized into stable browser
Filesnapshots immediately after the picker returns and before sequential upload begins. Later provider/content-URI-backed files no longer silently disappear while an earlier file is uploading; per-file read/upload failures remain visible. - Minimized-window movement, restore position, and scroll stability: minimized public chat keeps resize hit targets disabled so the
+restore control remains clickable, while the minimized window itself is draggable. Minimized drag coordinates are transient and never overwrite the normal saved window position; restoring returns to the pre-minimize normal coordinates. Public-chat scroll state is anchored across minimize/restore so repeated collapsing no longer walks visible history upward. - Mobile virtual-keyboard viewport and scroll-anchor handling: public chat keeps its cross-browser visible-viewport guard across
VisualViewport,innerHeight/innerWidth, and the document viewport, including exact embedded-frame restoration after editing. On smartphones/tablets, single-pane DM and Group overlays share the public.kwc-panel, and keyboard focus now captures the active public/DM/Group conversation anchor as one keyboard session. If that conversation was already at the newest messages, every keyboard viewport step keeps the message box/composer following the bottom and restores the bottom state when the keyboard closes; if the reader was browsing older history, the existing message anchor and on-screen offset are preserved instead of forcing a jump to latest. Temporary keyboard-driven scroll changes are not persisted as the normal conversation position. Mobile devices never enter desktop private multi-window solely because of a large screen. - Mobile Jump-to-latest keyboard follow state: public, DM, and Group chat now rebase the active keyboard-session anchor when the user manually scrolls while the composer remains focused. Using Jump to latest may intentionally adopt the bottom as the new keyboard baseline, but scrolling upward afterward immediately cancels that sticky follow state, so later focus/viewport synchronization cannot drag the reader back to the newest message. Jump-to-latest buttons are also re-evaluated after the settled mobile layout so they disappear once the actual latest position is reached.
- Event creation option alignment: Poll multi-select/cancellation controls keep a compact left-aligned option layout. In Automatic end, each condition label stays on the left while its associated value control uses the remaining row space: the response-count field keeps its compact existing width at the right edge, and the date/time field is shortened to fit its native value instead of leaving an oversized control. Labels are vertically centered with their inputs, and the rows still wrap naturally at genuinely narrow mobile/PiP widths.
- DM/Group history navigation parity: private conversations now expose the same localized Jump to latest affordance used by public chat when the reader moves away from the newest messages. A search jump that opens an older retained-history slice records that newer messages are outside the current slice, so Jump to latest reloads the current latest page before returning to the bottom. DM/Group top and bottom history limits continue to use the shared localized
history.endfeedback in both single-pane and desktop Standalone child-window presentations. - Blocked-user names, Relay identity, typing, and history layout: personal-block management strips Minecraft legacy/hex formatting from displayed names, and relayed users now use the same server-scoped
remote~server~UUIDidentity for profile block state, live public-chat delivery, retained history filtering, and Web Push suppression. Blocked users no longer appear in public, DM, or Group typing indicators, already-visible typing state is purged immediately, and blocked public messages contribute zero virtual-scroll height. Block/unblock transitions preserve a visible non-blocked anchor and keep hidden rows out of height/viewport measurement so unblocking no longer corrupts the visible history layout. - Account-wide notification inbox and notification throttling: signed-in users share notification-inbox contents, unread/read state, clear operations, badge count, and inbox lifecycle preference across PC and mobile browsers for the same KWC account. Opening the inbox or merely opening a DM/Group room does not consume that room's stored alerts. Public, DM, and Group notifications are acknowledged only when the exact target message is actually visible; unread and read rows are visually distinguished. By default, Remove inbox notification after viewing its message is enabled, so viewing the target removes only that notification from the inbox. Its checkbox is placed at the bottom of the notification inbox itself, immediately above the bulk actions, rather than in general Chat settings; users may disable it there to retain the row as Read instead. Mark all read remains an explicit non-destructive bulk action, while Clear notifications removes the complete inbox. Ordinary public-chat external notifications now use account-wide idle gating: after the public chat has not actually been viewed for the selected 15/30/60/120-minute interval (default 30), only the first ordinary message emits browser/Web Push attention until public chat is viewed again. Ordinary Group external notifications use a per-room burst gate: the first three unseen messages may emit browser/Web Push attention, while later messages continue to accumulate as unread inbox items without ringing until that room is actually viewed. Group/public keyword alerts, @mentions, and replies use their own category preferences and bypass these ordinary-message gates.
- Account emoji favorites refresh stability: account-backed favorites are no longer cleared by ordinary config/SSE refreshes. A transient favorites preference read failure keeps the last successfully loaded set; logout and actual storage-mode changes remain intentional reset/reload boundaries.
Compatibility
- Bukkit/Paper/Spigot: Minecraft 1.18–26.3
- Fabric: 17 exact targets, Minecraft 1.18.2–26.3
- NeoForge: 13 exact targets, Minecraft 1.20.2–26.3
- Forge: 16 exact targets, Minecraft 1.18.2–26.2
- Deployable release matrix: 47 artifacts. Fabric and NeoForge 26.3 are active exact targets; Forge 26.3 remains preparation-only and excluded pending an exact upstream Forge pin.
- Relay wire compatibility remains protocol major 2; KWC 5.3.2 continues to use revision 2.2.
- Configuration schema/reference remains 5.3.0 because 5.3.2 adds no new operator configuration keys.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:aihWl0Yb:AAuX3Ekc"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:aihWl0Yb:AAuX3Ekc"
}

