Skip to main content

Resolve overlapping TShock regions without removing protection

A player can have unexpected building access where two TShock regions overlap. Diagnose the region selection and its access list before removing protection. You need region-management permission and a normal test account; keep a backup of the world and TShock data before changing an established layout.

Capture one reproducible location

Choose one tile where the result differs from your expectation. Record the player account, group, coordinates and attempted action. Compare that with a nearby tile that behaves correctly. This keeps the investigation focused on a boundary rather than an entire world.

Run /region list and inspect likely regions with /region info NAME. Save the region names, dimensions, allowed users and allowed groups before editing. A region named after an old building can still cover the test tile, so inspect its coordinates rather than trusting its name.

Find the active overlap

  1. Run /region name and use the tile-interaction method described by the installed command help at the affected location.
  2. Where supported, use the -u and -z inspection flags to include unprotected regions and inspect z-index information.
  3. Compare the boundaries of the regions covering that tile. The TShock documentation states that a smaller z-index takes precedence over a larger one.
  4. Check whether the affected player belongs to an allowed group or has a protection-bypass permission. A SuperAdmin account makes a poor test subject.
  5. Write the intended policy in plain language, for example: visitors cannot edit the lobby, while the builders group may edit the workshop inside it.

Make a narrow correction

Choose whether the inner or outer region should take precedence. Record the old z-index, then use /region z NAME NUMBER with the planned value. Avoid assigning matching values and assuming an undocumented tie-break rule. Make one change and repeat the same tile test.

If the mistake is an oversized rectangle, use the installed region expansion or contraction command to adjust the relevant edge instead. Preserve the original dimensions in your notes. Do not change both geometry and precedence at the same time; you would lose a clear explanation of the result.

Verify the neighbouring areas

Test the problem tile, each side of the overlap and a tile outside both regions. Use the normal account first, then an account that should have explicit access. Record each result. Check a second protected building as a quick guard against accidentally changing a shared group permission.

If the edit does not produce the intended result, restore the old z-index or boundary and inspect permissions again. Do not delete regions one by one until access changes. That approach can leave a protection gap while giving you incomplete evidence.

After a successful change, save staff notes with the region names and intended precedence. Remove any temporary test access. If support needs to investigate, send the region inspection output and a redacted screenshot of the affected area rather than a full database containing account information.

Official references

No comments to display