Polygon Oddities

[wizjany]

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.

[verboEse]

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)

[DaniDipp]

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.

https://github.com/EngineHub/WorldGuard/assets/17002453/ccc9d7a4-3627-426a-a961-b6407c650373

Another video showing a region with both sides at once:

https://github.com/EngineHub/WorldGuard/assets/17002453/82b48972-a71b-487d-bd86-bc6288b96425

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.

[Technofied]

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

[Technofied]

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.

[DaniDipp]

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.