WorldGuard

WorldGuard

8M Downloads

Polygon Oddities

wizjany opened this issue ยท 5 comments

commented

Due to the weird way that the polygon region calculations work, a lot of issues have arisen.
Both the volume algorithm and the contains checks need to match and be rigorously tested, especially in edge case which may be mentioned in the following:

#1244
#1281
#1172

This is the cause for other issues such as:
#997

Any other issues with polygons should be closed and linked here, in the interest of cleanliness. They all arise from the same root cause.

Another thing to be checked:
https://github.com/EngineHub/WorldGuard/blob/master/worldguard-core/src/main/java/com/sk89q/worldguard/protection/managers/index/ChunkHashTable.java
could be potentially causing chunk states to show as loaded but not including the polygon, or vice versa (polygon existing in unloaded chunk state)

I'm fairly sure this is just caused by the higher edge not being included, i.e. the outermost edge is truncated to 0 instead of checking the 0.5 position for inside/outside like WE does.

commented

Chunk boundary issue:

When a polygon point is on the east(X+) or south(Z+) side of a chunk border, the blocks it crosses are not properly included in the region defined by the polygon.

Minimum reproduction steps:

  1. Create a 2x2 region across any chunk border
  2. Observe which blocks can be broken or in which blocks /rg info finds the region

Observed behavior:

The two blocks on the east or south side are not included in region calculations.

Expected behavior:

The region encompasses all 4 blocks, just like 2x2 cuboid regions or poly regions that do not cross a chunk boundary.

2023-11-30T18-12-20.mp4

Another video showing a region with both sides at once:

2023-11-30T17-55-57.mp4

Please note that even though my demonstrations both show rectangular regions, this issue can be observed for regions with any number of points or size.

commented

I seem to be observing the same issue too, odd.

commented

I just found a very weird way to bandaid fix this issue.

If you create additional regions for the bits excluded by the region, and then parent it to the original region in question, provided the additional regions have a lower priority, it works to extend the original region.

commented

my bandaid fix is to extend the region an additonal block into the east/south. the bug only happens when the poly point is directly on the chunk border. when moving it one block away from the chunk border, the region is calculated as expected.

commented

As just described in Discord:
Having a build-protection on "rg-01" with priority 0 and defining a poly "shop-06" without build-protection, priority 1. When selecting "shop-06" and setting all blocks to torch we can prove that all required blocks are correctly set.
But trying to build on some places at the edge inside shop-06 fails and "rg info" shows only "rg-01".

Here are some coordinates:
region_id world_id min_y max_y
shop-06 5 74 86

id region_id world_id x z
1625 shop-06 5 631 298
1626 shop-06 5 636 298
1627 shop-06 5 636 296
1628 shop-06 5 640 296
1629 shop-06 5 640 304
1630 shop-06 5 636 304
1631 shop-06 5 636 302
1632 shop-06 5 626 302
1633 shop-06 5 626 298
1634 shop-06 5 628 298
1635 shop-06 5 628 297
1636 shop-06 5 631 297

problems are at e. g. (640 79 296) --> (640 84 304)
and (640 84 304) --> (636 79 304)