v0.2.8-alpha

Silk v0.2.8-alpha

Silk v0.2.8-alpha rebases Silk onto 47 newer Paper 26.3 commits and fixes a startup crash in the
console.

Baseline. This release is built on Paper 26.3 (4728a90), which Paper now marks as beta.
Region threading is still Silk's hand port of Folia ver/26.2.x; Folia has no 26.3 branch yet.

Downloads

File	What it is
silk-paperclip-v0.2.8-alpha.jar	The server. Run this one: java -Xmx4G -jar silk-paperclip-v0.2.8-alpha.jar nogui
silk-bundler-v0.2.8-alpha.jar	Bundler jar with all libraries included
silk-server-v0.2.8-alpha.jar	Module artifact; not launchable on its own
silk-patches-v0.2.8-alpha.zip	Every Silk patch (API, Paper and Minecraft) for this release

Fixes

• Console commands typed while the server is starting no longer throw a
  NullPointerException. The command was queued before the worlds loaded and ran with no level.

From Paper

Notable upstream fixes picked up in this release:

• Hoppers no longer mark the wrong container as changed.
• Bundle contents are no longer corrupted by item obfuscation and shelves.
• Fixed a race that could throw ConcurrentModificationException for post effects.
• BlockBreakEvent no longer misfires in Adventure mode.
• Skipped inbound packets now count toward packet rate limiting.
• Block#getState(boolean) now respects its parameter.
• JLine is updated to 4.4.6.

Changes to Silk's patches

• Folia's guard against removing a player twice on disconnect is now in Paper, so Silk dropped its
  copy.
• Paper replaced the static block-state snapshot flag with a parameter, so Silk's thread-local
  version of that flag was removed.
• The region profiler now depends on leafpile's profiler module, since leafpile is split into
  modules.

v0.2.7-alpha

Silk v0.2.7-alpha

Silk v0.2.7-alpha moves the server to Minecraft 26.3 and renames the server brand to Silk.

Alpha baseline. This release is built on Paper 26.3 (d5cc7d4), which Paper still marks as
alpha. Folia has not published a 26.3 branch, so Silk's region threading was ported forward from
Folia ver/26.2.x by hand, using CanvasMC's dev/26.3 port as a reference. Test on a staging
server before upgrading a live one. The 26.2 line continues on the dev/26.2 branch.

Downloads

File	What it is
silk-paperclip-v0.2.7-alpha.jar	The server. Run this one: java -Xmx4G -jar silk-paperclip-v0.2.7-alpha.jar nogui
silk-bundler-v0.2.7-alpha.jar	Bundler jar with all libraries included
silk-server-v0.2.7-alpha.jar	Module artifact; not launchable on its own
silk-patches-v0.2.7-alpha.zip	Every Silk patch (API, Paper and Minecraft) for this release

Minecraft 26.3

• 26.3 rewrote most entity-targeting commands. /kill, /give, /effect, /enchant, /clear,
  /xp, /recipe, /advancement, /attribute, /spawnpoint, /tag, /posteffect and others now
  run their work on the region that owns each target and reply once every region has finished.
• Commands that touch global state, such as /time, run on the global region.
• The new /compute command is disabled until it has been checked for region safety.
• Spectators clicking a portal (new in 26.3) are teleported through the asynchronous portal path.
• End portal arrival matches 26.3's placement (players stand one block lower than other entities).
• /mspt keeps working through Paper's new brigadier implementation.

Fixes

• Plugins that cancel their tasks on shutdown (e.g. Vault) no longer throw a
  NullPointerException. The legacy scheduler bridge sent internal ownerless tasks to the Folia
  scheduler, which rejects them; they now run inline.
• BukkitScheduler#cancelTasks(plugin) now cancels that plugin's bridged sync tasks.
  Previously they kept running.
• Fixed a crash when a player was created during login, caused by reading a per-region clock
  outside any region.

Branding

The server now reports itself as Silk in the F3 screen, /version and the startup log. The
brand id (tame-gg:silkmc), bStats page and internal names are unchanged, so plugins that check the
brand id are unaffected.

The operator command is now /silk (/silk status, /silk plugins, /silk report,
/silk reload, /silk bench). /silkmc still works as an alias, and the silkmc.command
permission is unchanged.

Plugin compatibility

The CI smoke test now runs with LuckPerms 5.5.85, EssentialsX 2.22.1-dev+24 (the first build that
supports 26.3), Vault 1.7.3, WorldEdit 7.4.6-beta-02 and ProtocolLib 5.4.0, all enabling and shutting
down without errors. WorldEdit 7.4.3 and EssentialsX 2.22.0 and older do not support 26.3.

SilkMC v0.2.6-alpha

SilkMC v0.2.6-alpha

SilkMC v0.2.6-alpha is a threading and correctness release on the Minecraft 26.2 baseline. It
raises the default tick thread count, fixes four region-threading defects in state shared between
regions, restores five vanilla commands, and adds a benchmark harness for measuring region
workloads.

This release changes a default. Servers that have not set threaded-regions.threads will use
more tick threads than before. See below.

Default change: tick thread count

threaded-regions.threads, when unset, now resolves to cores / 4 (minimum 1) instead of the
upstream Folia formula.

Upstream halves the core count and then divides by four, which collapses to a single tick thread on
any machine with 8 or fewer usable cores - and, because 6 / 4 truncates, on 12-core machines as
well. A 32-core machine received 4 threads.

Cores	Before	Now
6 or fewer	1	1
8	1	2
12	1	3
16	2	4
32	4	8
64	8	16

Measured on a 12-core machine with the benchmark harness added in this release - 8 regions running a
mixed hopper, redstone and entity workload requiring roughly 2.4 threads' worth of work - one tick
thread sustained 10.03 TPS while two sustained 19.90. With the new default the same machine
selects 3 threads and holds 19.95 TPS.

The failure this fixes was silent, which is the important part. A region that cannot keep up skips
ticks, and the ticks it does complete are the cheap ones. The single-thread configuration therefore
reported the lowest average MSPT of any configuration tested - 12.8 ms, against 18.1 ms at 8
threads - while running at half speed. An operator diagnosing this with /tps would have seen an
apparently healthy server.

Average MSPT rises with this change (12.81 ms to 14.16 ms on the workload above). That is the
expected result of completing every tick rather than dropping work, not a regression.

cores / 4 leans deliberately high, because the two errors are not symmetric: under-provisioning
cost half the tick rate, while over-provisioning cost only CPU - summed region utilisation rose 1.39
to 1.57 going from 2 to 4 threads at identical TPS. Three quarters of the machine remains available
to the chunk system, Netty, GC workers and the global region.

Setting threaded-regions.threads explicitly continues to override this entirely. Operators who
have already tuned it are unaffected.

Region threading fixes

Four defects in state that is mutated on one region thread and read from others. All four are
correctness fixes; none changes behaviour that was previously correct.

• World border. WorldBorder had no volatile fields, despite being mutated on the global region
  and read by every region thread on movement and collision paths. Because a moving border swaps in
  a new BorderExtent, the unsafely published value was an object reference rather than a scalar,
  so a region thread could observe a partially constructed border.
• Scoreboard objective removal. Removing an objective raced with PlayerScores#getOrCreate,
  which reads without a lock on the criteria hot path. A score could be created for an
  already-removed objective and left behind. Fixed with a publish-then-verify handshake, so the hot
  path remains lock-free.
• Boss bars. ServerBossEvent held a plain HashSet of players and BossEvent's fields were
  non-volatile, while CraftBossBar allows any plugin to mutate a bar from any region thread. This
  affected the Bukkit BossBar API independently of the /bossbar command, so it was reachable
  on any server running a plugin that uses boss bars.
• Legacy scheduler task lifecycle. Sync tasks bridged onto Folia's schedulers were never removed
  from CraftScheduler#runners, because mainThreadHeartbeat is the only path that removes them and
  it does not run under SilkMC. On a server with plugins using runTask and friends, this grew
  without bound.

CraftServer#getTPS and #getAverageTickTime also no longer throw when called off a region thread;
they fall back to the global region's tick data.

Restored commands

/team, /teammsg, /trigger, /tag and /bossbar are available again. Each was assessed for the
state it touches and which thread owns that state, rather than restored because it was commented
out:

• /tag and /trigger may target entities owned by another region, so their targets are filtered
  through the existing region-scoped resolution, which reports what it skipped rather than acting
  cross-region silently.
• /team reuses the existing scoreboard write lock rather than introducing a second concurrency
  mechanism, and team creation is atomic.
• /bossbar depends on the boss bar fix above.

Benchmark harness

tools/benchmark generates a deterministic, client-free region workload and samples the tick
statistics the server already maintains. It has no external dependencies and adds no instrumentation
to the tick loop - the /silkmc bench subcommand only formats windows that are collected on every
region tick regardless.

It reports TPS alongside MSPT, and reports it first, because MSPT alone will report a saturated
server as the healthiest configuration in a matrix.

See tools/benchmark/README.md for what it does and does not measure. It cannot exercise connection
ticking or anything that scales with player count, since those paths require real clients.

Documented, not changed

Investigations that concluded no code change was warranted are recorded rather than acted on:

• Legacy sync scheduler tasks stay on the global region (docs/compatibility.md). This is
  deliberate, not a gap awaiting more context: runTask and friends promise that tasks run in order
  and never concurrently with one another, and the global region is what still provides that.
• Global region scaling limits (docs/architecture.md). PlayerList.tick() is O(n²) in player
  count every 600 ticks, tickConnections() scans all connections even when nearly all are
  region-owned, and autoSaveMaps() performs synchronous disk I/O on the global tick thread. None is
  measurable without connected clients, so none was changed.
• Allocation. Profiling the saturating workload attributes roughly 0.2% of sampled allocation to
  SilkMC and Folia frames; the remainder is vanilla ticking. There is no per-tick allocation hot spot
  in SilkMC's own code to address.
• GC pauses. Reducing the young generation from the sizing in docs/benchmarking.md roughly
  halves the worst stop-the-world pause (119 ms to 65 ms). Whether that improves the observed tick
  tail is not established - a first pair of runs suggested it did and a confirmation pair showed
  no difference - so no default was changed and no tail-latency improvement is claimed.

Upgrade notes

• Servers that have not set threaded-regions.threads will use more tick threads. On machines with
  8 or more cores this should raise sustained TPS under load; average MSPT will typically rise with
  it, as described above.
• Set threaded-regions.threads explicitly to keep the previous behaviour.
• No API changes. No configuration keys added or removed.

v0.2.5-alpha

SilkMC v0.2.5-alpha

SilkMC v0.2.5-alpha is a correctness release on the Minecraft 26.2 baseline. It fixes the
plugin compatibility scanner refusing to load correct plugins, removes off-region game state
access from the status bars added in v0.2.2-alpha, and adds the project's first unit tests.

There are no new features and no configuration changes.

Behaviour change: correct plugins are no longer refused

The compatibility scanner classified plugins by searching the raw bytes of every class in the jar
for text such as isPrimaryThread or org/spigotmc/AsyncCatcher. Raw bytes include string
literals, resource names and every other piece of text in the constant pool, so a jar that merely
mentioned one of those - in a log message, a config key, or a shaded library - matched.

The consequence was not a bad classification but a refusal to start. isPrimaryThread produced an
UNSAFE classification, and UNSAFE is a hard block. A plugin that called
Bukkit.isPrimaryThread() defensively, or shaded any library that named it, was rejected outright
with no way to tell a real hit from a coincidence except an operator override.

The scan is now structural. Each class is parsed and only genuine symbol references are considered:
supertypes and interfaces, field and method descriptors, and the owner and name of every
instruction that touches a type or calls a method. Text in a string constant or a resource is no
longer a signal.

The classification boundaries moved with it:

• UNSAFE now means a real reference to org/spigotmc/AsyncCatcher, which has no purpose other
  than disabling the thread checks the server depends on. This remains a hard block.
• A call to isPrimaryThread() is now UNKNOWN rather than UNSAFE. The usual reason to ask
  whether you are on the main thread is to be careful about threading; that deserves an operator's
  attention, not a refusal. Under the default WARN policy such plugins now load with a warning.
• A jar that cannot be read, or a class that cannot be parsed - for example one compiled for a
  newer class-file version than the server's bytecode reader knows - is now UNKNOWN with an
  explicit reason. Previously an unreadable jar aborted plugin loading with a raw exception, and
  the absence of signals from unparseable classes was indistinguishable from a clean scan.

Operators running with unsupported-plugin-mode: REQUIRE_DECLARATION should expect to see plugins
that previously failed as UNSAFE now appear as UNKNOWN, which that mode still blocks. Under the
default WARN mode they will load.

Force-loading a plugin classified UNSAFE now always logs a warning. Previously the only trace was
an informational line, despite it being the riskiest thing an operator can configure here.

Fix: status bars no longer read game state off-region

/tpsbar and /rambar, added in v0.2.2-alpha, refreshed every tracked player from a single
private daemon thread that owned no region. Once a second it called getWorld(), getLocation(),
getPing() and showBossBar() on players being ticked concurrently by their own regions, and
looked each player's chunk up in the regioniser to find tick data - the exact pattern SilkMC
classifies third-party plugins as unsafe for.

Each tracked player now drives their own refresh loop through their entity scheduler, so every read
happens on the region that owns that player. The scheduler follows the player across region splits,
merges and dimension changes, and retires the loop on disconnect. Because the callback already runs
on the player's region, the tick report is read from the region being ticked rather than looked up
by position, which also closes the window where a player had moved to a different region than the
one being reported.

A supervisor thread still ticks once a second, but it touches no game state: it hands a task to the
global region, which owns the player list and can safely arm a loop for anyone who has opted in but
is not running one. Toggles from the two commands are funnelled onto the owning region as well,
which removes a race that could show a player two overlapping bars.

Fix: files are resolved against the server directory

silkmc-compatibility.yml, silkmc-plugin-overrides.yml and the status bar opt-in file
silkmc-status-bars.json were opened by bare relative name, which resolves against the process
working directory rather than the server directory. These are usually the same. When they are not,
the server read and created defaults in a different set of files from the ones sitting next to
server.properties, and /silkmc reload reported success having reloaded nothing the operator had
changed. All three now resolve against the server directory.

The status bar file is also written through a temporary file and moved into place, so losing the
process partway through a write can no longer leave a truncated file. A half-written file does not
parse, which previously dropped every player's opt-in rather than just the toggle in flight.

Fix: scoreboard registry pruning

The weak registry of plugin scoreboards, added in v0.2.4-alpha, removed collected entries as an
iterator encountered them. That is correct but each removal copies the whole backing array, so a
single criteria update after a mass disconnect walked it quadratically on a region thread, with
every region contending on the same copy-on-write lock.

Cleared references are now enqueued by the collector and removed as one batch when a scoreboard is
next registered. Iteration - the hot path, reached by every health, death and kill-count update -
only skips them. Registering the same scoreboard twice is now also a no-op; previously it applied
every criteria update to that scoreboard twice.

Fix: locale-dependent policy parsing

unsupported-plugin-mode was uppercased using the host's default locale before being matched. Under
a Turkish locale require_declaration uppercases to REQUİRE_DECLARATION, which does not match,
and the parse fell back to WARN. A server configured to require explicit compatibility metadata
silently stopped requiring it depending on where it was running.

Compatibility failure reporting also walked a plugin's exception cause chain with only a
single-hop cycle guard, so a cyclic cause chain could hang the reporting thread while the server
was already handling a failure. The walk is now bounded.

Tests

SilkMC's own logic now has unit tests - 50 of them, run by ./gradlew build and therefore in CI on
every push and pull request. They cover the compatibility scanner (including the string-constant
false positive above, as an explicit regression test), the classification rules, the weak scoreboard
registry under concurrent readers and writers, and the status bar formatting and thresholds.

This matters more than the count suggests: SilkMC is maintained as a patch set rebased onto upstream
Folia, and this is the logic most likely to break quietly during a version bump.

Upgrade notes

Drop-in. No configuration changes are required.

Operators who added silkmc-plugin-overrides.yml entries to work around the scanner rejecting a
plugin should re-check whether they are still needed - many were compensating for the false
positives fixed here. Overrides that are no longer needed can be removed; /silkmc report <plugin>
shows the classification a plugin now receives.

Anyone launching the server from a directory other than the server directory should move
silkmc-compatibility.yml, silkmc-plugin-overrides.yml and silkmc-status-bars.json next to
server.properties if they are not already there.

v0.2.4-alpha

SilkMC v0.2.4-alpha

SilkMC v0.2.4-alpha builds on the Minecraft 26.2 baseline from v0.2.3-alpha and restores
the Bukkit/Paper scoreboard API, which has been unavailable since the fork inherited Folia's
region threading. Plugins that use scoreboards now work without SilkMC-specific code, and the
vanilla /scoreboard command is available again with region-aware selectors.

Feature: the Bukkit scoreboard API works again

Folia disabled the scoreboard API behind five UnsupportedOperationException guards, so any
plugin calling Bukkit.getScoreboardManager().getNewScoreboard(), registerNewObjective,
registerNewTeam, clearSlot, or Player#setScoreboard failed outright. Scoreboard
synchronisation on join, scoreboard cleanup on entity removal, and the player-collision team
were commented out for the same reason.

The implementation itself was never missing. The blocker was thread safety: Scoreboard,
PlayerScores, PlayerTeam and Score store their state in non-concurrent collections and
non-volatile fields, and every region thread reaches that state. The registry of plugin
scoreboards was an ArrayList-backed WeakCollection walked on every criteria trigger.

Notably, this was already a live problem before this release rather than only a
plugin-facing one: criteria objectives such as health, deathCount and playerKillCount
have always updated the main scoreboard from region threads through those same
non-concurrent collections. Disabling the plugin-facing API never made that safe.

What changed

Scoreboard state is now held in concurrent collections, with a per-scoreboard lock used only
for compound structural mutations - creating an objective, moving a player between teams,
removing an objective - so those stay atomic without reintroducing a global server thread. No
packets are sent while that lock is held.

Region-owned side effects are scheduled rather than run inline. Waypoint reconnection, which
touches world state owned by a specific region, is routed through the affected player's task
scheduler. Assigning a scoreboard to a player flips the assignment immediately, so
getScoreboard() is coherent for the caller, but orders the teardown-and-resync packet burst
on that player's owning thread so it cannot interleave with join synchronisation or a
concurrent switch.

Packet broadcast is left direct, since the player list is copy-on-write and channel writes are
thread-safe. AsyncCatcher is retained, so scoreboard calls from genuinely asynchronous
plugin threads are still rejected exactly as on Paper.

Scoreboard synchronisation on join has been restored, and now sends the player's own board
rather than the level's, so a scoreboard assigned during PlayerJoinEvent is honoured.

Feature: /scoreboard is available again, with region-scoped selectors

The vanilla /scoreboard command was disabled entirely. It is now registered.

Scoreboard state is safe to touch from any region thread, but a score holder that is a live
entity is not - selector resolution walks every level, and neither the selector nor the entity
getters assert region ownership, so an unfiltered @a or @e reads entity state that another
region may be ticking concurrently.

Every /scoreboard subcommand resolves its targets through ScoreHolderArgument, so the
scoping is applied at that single point. Score holders that are not entities - plain names,
#hidden names, offline players, the * wildcard - carry no entity state and always pass,
which covers the overwhelming majority of scoreboard usage. Entity holders are kept only when
the executing thread owns them. A command that matches some out-of-region entities reports
what it skipped; one that matches only out-of-region entities fails rather than silently
doing nothing.

This also covers /execute ... score, which shares the same argument type and was already
enabled with its selectors unguarded.

/team and /trigger remain disabled.

Behaviour change: player collisions

Paper's enable-player-collisions: false option works again. The collision team it relies on
was being created, but the code adding and removing players from it was disabled under region
threading, so the setting silently had no effect. Servers that set this option to false and
had grown used to collisions remaining on will now see collisions actually disabled.

Upgrade notes

No configuration changes are required. Plugins that were shipping SilkMC-specific workarounds
for the missing scoreboard API can drop them; the standard Bukkit/Paper API is the supported
path.

v0.2.3-alpha

SilkMC v0.2.3-alpha

SilkMC v0.2.3-alpha builds on the Minecraft 26.2 baseline from v0.2.2-alpha and
hardens the plugin lifecycle so that a plugin which fails to enable can no longer spam the
console with a second, misleading crash while it is being torn back down.

Fix: cascading onDisable failures no longer look like a crash

When a plugin's onEnable throws, Paper immediately disables the plugin again by calling its
onDisable. A plugin that failed partway through onEnable is only half-initialised, so its
own shutdown logic very often trips over its own uninitialised state and throws a second
exception — most commonly a NullPointerException on a field that onEnable never got to
set. Before this release SilkMC logged that follow-up failure as a raw SEVERE stack trace,
which reads like an independent crash even though the server has already handled the situation.

A representative example is NoChatReports v2.7.8, which could not resolve an NMS provider
for this SilkMC/Minecraft version. Its onEnable failed, and the subsequent
Paper-initiated disable then hit:

Error occurred while disabling NoChatReports v2.7.8
java.lang.NullPointerException: Cannot invoke
  "com.tcoded.nochatreports.nms.NmsProvider.getChannelInjector()"
  because "this.nmsProvider" is null
    at com.tcoded.nochatreports.plugin.NoChatReports.onDisable(NoChatReports.java:167)
    ...

What changed

SilkMC now recognises this shutdown exception as a cascade of the enable failure that was
already reported, rather than a new, actionable problem:

• When a plugin throws during enable, SilkMC flags it (SilkPluginCompatibility.markEnableFailed)
  right before Paper disables it.
• If that same plugin then throws from onDisable during the immediately following disable,
  SilkMC (SilkPluginCompatibility.handleDisableFailure) logs a single, concise, operator-facing
  line explaining that the shutdown error is a side effect of the earlier enable failure, is
  safe to ignore, and that the server has disabled the plugin and kept running. The raw stack
  trace is kept at FINE so the default console stays clean, while remaining available when
  SilkMC debug logging is enabled.
• Disable failures for plugins that enabled successfully are unchanged — they still log at
  SEVERE with the full stack trace, so genuine shutdown bugs are not hidden.

This does not make an incompatible plugin work — NoChatReports still needs a build that
supports this SilkMC/Minecraft version — but the server no longer prints a scary second
stack trace, and other plugins continue to enable normally.

Notes

• The Minecraft 26.2 baseline (mcVersion/apiVersion 26.2, Paper base
  2717585e686d7d294cabce9f1753280780ecf847) and all 26.2 region-threading patches and
  compatibility features from v0.2.0-alpha through v0.2.2-alpha are preserved and
  unchanged.
• The change lives in the maintained SilkMC compatibility layer
  (gg.tame.silkmc.server.compat.SilkPluginCompatibility) and the plugin lifecycle hook in
  io.papermc.paper.plugin.manager.PaperPluginInstanceManager
  (patch silkmc-server/paper-patches/features/0008-SilkMC-compatibility-improvements.patch).

Build

$env:JAVA_HOME='C:\Program Files\Eclipse Adoptium\jdk-25.0.2.10-hotspot'
$env:Path="$env:JAVA_HOME\bin;$env:Path"
./gradlew applyAllPatches
./gradlew build
./gradlew :silkmc-server:createPaperclipJar

Run with:

java -Xms4G -Xmx4G -jar .\silkmc-server\build\libs\silkmc-paperclip-26.2.local-SNAPSHOT.jar nogui

v0.2.2-alpha

SilkMC v0.2.2-alpha

SilkMC v0.2.2-alpha builds on the Minecraft 26.2 baseline from v0.2.1-alpha and
adds live server-health boss bars for quick, in-game performance observability.

New: server-health boss bars

Two opt-in boss bars can now be toggled per player, giving operators an at-a-glance read on
how well the server (and the player's own region) is holding up — handy for testing,
benchmarking, and load checks without leaving the game. Each bar is toggled independently.

• TPS bar (/tpsbar) — shows TPS, MSPT, and the player's Ping. The TPS and MSPT
  values are read from the tick data of the region the player is standing in (Folia region
  threading), falling back to the global region schedule when the player is not inside a
  ticking region.
• RAM bar (/rambar) — shows used/max heap and the corresponding percentage, sourced
  from the JVM heap at runtime.
• The bar text, gradient value colors, thresholds, and byte formatting match
  SerlithNetwork/PurpurBars (which mirrors
  Purpur's TPS/RAM bars): gray labels with yellow colons, green→yellow→red gradient values,
  and a green/yellow/red bar color. Bars refresh once per second on a shared daemon thread,
  off the region threads, so enabling them does not add work to server ticks.

Credit

The bar rendering (text format, gradient colors, thresholds, and byte formatting) is adapted
from SerlithNetwork/PurpurBars by the Serlith
Network (MIT), which brings Purpur's TPS/RAM bars to non-Purpur servers.

Usage

/tpsbar
/rambar

Run either command to toggle that bar on; run it again to hide it. Both commands require the
silkmc.bars permission (default: OP). Only players can toggle the bars.

Each player's enabled bars are persisted to silkmc-status-bars.json in the server
directory, so they survive disconnect/reconnect and full server restarts — a player who had
/tpsbar, /rambar, or both enabled will have them re-shown automatically when they rejoin,
including after a reboot.

Notes

• The Minecraft 26.2 baseline (mcVersion/apiVersion 26.2, Paper base
  2717585e686d7d294cabce9f1753280780ecf847) and all 26.2 region-threading patches from
  v0.2.0-alpha / v0.2.1-alpha are preserved and unchanged.
• The feature is implemented within the maintained SilkMC server module
  (gg.tame.silkmc.server.bars.ServerStatusBars, with the TpsBarCommand and
  RamBarCommand commands registered alongside the existing SilkMC commands).

Build

$env:JAVA_HOME='C:\Program Files\Eclipse Adoptium\jdk-25.0.2.10-hotspot'
$env:Path="$env:JAVA_HOME\bin;$env:Path"
./gradlew applyAllPatches
./gradlew build
./gradlew :silkmc-server:createPaperclipJar

Run with:

java -Xms4G -Xmx4G -jar .\silkmc-server\build\libs\silkmc-paperclip-26.2.local-SNAPSHOT.jar nogui

v0.2.1-alpha

SilkMC v0.2.1-alpha

SilkMC v0.2.1-alpha is a rebuild on the Minecraft 26.2 baseline. It carries forward
the full 26.2 rebase from v0.2.0-alpha.

Notes

• An earlier revision of these notes claimed a fix for /help, /pl, etc. rendering
  red/unknown. That claim has been retracted: the change (switching
  Commands.sendCommands from taskScheduler.schedule(..., null, 1L) to
  taskScheduler.scheduleOrExecute(...)) is a no-op for this code path — the command
  tree is built on an async pool thread, where scheduleOrExecute simply falls back to
  the same schedule(..., null, 1L) behavior. The red/unknown command symptom is not a
  SilkMC backend issue.
• The Minecraft 26.2 baseline (mcVersion/apiVersion 26.2, Paper base
  2717585e686d7d294cabce9f1753280780ecf847) and all 26.2 region-threading patches and
  API-break fixes from v0.2.0-alpha are preserved and unchanged.

Build

$env:JAVA_HOME='C:\Program Files\Eclipse Adoptium\jdk-25.0.2.10-hotspot'
$env:Path="$env:JAVA_HOME\bin;$env:Path"
./gradlew applyAllPatches
./gradlew build
./gradlew :silkmc-server:createPaperclipJar

Run with:

java -Xms4G -Xmx4G -jar .\silkmc-server\build\libs\silkmc-paperclip-26.2.local-SNAPSHOT.jar nogui

v0.2.0-alpha

SilkMC v0.2.0-alpha

SilkMC v0.2.0-alpha rebases the project onto Minecraft 26.2, moving up from the
previous 26.1.2 baseline. All compatibility infrastructure from the v0.1.x line
(compatibility policy, per-plugin overrides, the /silkmc operator command, and the
scheduler bridge) is preserved.

Highlights

• Upstream baseline moved from Folia 26.1.2 to Folia 26.2 (ver/26.2.x).
• Paper base bumped to 2717585e686d7d294cabce9f1753280780ecf847.
• All maintained region-threading patches regenerated against the 26.2 sources.
• Locator-bar / region-threading waypoint support carried forward and fixed for 26.2.
• Two 26.2 API-break fixes applied to SilkMC code (see below).

Minecraft 26.2 update

• mcVersion and apiVersion are now 26.2.
• Folia's regenerated 26.2 region-threading base and feature patches were adopted
  wholesale where SilkMC tracked them unchanged (0001–0008 minecraft feature
  patches, the server/api build.gradle.kts and TPS/watchdog/build paper patches).
• SilkMC-only patches were rebased onto the new base:
  • 0009 Restore locator bar and region threading fixes (minecraft feature patch)
  • 0008 SilkMC compatibility improvements / 0009 SilkMC operator command
    (paper patches).

Bug fixes for 26.2 API changes

• Region status MSPT read-out: SilkPluginCompatibilityManager referenced
  ca.spottedleaf.moonrise.common.time.TickData, which no longer exists after the
  26.2 leafpile repackaging. Updated to ca.spottedleaf.common.time.TickData so
  /silkmc status and the status line continue to report worst-region MSPT.
• Waypoint distance scheduling: RegionThreadingWaypointManager accessed the now
  protected Entity.random field directly, which fails to compile on 26.2. Switched
  to the public Entity#getRandom() accessor.
• Respawn-anchor charge on cross-region respawn: the carried-forward respawn-anchor
  charge consumption is now routed through moonrise$loadChunksAsync so the charge is
  consumed on the owning region thread after the respawn completes.
• Legacy sync teleport bridge: CraftPlayer#teleport0 no longer leaves unreachable
  upstream teleport code after the compatibility bridge returns.

Build

$env:JAVA_HOME='C:\Program Files\Eclipse Adoptium\jdk-25.0.2.10-hotspot'
$env:Path="$env:JAVA_HOME\bin;$env:Path"
./gradlew applyAllPatches
./gradlew build
./gradlew :silkmc-server:createPaperclipJar

Run with:

java -Xms4G -Xmx4G -jar .\silkmc-server\build\libs\silkmc-paperclip-26.2.local-SNAPSHOT.jar nogui

v0.1.7-alpha

SilkMC v0.1.7-alpha

SilkMC v0.1.7-alpha is a small maintenance release that corrects a plugin-compatibility logging defect and tidies up the release tooling.

Highlights

• Fix an inconsistent dedup key in the plugin compatibility warning tracker. The metadata path recorded the raw plugin name in WARNED_PLUGINS while the bytecode-inspection path recorded the normalized (trimmed, lowercased) name, so the same plugin could emit duplicate "not silk-supported" warnings and case variations of a name were treated as distinct. Both paths now normalize consistently.

Maintenance

• Point the release workflow at the matching release notes (body_path) instead of the stale v0.1.5-alpha file.

Notes

• No plugin compatibility behavior changed beyond the warning dedup fix; classification, enforcement, and override handling are unchanged.
• Region-threading and locator-bar behavior from v0.1.6-alpha are unaffected.