DyClaim 1.0.3 — Folia Support and Claim Management Improvements

DyClaim 1.0.3 introduces a dedicated Folia build and expands the existing command-based claim management workflow. Connected claims can now share an outline, claim lists support filters, claim information explains your effective access, and administrators can generate a concise diagnostic summary.

This release also updates scheduling, shared state, confirmations, acquisition reservations and transaction coordination to support Folia’s region-based execution model.

The familiar experience remains: no required GUI, automatic English and Turkish language support, configurable protection, and optional integrations.

Zero bloat. The new management tools extend commands you already use.

---

Dedicated Folia Build

A complete backend for Folia servers

DyClaim now provides two separate distributions:

Server software	File
Bukkit, Spigot, Paper and Purpur	DyClaim-1.0.3.jar
Folia	DyClaim-1.0.3-Folia.jar

The Folia build contains the claim system itself. It is not a companion plugin and does not require the standard DyClaim JAR.

Install only one DyClaim build on each gameplay server.

Both builds share the same claim data format, English and Turkish command structure, protection settings and configuration system.

Native scheduling

The Folia distribution uses native entity, region, global and asynchronous schedulers according to the work being performed.

This separates operations that belong to different server contexts:

• Player messages, effects and player-specific tasks run through the player’s scheduler.
• Terrain inspection runs on the region responsible for the relevant chunk.
• Entity removal runs through the affected entity’s scheduler.
• Plugin-wide coordination uses global scheduling where appropriate.
• Update requests continue to run asynchronously.

The standard distribution retains Bukkit scheduling.

Region-aware protection lookups

Claim boundary lookups now use stored world and chunk coordinates in paths where obtaining a live chunk is unnecessary.

This supports protection checks around neighbouring claims without requiring an unrelated chunk lookup merely to identify ownership.

Existing protection rules remain configurable. This change does not introduce a new claim format or replace the established protection settings.

Cross-region player information

Folia protection decisions involving players in different regions now use player information published from the appropriate owning context.

This includes the player’s claim position and bypass permission state.

When a remote PvP participant does not have an available ownership-context snapshot, the affected interaction is conservatively blocked instead of reading that player’s live state from an unrelated region.

Platform requirements

Optional integrations still need to support the selected server platform themselves.

A Folia-compatible DyClaim build does not automatically make every Vault economy provider, protection plugin or Bedrock integration compatible with Folia.

---

Connected Claim Outlines

View connected land as one area

/claim see can now display a joined outline around nearby, side-connected claims belonging to the same primary owner.

Previously, adjoining claimed chunks were visualized individually. This could leave internal chunk edges visible throughout a larger property.

The new outline hides those internal edges.

For example, two neighbouring claims owned by the same player are displayed as one connected area instead of two separate chunk boxes.

Ownership and connection rules

Claims are joined only when they:

• Belong to the same primary owner.
• Exist in the same world.
• Connect through a complete chunk side.
• Fall within the bounded local outline search.

Claims touching only at a corner are not joined.

Trust and coownership do not make claims with different primary owners part of the same outline.

Bounded local search

Outline discovery is limited to a local search extending at most eight chunks in each direction.

This is a nearby visualization tool rather than a whole-world claim map.

Large properties may extend beyond the search or display distance. When that happens, clipping does not create a false ownership boundary at the edge of the searched area.

Java particle rendering

Java visualization retains its existing duration, distance and particle limits.

For longer outlines, particle sampling rotates through the available boundary positions within the rendering budget. A larger connected property therefore does not require every boundary point to be emitted at once.

Bedrock block rendering

The optional Floodgate visualization path also supports connected outlines.

Temporary block borders:

• Use a bounded set of at most 256 positions.
• Respect the configured display distance.
• Check the player’s current position when queued display work executes.
• Read terrain in the responsible region.
• Avoid loading terrain solely to display the outline.
• Restore client-side block changes when the view closes.

Distance checks also apply to queued callbacks, addressing a case where a connected outline could otherwise send temporary blocks beyond the configured radius.

Bedrock rendering was covered by automated fixtures for this release; live Bedrock client acceptance testing was not performed.

---

Claim List Filters

Find claims without changing their numbers

/claim list now supports optional filters for claim names, worlds and marketplace status.

The original commands remain valid:

• /claim list
• /claim list 2

Filters extend the same command rather than introducing a separate management interface.

Filter by name

Use:

/claim list name home

Name matching is case-insensitive and searches for the supplied text within the claim name.

A distinctive part of a name can therefore be used without entering the complete name.

Filter values occupy one command argument. When searching a name containing spaces, use a distinctive word from that name.

Filter by world

Use:

/claim list world world_nether

The world filter matches the full stored world name, case-insensitively.

Actual world names are not translated.

Filter by sale status

Use:

• /claim list sale all — include listed and unlisted claims.
• /claim list sale listed — show claims listed for sale.
• /claim list sale unlisted — show claims without an active listing.

This changes which claims appear in the list. It does not create, cancel or modify marketplace listings.

Combine filters

Filters can be combined, with an optional page number before them.

Examples:

• /claim list world world_nether sale listed
• /claim list name home sale unlisted
• /claim list 2 world world sale unlisted

Invalid, duplicate or incomplete filters are rejected rather than silently producing an unintended query.

Stable teleport indices

Filtering does not renumber claims.

A filtered result might show claims 2, 7 and 12 because those numbers still correspond to the unfiltered teleport list.

This keeps:

/claim tp <number>

consistent with the number displayed beside each claim.

Filtering changes presentation only. It does not change ownership, stored claim order or teleport destinations.

English and Turkish support

Filter words and sale-status values support localized English and Turkish forms, including supported ASCII alternatives for Turkish input.

Examples:

• /claim liste isim ev
• /claim liste dünya world_nether
• /claim liste satış satışta

Help and TAB suggestions follow the effective language and existing permission filtering.

Both languages remain accepted when typed.

---

Personal Access Information

Understand what you can actually do

/claim info now includes a personal access summary for the player viewing the claim.

The summary shows the viewer’s role and effective access to:

• Building.
• Containers.
• Doors.
• Trapdoors.
• Redstone interactions.
• Protected entity interactions.
• Claim teleportation.

Effective permissions

The displayed rights are calculated through the same access policy used by protection.

This means the summary can account for applicable ownership, trust, bypass, clan access and public-door rules.

It is not simply a copy of one stored trust entry.

For example, a player may have access to public doors while still being denied container access. The information display reflects that distinction.

Remaining temporary trust

When the viewer has an active temporary player trust grant, claim information also shows its remaining duration.

This helps players distinguish temporary access from permanent trust.

Visitor privacy

The personal summary does not expose other players’ trust entries to visitors.

It explains the viewer’s own effective access without turning claim information into a public list of everyone’s permissions.

---

Administrator Diagnostics

A concise support command

Added:

/claim admin diagnose

Turkish aliases:

• /claim admin tanı
• /claim admin tani

The command supports permitted players and the server console.

It requires:

dyclaim.admin

Included information

The diagnostic summary reports:

• DyClaim version.
• Active distribution.
• Claim storage write status.
• Claim count.
• Economy availability.
• Enabled optional integration plugin names.

Help and TAB follow the effective language and permission rules.

Read-only output

Diagnostics do not:

• Execute an economy transaction.
• Rewrite claim data.
• Upload information remotely.
• Display credentials.
• Display filesystem paths.
• Print raw provider exceptions into the summary.

An integration appearing in the output means it is installed and enabled. It does not certify that its version or API behaviour has been tested successfully.

---

Confirmations and Ownership Operations

Single-consumption confirmations

Pending confirmation storage now supports concurrent access.

Confirming, denying or expiring an action consumes the specific pending action atomically, so competing callbacks cannot both consume the same confirmation successfully.

Recipient-owned invitation delivery

On Folia, invitations and other pending actions intended for a player are installed through that player’s owning scheduler when necessary.

Queued delivery checks whether:

• The queued offer is still current.
• The player remains online.
• The manager’s lifecycle generation still matches.

This prevents an outdated queued invitation from being installed after it has been replaced or invalidated.

Lifecycle invalidation

Clearing confirmations invalidates deferred deliveries as well as installed pending actions.

Claim-specific cancellation also removes matching deferred offers.

Ownership and coowner checks

Ownership and coowner mutations now coordinate with claim state and transaction reservations.

Coowner changes verify the expected owner and claim revision before applying the change.

Transfers retain the existing ownership-transfer behaviour while updating ownership and access state through a coordinated operation.

---

Acquisition and Transaction Coordination

Pending acquisitions count toward limits

Acquisition checks now account for in-progress reservations.

Concurrent acquisition attempts therefore consider both existing ownership and relevant pending operations when checking:

• Total claim limits.
• Per-world claim limits.
• Configured spacing.
• Whether the target claim is already involved in another operation.

Spacing during ownership changes

Spacing checks also account for pending ownership changes.

A transfer that has not completed does not grant an early same-owner spacing exemption to either party.

Per-claim transaction reservations

Financial and ownership operations can reserve the affected claim before proceeding.

The reservation is handed over to the persistent transaction entry when execution starts.

A reservation cannot be consumed repeatedly to start multiple transactions.

Protected mutations

Claim removal, transfer and coowner changes respect active transaction ownership.

Unrelated operations cannot mutate a transaction-locked claim simply because the claim object is still available in memory.

Journal coordination

Transaction journal access and stage updates are coordinated separately from external economy callbacks.

A failed stage write retains the previous in-memory stage.

Unresolved entries remain available for reconciliation, and uncertain provider outcomes are not automatically replayed after restart.

Economy uncertainty isolation

Economy response uncertainty is now tracked per execution thread.

Concurrent operations no longer share one global uncertainty flag that could be overwritten by another region’s payment attempt.

Startup without Vault

Fixed an optional-dependency linkage issue where an eagerly bound provider method reference could prevent startup when Vault was absent.

Core claiming remains available without Vault. Economy-dependent functionality still requires a suitable active provider.

---

Claim Storage and Reload Consistency

Coordinated claim state

Claim collection access, ownership indexes and persistence operations have been updated for concurrent execution.

Collection readers receive a stable map snapshot instead of a live unmodifiable view of the changing claim map.

Insertion revalidation

Claim creation rechecks the target before committing the new claim after external provider lookup.

This addresses the interval in which another operation could occupy or lock the same target.

Coordinated JSON writes

Writes targeting the same normalized file path are coordinated across the temporary-file, backup and replacement sequence.

This protects those file operations from competing writes using the same destination.

Complete message catalogues

English and Turkish message catalogues are now prepared before being published together.

Readers retain the previous complete catalogue while replacement files are being loaded, rather than observing maps that have been cleared and only partially repopulated.

Configuration snapshots

Runtime configuration access has been adjusted to support consistent snapshots across concurrent readers and reload operations.

The claim data schema remains unchanged.

---

Teleportation and Background Tasks

Region-aware destination inspection

The Folia teleport flow separates destination terrain inspection from player-owned work.

Player permission and access checks run in the player context; destination safety reads run in the destination region.

Revalidation during teleportation

Pending teleport requests retain the target claim identity and check that the target still exists.

Permissions and teleport access are rechecked during the flow, including after warmup.

The destination is resolved again before transfer instead of relying solely on the initial lookup.

Cancellation and effect ownership

Scheduled handles and temporary blindness effects are tracked per request.

Cancellation and cleanup are coordinated so an older request does not remove the effect state belonging to a newer request.

Once a native teleport has already been accepted, cancelling DyClaim’s callbacks does not guarantee cancellation of the native transfer itself.

Region-aware visitor ejection

Visitor ejection separates destination searches from player operations.

The flow rechecks the player’s location, claim identity and continued eligibility before moving them to an available destination.

Bounded mob cleanup

Optional mob cleanup schedules chunk scans and entity removal in their appropriate contexts.

Before removal, queued work rechecks the current claim, cleanup eligibility and the entity’s actual location.

Reload and shutdown cleanup invalidate or cancel managed work so outdated callbacks do not continue under an obsolete lifecycle.

---

Update Notifications and Version Naming

Platform-specific update selection

Update checking now distinguishes the standard and Folia distributions.

The Folia build requests compatible Folia releases; the standard build retains its Bukkit-family update path.

New artifact names

The update selector recognizes:

• DyClaim-1.0.3.jar
• DyClaim-1.0.3-Folia.jar

Historical filenames using the previous v prefix remain recognized.

Folia version suffixes

Folia release suffixes are handled during version comparison so the platform label is not incorrectly treated as an ordinary prerelease suffix.

Removed new-release v prefixes

New version labels and artifact filenames use 1.0.3 without a leading v.

Historical release names are retained.

Folia notification delivery

Administrator notifications are routed through the relevant player scheduler on Folia.

Existing periodic checks, retry behaviour and direct download notifications remain available. DyClaim does not automatically replace the installed JAR.

---

Compatibility

Preserved foundations

This release retains:

• Java 17 bytecode target.
• Spigot API 1.20.4 baseline.
• Schema-2 claim data.
• Existing command aliases.
• Existing permission structure.
• Automatic English and Turkish language behaviour.
• Existing configuration and custom message preservation.

Use the Java runtime required by your actual server. Java 17 bytecode does not mean every supported Minecraft server can run on Java 17.

Excluded platforms

This release does not include Velocity or BungeeCord companion plugins.

The proxy experiments remain separate from the published backend artifacts.

Sponge and NeoForge are not supported by this release.

---

Tested Environments

The following checks were performed for the DyClaim 1.0.3 artifacts on 16 October 2026.

Results from older releases are not included as evidence that the same scenarios were repeated for 1.0.3.

Automated verification

284 JUnit tests passed, with:

• 0 failures.
• 0 errors.
• 0 skipped tests.

The suite includes coverage for:

• Claim-list filters and stable teleport indices.
• Connected outline geometry.
• Personal effective-access information.
• Administrator diagnostics and permission checks.
• English/Turkish command and TAB behaviour.
• Platform scheduler routing.
• Concurrent claim insertion, ownership state and snapshots.
• Acquisition reservations and limit checks.
• Single-consumption confirmations.
• Transaction reservations and journal coordination.
• Concurrent JSON writes.
• Configuration and message reload snapshots.
• Teleportation and task cancellation.
• Region-aware border rendering, visitor ejection and mob cleanup.
• Standard/Folia update selection and artifact naming.

After the final code change, the following command passed:

gradlew.bat test verifyPlatformArtifacts --no-daemon

Artifact checks confirmed:

• Plugin version 1.0.3 in both JARs.
• Java 17 class-file target.
• Correct standard and Folia distribution markers.
• folia-supported: true only in the Folia distribution.
• No archived proxy classes or bridge protocol resources in either artifact.

Isolated server verification

All scenarios used disposable, loopback-bound test environments. Minecraft protocol clients were used rather than human visual clients.

Server	Java	Scenarios exercised
Purpur 1.20.4, build 2176	Java 21	Free claim acquisition; claim naming; name and sale-status filters; stable teleport indices; permitted and denied player diagnostics; temporary personal trust with denied container access; joined Java particle packet coordinates; English and Turkish/ASCII TAB; global language override; reload; normal stop/start with ownership, name and index persistence
Folia 1.20.4, build 31	Java 21	The same new command, particle, access, language and reload scenarios; normal shutdown/start with ownership, name and index persistence; console diagnostics and reload through loopback RCON
Folia 26.3, build 3 ALPHA	Java 25	Plugin startup; console diagnostics; reload; repeated diagnostics; normal shutdown

Test execution notes

The initial Purpur script attempted /claim see while the automatic claim-acquisition visualization was still active. That attempt timed out because of test sequencing.

The remaining visualization, TAB, language and reload scenarios were subsequently completed after the automatic display expired. This sequencing issue was not reported as a plugin fix.

Folia persistence was verified after an actual normal stop/start. Reconnecting to a server without restarting it was not treated as restart evidence.

The modern-server environment also produced Windows OSHI/performance-counter warnings. These were separate from DyClaim's startup and console results.

Areas not live-tested for 1.0.3

The completed checks did not include:

• A live Vault economy provider.
• Live SimpleClans integration.
• Live Floodgate/Bedrock-client visualization.
• Human visual-client inspection.
• The complete piston, fluid, inventory and entity protection matrix.
• Every intermediate Minecraft patch release.
• Modern-client gameplay scenarios on Folia 26.3.

Bedrock rendering and cross-region ownership constraints have automated fixture coverage. This is not equivalent to live integration acceptance.

Folia 26.3 startup, reload and shutdown results do not establish that every gameplay or integration path was tested on that runtime.

Compatibility interpretation

Minecraft version listings describe the release's intended compatibility range. They are not a statement that every listed patch was individually tested.

Likewise, optional integration detection is not proof of compatibility with every version of that integration.

Read the version-specific verification record.

                    GNU GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007

 Copyright (C) 2024-2026 DyClaim Contributors

 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.

 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU General Public License for more details.

 You should have received a copy of the GNU General Public License
 along with this program. If not, see <https://www.gnu.org/licenses/>.

 ============================================================================
 ADDITIONAL TERMS (pursuant to Section 7 of the GPL v3)
 ============================================================================

 1. ATTRIBUTION REQUIREMENT
    All copies, forks, or derivative works of this software must
    retain the original project name "DyClaim" in a visible and
    prominent location, including but not limited to:
    - The plugin description (plugin.yml or equivalent)
    - The project README or documentation
    - Any public distribution page (Modrinth, Spigot, GitHub, etc.)

 2. NON-COMMERCIAL DISTRIBUTION
    You may NOT sell this software or any derivative work for monetary
    compensation. This includes but is not limited to:
    - Selling compiled builds (.jar files)
    - Offering paid downloads
    - Requiring payment or donation to access the software
    - Bundling with other paid products

    Free distribution is permitted and encouraged.

 3. OPEN SOURCE REQUIREMENT
    Any fork, modification, or derivative work of this software must
    be made publicly available under the same license terms (GPL v3
    with these additional terms). You may not distribute closed-source
    versions of this software.

 ============================================================================

 For the full text of the GNU General Public License v3, visit:
 https://www.gnu.org/licenses/gpl-3.0.en.html