DyClaim 1.1.0

This is the largest DyClaim update so far. Ranks can get their own claim limits. Owners can greet visitors and keep unwanted players out. Claims appear in PlaceholderAPI and on BlueMap, Dynmap and squaremap. Servers can bring their claims over from GriefPrevention or ClaimChunk. Other plugins can use a developer API, and messages now come in five languages. Every new system has its own switch in config.yml. Claim data, existing commands and permissions are unchanged, and servers can upgrade from any earlier version by replacing the JAR.

Claim limits by permission

What changed. Until now every player had the same claim.max-claims-per-player limit. Servers with ranks had no simple way to give VIPs more land. Now a permission sets the limit:

Permission	Claim limit
dyclaim.limit.5	5
dyclaim.limit.50	50
dyclaim.limit.unlimited	No limit

• Give the permission to a group in LuckPerms or any other permission plugin. Any number works.
• If a player has several, the highest one wins.
• The permission replaces the default limit, so a lower number can also restrict a group, for example new players.
• Players without a dyclaim.limit permission keep the default limit, so nothing changes on servers that do not use it.
• Per-world limits under claim-rules.worlds still apply. A world without its own limit uses the player's effective total.
• /claim list shows the effective limit, for example 3/10, or ∞ for unlimited.
• Being OP does not grant these permissions; they must be given explicitly.
• Switch: claim.permission-limits.enabled.

Claim messages

What changed. Owners can now set a short message that visitors see in chat when they walk into the claim, for example [Alex] Welcome to the market!.

• /claim message <text> sets the message. /claim message clear removes it.
• Owners and coowners can set it. They do not see it themselves when they walk in.
• The message is shown when a player enters from outside or from another owner's land, not on every step inside.
• /claim info shows the current message.
• claim-messages.maximum-length sets the longest message, 1 to 128 characters (default 64).
• claim-messages.allow-colors decides whether & colour codes are allowed (default: off).
• Section signs and control characters are always rejected.
• Permission dyclaim.message (everyone by default). Switch: claim-messages.enabled.

Visitor bans

What changed. Trust decides who can build, but until now there was no way to keep a specific player from walking in. Owners can now ban a player from one claim.

• /claim ban <player> bans permanently. /claim ban <player> 30m, 2h or 7d bans for a time.
• /claim unban <player> lifts the ban. /claim banlist shows active bans and when each one ends.
• A banned player cannot walk or teleport into the claim and sees "You are banned from Alex's claim."
• A player who is inside when banned is moved to a safe unclaimed spot nearby, using the same exit search as visitor warnings.
• Banning removes the player's trust in that claim. Trusting them again lifts the ban.
• Owners, coowners, administrators, players with active bypass and players with dyclaim.ban.exempt cannot be banned.
• claim-entry-bans.maximum-per-claim limits bans per claim (default 50).
• When ownership changes through a transfer or a market sale, the old owner's bans and message are cleared.
• Permission dyclaim.ban (everyone by default). Switch: claim-entry-bans.enabled.

The existing admin "claim-entry-ban" sanction for warnings is separate and works as before.

PlaceholderAPI

With PlaceholderAPI installed, DyClaim registers its own dyclaim expansion. No /papi ecloud download is needed.

Placeholder	Value
%dyclaim_claims%	Claims the player owns or coowns
%dyclaim_claims_owned%	Claims the player owns
%dyclaim_limit%	Effective claim limit (∞ when unlimited)
%dyclaim_remaining%	Claims the player can still get
%dyclaim_in_claim%	true or false for the current chunk
%dyclaim_owner%	Owner of the current chunk
%dyclaim_name%	Name of the current claim
%dyclaim_pvp%	PvP in the current claim
%dyclaim_can_build%	Whether the player can build here
%dyclaim_role%	owner, coowner, trusted or visitor
%dyclaim_total%	Claims on the whole server

Use them in scoreboards, tab lists, holograms or chat formats. Switch: integrations.placeholderapi.enabled.

Claims on the web map

DyClaim now draws claims on BlueMap, Dynmap and squaremap.

• Each owner's neighbouring chunks are joined into a few areas instead of one square per chunk.
• Every owner keeps the same colour, so land is easy to tell apart.
• Hovering or clicking shows the owner and any claim names.
• The layer is refreshed every 60 seconds by default (integrations.maps.refresh-seconds, 10 to 3600) and after /claim admin reload.
• A refresh works out the claim areas off the main server thread and sends the map plugins only what was added or removed. When nothing changed, the maps are not touched, so even servers with tens of thousands of claims do not lag on each refresh.
• layer-name, fill-opacity, line-opacity and hidden-worlds control the look and which worlds are shown.
• Each map plugin has its own switch, plus a master switch integrations.maps.enabled.
• On the Folia build only BlueMap is used, because Dynmap and squaremap do not run on Folia.

Import from GriefPrevention and ClaimChunk

What changed. Moving to DyClaim used to mean every player had to claim again. Now DyClaim can copy existing claims.

1. Install DyClaim next to the old plugin and start the server.
2. Run /dyclaim admin import griefprevention (or claimchunk). This only shows a preview: how many claims were found, how many new chunks they cover and what will be skipped.
3. Run the same command with confirm to import. DyClaim writes a backup of its claim file first.
4. Remove or disable the old plugin.

How claims are converted:

• GriefPrevention: every chunk that a player claim touches becomes a DyClaim claim for the same owner. Builder and manager trust become full trust, container trust becomes containers, entities, doors, trapdoors and redstone, and access trust becomes doors, trapdoors and redstone. Admin claims, subclaims, public trust and group trust are skipped.
• ClaimChunk: every claimed chunk is copied with its owner, and per-player access maps to the closest DyClaim rights.
• Chunks DyClaim already owns, chunks in blacklisted worlds and chunks claimed by two different owners in the source are skipped.
• Imported claims have no purchase price, so selling them back refunds nothing. Limits and prices are not checked during import.
• The old plugin's data is never changed. Running the import again only adds what is still missing.

Use /dyclaim (or dyclaim in the console) instead of /claim for this command, because GriefPrevention also registers /claim. Import requires dyclaim.admin.

Developer API

Other plugins can now read DyClaim claims and react to changes. The API is part of the normal JAR, in the dev.dyclaim.api package.

• DyClaimAPI.getClaimAt(location), getClaims(player), getClaimCount(player), getClaimLimit(player), canBuild(player, location) and getAllClaims().
• A Claim gives the owner, coowner, name, location, claim date, trusted players and each permission right.
• Events: ClaimCreateEvent (by player, admin or import), ClaimRemoveEvent, ClaimTransferEvent and ClaimTrustChangeEvent.
• The API is read-only; changes still go through DyClaim's commands with all their checks.
• Event objects are only created when another plugin listens, so servers without such plugins pay nothing.

The full guide with examples is at docs/api.md.

German, Spanish and Russian

DyClaim now ships complete message files in German, Spanish and Russian, next to English and Turkish.

• With lang: auto, players get these languages from their Minecraft language setting.
• Players can choose with /claim lang de, es or ru. Administrators can force one for everyone with /claim admin lang de|es|ru.
• Commands stay English in these languages. Turkish keeps its translated command words.
• The new files messages_de.yml, messages_es.yml and messages_ru.yml are created in the plugin folder and can be edited like the others.

bStats

DyClaim now sends anonymous statistics to bStats: server and player counts, Minecraft and plugin versions, and a few DyClaim charts (language mode, platform, economy on or off, claim count range, PlaceholderAPI use and active map plugins). No player names, claim locations or chat are sent. Turn it off with metrics.enabled: false, or for every plugin in plugins/bStats/config.yml.

Smaller changes

• Claim changes such as trust, settings, names, messages and bans are now written to disk in the background, so servers with very large claim files no longer pause. Steps that involve money, imports, inactive cleanup and shutdown still save immediately.
• /claim admin diagnose lists active PlaceholderAPI and map hooks, and shows Floodgate with its correct name.
• Help shows the new commands only to players who have the permission and only while the feature is on.
• TAB suggests player names, durations and clear for the new commands, and the import sources and confirm for administrators.

Performance

The four-plugin, 50-claim comparison was repeated with the 1.1.0 JAR on 24 October 2026, with the same method, server, plugin versions and order as before. Values are milliseconds per 1,000 block-break checks, median of six windows (observed range in brackets).

Plugin	Owner allowed	Visitor blocked	50% / 50% mixed
DyClaim 1.1.0	0.677 (0.595–0.841)	10.194 (6.647–12.506)	5.430 (3.621–6.674)
GriefPrevention 16.18.3	0.479 (0.369–0.696)	12.409 (8.943–17.313)	6.443 (4.674–9.005)
ClaimChunk 0.0.25-FIX3	1.032 (0.921–1.150)	39.302 (28.809–49.809)	20.167 (14.872–25.453)
Towny 0.103.2.0	3.720 (3.228–4.639)	37.772 (31.086–43.227)	20.752 (17.169–23.641)

How to read the results:

• DyClaim had the lowest median in the mixed workload. GriefPrevention was faster when only owners were checked.
• The DyClaim and GriefPrevention ranges overlap, and so do the ClaimChunk and Towny ranges.
• Claim messages and visitor bans are checked when players move, not when blocks are broken, so this test does not cover them. Block protection itself did not change in 1.1.0.
• These are event-processing times, not CPU or RAM usage, and they do not prove DyClaim is faster in every situation. Differences from the 22 October numbers are normal run-to-run variation on a desktop machine.

Verification

• Automated tests. 328 tests passed: the 299 from 1.0.4 and 29 new ones for every new system.

• Upgrade from 1.0.4. A Purpur 1.20.4 server with LuckPerms, PlaceholderAPI, BlueMap, Dynmap and squaremap passed 18 of 18 checks:

  • claims were kept;
  • rank limits, placeholders, claim messages and visitor bans worked;
  • German, Spanish and Russian help appeared;
  • map markers and reload worked.

• Upgrade from older versions. Real data made by the Beta and by 1.0.3 passed 12 of 12 checks each:

  • claims, trust and names were kept, and the Beta file was backed up first;
  • untouched messages switched to the new wording while edited ones were kept;
  • the new features worked on the old claims.

• Economy, market, clans and API: 32 of 32 checks, with Vault and EssentialsX:

  • Prices. A claim cost $1,500 and selling it refunded $900. A market sale for $1,000 paid the seller $950 after the 5% tax and cleared the old owner's message and bans.
  • Timed bans. A 1-minute ban stopped both walking and /tp into the claim, then ran out on time.
  • SimpleClans. /claim trust clan:<tag> let clan members build, and /claim untrust clan:<tag> took it back.
  • API. A test plugin received every API event on the main thread and read the right values.

• Import. 50 real GriefPrevention claims and 50 real ClaimChunk claims arrived with the right owners, and a second run added nothing. Trust given with /trust, /containertrust, /accesstrust, /permissiontrust or /chunk access became the matching DyClaim rights.

• Web maps. With BlueMap's download terms accepted on the test server:

  • Purpur: 12 of 12 checks. BlueMap, Dynmap and squaremap showed new claims and dropped sold ones, and the hidden-world and on/off switches worked.
  • Folia: 6 of 6 with BlueMap 5.5.

• Large servers. With 10,000 claims and all three map plugins, the longest server tick was 5.8 ms (5.3 ms without maps). In an extreme test with 49,807 scattered claims, map refreshes no longer cause lag spikes: the longest tick dropped from 685 ms in the first test build to 19.8 ms.

• Saving. A claim message was on disk 3 seconds after it was set, even when the server process was killed right after. A claim made just before /stop was also kept.

• Minecraft versions. 10 of 10 checks passed on each of these servers: claiming, protection, claim message, bans, German help and reload.

  Server	Versions
  Paper	1.20.1, 1.20.6, 1.21.1, 1.21.4, 1.21.8, 1.21.11, 26.1.2, 26.2, 26.3
  Purpur	26.2
  Spigot	26.2, 26.3
  Folia	26.2, 26.3

• PlaceholderAPI on Folia returned the right values for a real player.

• bStats. One real submission was sent with the right plugin ID and charts, and with no player data.

• Not tested: Bedrock players through Floodgate.

DyClaim 1.0.4

Released 23 October 2026. This release makes DyClaim easier to use day to day. Help is paged, frequent commands get short forms, and every English and Turkish message was rewritten. It also fixes three message bugs. Claim data, configuration, permissions and existing commands are unchanged, and servers can upgrade from any earlier version by replacing the JAR.

Paged help

What changed. /claim help used to print more than thirty lines at once. On a normal chat window, the top of the list scrolled away before it could be read. Help is now split into pages of eight commands.

• /claim help shows page 1. /claim help 2, /claim help 3 and so on show the others.
• Under the list, a line shows the current page, the page count and the exact command for the next page, for example Page 1/5 | Next page: /claim help 2.
• In Turkish the command is /claim yardım 2. The next-page hint uses whichever root you typed, so a player who used /dyc yardım is told /dyc yardım 2.
• Admin help works the same way with /claim admin help [page] or /dyca help [page]. Plain /claim admin or /dyca still opens page 1.
• A page number past the end shows the last page. Text, zero or negative numbers are rejected with the usual "type /claim help" message.
• TAB suggests valid page numbers for the player's own help.
• The server console has no chat window limit. It still receives the complete list on one screen, filtered to the commands the console can actually run.

Rows and permissions. Every command row from 1.0.3 is still there, in the same order, and each row appears on exactly one page. The filtered-list row is shown only with dyclaim.list, the /cltp row only with dyclaim.teleport, and the "Admin commands" entry only to players with dyclaim.admin.

New command shortcuts

Shortcut	Same as	Who can use and see it
/dyc	/claim / /dyclaim	Everyone, like /claim
/cltp <number|name>	/claim tp <number|name>	Everyone with dyclaim.teleport (granted to everyone by default)
/dyca <command>	/claim admin <command>	Only players with dyclaim.admin and the console

• /dyc is a real alias of the main command. Every subcommand, Turkish word, filter and TAB suggestion works through it: /dyc list, /dyc güven Alex 2h, /dyc yardım 2.
• /cltp behaves exactly like /claim tp. It takes the number from your claim list or the claim name and uses the same warmup, movement cancel and safety checks. TAB suggests your claim numbers and names. It appears in both English and Turkish help, so players can find it in either language.
• /dyca reaches every admin tool: /dyca reload, /dyca diagnose, /dyca lang tr, /dyca bypass, /dyca purge 30 and so on. It is declared with the dyclaim.admin permission. Players without it get no TAB suggestion for the command or its arguments, never see it in help and cannot run it. Administrators see it at the top of the admin help. In the console, type it without the slash: dyca reload.

Clearer English and Turkish messages

Rewritten text. All 269 messages in both languages were rewritten with these goals:

• Shorter sentences that say what happened and what to do next. For example, "Something changed in the meantime. Please run the command again." replaces "Conditions changed. Start the action again."
• The same words for the same things everywhere: co-owner, trusted player, claim limit, sale listing.
• Help descriptions that explain the result, not just the command name. For example, "Let a player build here, optionally for a time" instead of "Trust a player".
• Clearer headers: "Claim Info" and "Your Claims". The empty claim list now tells new players to stand in a chunk and type /claim.

Turkish. The Turkish text now uses one consistent form of address ("siz") instead of mixing "sen" and "siz". English leftovers such as "trust" were replaced with natural Turkish ("güvenilen oyuncu", "güven izni"). The confirmation hint now points to the Turkish commands /onayla and /reddet. /confirm and /cancel still work.

Upgrading existing message files. Server owners often never touch the message files, and a plugin cannot simply overwrite files that might contain custom translations. 1.0.4 handles this automatically:

• DyClaim ships a list of every message text released in Beta, 1.0.0, 1.0.1, 1.0.2 and 1.0.3.
• When a server's message is still exactly one of those shipped texts, DyClaim uses the new 1.0.4 wording.
• When the text was edited, even slightly, the server's own version is kept.
• The message files on disk are never rewritten. The upgrade happens in memory each time messages load, so removing a custom line from the file still falls back to the bundled default.
• Prefixes, colors and {placeholders} keep working as before. No key was renamed or removed.

Fixes

• Duplicate message on denied permission. A player without permission for coowner, transfer, market or warning commands received both "You don't have permission" and "This feature is turned off". Now only the permission message is shown. "Feature turned off" is shown only when the player has permission but the server disabled the feature.
• /cancel reply. Cancelling a pending action (claim, sale, purchase, transfer offer, coowner offer, admin delete or purge) sent the red "[Cancel]" button label back as a chat message. It now replies "Cancelled. Nothing was changed." ("İşlem iptal edildi, hiçbir şey değişmedi."). The clickable button keeps its label.
• Diagnostics version fallback. /claim admin diagnose had an old version number written into its code as a fallback. It now reports "unknown" if the version cannot be read, instead of showing a wrong number.

Compatibility

• Same claim data (schema 2), configuration file, permissions and commands as 1.0.3. No migration step is needed.
• All existing aliases still work: /claim, /dyclaim, Turkish subcommands, ASCII spellings, /confirm, /onayla, /cancel, /reddet, trustperm and mobexplosion.
• Java 17 bytecode compiled against Spigot API 1.20.4. Use the Java version your server requires.
• Two builds, as in 1.0.3. DyClaim-1.0.4.jar is for Bukkit, Spigot, Paper and Purpur. DyClaim-1.0.4-Folia.jar is for Folia. Install only one of them.
• If another plugin already registers /dyc, /dyca or /cltp, Bukkit decides which plugin owns the name. The full forms /claim, /claim admin and /claim tp always keep working, and /dyclaim:dyc style names reach DyClaim directly.

Performance

The four-plugin, 50-claim comparison was repeated with the 1.0.4 JAR on 22 October 2026. It uses the same method, server, plugin versions and order as the October 10 run. Values are milliseconds per 1,000 block-break checks, median of six windows (observed range in brackets).

Plugin	Owner allowed	Visitor blocked	50% / 50% mixed
DyClaim 1.0.4	0.752 (0.643–0.874)	10.705 (9.355–13.308)	5.751 (4.999–7.091)
GriefPrevention 16.18.3	0.407 (0.289–0.556)	13.121 (8.017–18.385)	6.764 (4.153–9.458)
Towny 0.103.2.0	4.366 (3.619–5.710)	49.987 (40.708–59.338)	27.176 (22.164–32.524)
ClaimChunk 0.0.25-FIX3	1.397 (1.159–1.906)	58.493 (54.254–62.536)	29.852 (27.707–32.221)

How to read the results:

• DyClaim had the lowest median in the mixed workload. GriefPrevention was faster when only owners were checked.
• In this run, the DyClaim and GriefPrevention ranges overlap.
• These are event-processing times, not CPU or RAM usage, and they do not prove DyClaim is faster in every situation.
• The protection code did not change in 1.0.4. Differences from the October 10 numbers are normal run-to-run variation on a desktop machine.

Verification

• Automated tests. 299 tests passed, 284 existing and 15 new. The permission-message fix was first reproduced by a test that failed on 1.0.3 and passed after the change.
• Live upgrade test. A Purpur 1.20.4 test server was upgraded in place from 1.0.3, with its claims and 1.0.3 message files. 24 of 24 checks passed:
  • Untouched 1.0.3 messages showed the new wording.
  • Claims and names were kept.
  • Help was paged and showed the next-page command. Players could not see the admin entry or /dyca.
  • /dyca was hidden from player TAB, visible to administrators and refused for players.
  • /dyc and /cltp worked, including teleporting to a named claim.
  • Turkish paged help worked.
  • /cancel gave the new reply.
• Folia 1.20.4. The Folia build started with existing claims and ran dyca diagnose, dyc help, dyca help and dyca reload from the console.
• Not tested in this release:
  • a live Vault economy provider
  • a permissions plugin (permission denial is covered by automated tests)
  • SimpleClans
  • Bedrock / Floodgate clients
  • Paper or Spigot 26.x
  • Folia 26.3
  • every intermediate Minecraft patch release

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.