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.jarDyClaim-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 and Upgrading
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.
Upgrade procedure
- Stop the server normally.
- Back up the installed DyClaim JAR and the complete
plugins/DyClaim/ directory.
- Remove the previous DyClaim JAR from
plugins/.
- Install the correct single 1.0.3 build.
- Keep the existing DyClaim data directory.
- Start the server and check the startup log.
Missing shipped message keys receive defaults while existing custom messages remain supported.
Use a normal stop/start when changing between server builds. Disabling the plugin outside a relevant region or entity context can prevent restoration of some client-only visuals or temporary effects.
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.
Verification
Automated checks recorded for 1.0.3
284 JUnit tests passed, with:
- 0 failures
- 0 errors
- 0 skipped tests
Coverage includes command workflows, list filtering, outline geometry, platform scheduling, concurrent claim operations, confirmations, transaction reservations, persistence and update selection.
Artifact verification confirmed that:
- Both JARs contain plugin version 1.0.3.
- Class files target Java 17.
- Each JAR contains the correct backend marker.
- Only the Folia build declares
folia-supported: true.
- Archived proxy classes and protocol resources are excluded.
Isolated server scenarios
| Environment | Verification performed |
|---|
| Purpur 1.20.4 build 2176 / Java 21 | Claim acquisition, naming, filtered lists with stable teleport indices, personal access, allowed and denied diagnostics, joined Java particle coordinates, EN/TR and ASCII TAB, global language override, reload and restart persistence |
| Folia 1.20.4 build 31 / Java 21 | The same new command, particle and language scenarios, normal restart persistence, plus console diagnostics and reload through loopback RCON |
| Folia 26.3 build 3 ALPHA / Java 25 | Startup, console diagnostics, reload, repeated diagnostics and normal shutdown |
These checks used isolated disposable servers and protocol clients.
Verification limits
The 1.0.3 checks did not include:
- Live Vault economy-provider acceptance.
- Live SimpleClans acceptance.
- Live Floodgate or Bedrock-client rendering.
- Human visual-client inspection.
- Every protection-event combination.
- Every intermediate Minecraft patch release.
- Modern-client gameplay scenarios on Folia 26.3.
Automated fixtures and successful startup checks are not presented as substitutes for those live integration scenarios.
Detailed verification record · Platform guide · Claim management guide · Download DyClaim 1.0.3
