Download File

# GriefPrevention3D v18.2.15 **Wiki:** https://github.com/castledking/GriefPrevention3D/wiki ## Fixes ### Two rectangular claims could merge into a narrow Manhattan path Running `/mergeclaims` on two rectangular claims could produce a thin, bent connection between them instead of one usable rectangle. The disconnected-polygon union already knew how to make a valid Manhattan connection, so the later bounding-box fallback was never reached. Whether another claim occupied part of the larger rectangle could therefore indirectly change which geometry survived. **Fix:** a direct merge now chooses its geometry before the generic polygon union runs. When both selected claims have four-corner rectangular boundaries, the result is always the single global bounding rectangle covering both claims: - The rectangle uses the minimum and maximum X/Z coordinates of both selected claims. - `GriefPrevention.Claims.AllowShapedClaims` does not change this rule. - A claim which carries shaped-claim metadata but still has an actual four-corner boundary is treated as a rectangle. - If the proposed rectangle overlaps another claim, the merge fails with the normal overlap conflict instead of silently falling back to a Manhattan or other non-rectangular shape. This can require more claim blocks than the old narrow connection. The existing final-area claim-block check still runs before anything is changed and reports insufficient blocks in the normal way. ### Shaped claims keep their Manhattan route, widened by the selected nib depth The Manhattan route remains the useful behavior for non-rectangular shaped claims, but its old fixed-width path could look and behave like a tiny road between otherwise substantial claim sections. Shaped merges now record the selected boundary edge and the player's position at **both** ends. A new platform-neutral `MergeCorridor` geometry helper uses that information to build one straight rectangle or two rectangles forming an L-shaped Manhattan route: - The player's distance inward from the selected edge controls how deeply the corridor is inset into that nib. - The selected nib keeps its own width while the chosen depth remains inside the narrow section. - If that depth reaches a wider connected parent section, the parent section becomes the width of that corridor leg. - Diagonal claims keep the Manhattan turn; each leg uses the width measured from the nib it leaves or enters. - A shaped claim must have a resolvable boundary edge at both ends, preventing missing nib data from dropping back to an unintended thin connector. The cross-claim shaped-editor/roundabout path already supplies its own connection cells and continues using that path unchanged. This new corridor selection applies to direct `/mergeclaims` operations. ### Populated-area overlap checks now cover the whole proposed result The old merge check looked for claims near the first claim's corner. A long rectangle or shaped corridor can extend through chunks well beyond that local search, allowing a claim in the middle or near the second endpoint to be missed. **Fix:** collision candidates are collected from every chunk beneath the complete proposed merge boundary. The exact polygon intersection check then rejects: - A third claim belonging to another player. - A third claim belonging to the same owner. Only the two explicitly selected claims are collapsed; swallowing a separate same-owner claim would otherwise leave two live claims on the same blocks. - A claim crossing a shaped corridor even when neither polygon has a corner inside the other, such as a narrow horizontal claim crossing a vertical corridor. The two claims explicitly selected for the merge and their subdivisions are still excluded from this conflict list. On conflict, no claim geometry is mutated and the conflicting claim is shown with the existing conflict visualization. ### The command completion path now checks the second claim's edit permission Right-click completion already checked edit permission on the second claim, but running `/mergeclaims` again while standing inside the second claim could reach the merge directly. That alternate command path now performs the same edit-permission check before measuring a nib or calling the data store, so a claim the player cannot edit is never absorbed. ## Notes No configuration or claim-data migration is required. Existing rectangular claims remain rectangular, existing shaped boundaries remain valid, and stored claim IDs and subdivisions are handled as before. ## Tests Eleven regression cases were added across `MergeClaimsTest` and `MergeCorridorTest`, covering: - The mandatory global bounding rectangle for two rectangular claims, even when edge/depth metadata is present. - Four-corner claims carrying shaped metadata. - Shallow nib depth and widening when that depth reaches a larger parent section. - The complete widened Manhattan route between diagonal shaped claims. - Clear populated areas containing nearby same-owner and other-player claims. - Overlap rejection for both same-owner and other-player claims. - Candidate discovery across the full multi-chunk proposed boundary. - Crossing-polygon conflicts where corner-only intersection checks would fail. - Rejection when the player cannot edit the second selected claim. The full Gradle `check` lifecycle passes for the Bukkit plugin, `gp3d-core`, and the Fabric module. ## Files Changed ``` A gp3d-core/src/main/java/com/griefprevention/geometry/MergeCorridor.java A gp3d-core/src/test/java/com/griefprevention/geometry/MergeCorridorTest.java M src/main/java/me/ryanhamshire/GriefPrevention/ClaimToolDispatcher.java M src/main/java/me/ryanhamshire/GriefPrevention/DataStore.java M src/main/java/me/ryanhamshire/GriefPrevention/GriefPrevention.java M src/main/java/me/ryanhamshire/GriefPrevention/PlayerEventHandler.java A src/test/java/me/ryanhamshire/GriefPrevention/MergeClaimsTest.java ```