Tags
Creators
Details
0.5.0
Compatibility
Required content
Changes
TunnelVision 0.5.0
This release adds terrain exposure: the plugin now knows whether an ore was visible in open air before it was broken. That's what makes it possible to tell a player exploring a cave apart from one digging straight at an invisible vein — the main source of false positives so far.
Terrain exposure (new)
For every ore broken, the plugin re-reads the actual terrain through the Bukkit
API and determines whether the block was exposed to air just before it was mined.
This feeds a new scoring signal, blind_target_rate: the share of veins hit
without a single face having been visible beforehand.
- Enabled by default, under the
exposure:section inconfig.yml. - Runs on an async thread — the server tick is never blocked.
- Automatic history backfill. Two cursors work in parallel with nothing to configure: a forward cursor for recent breaks, and a backward cursor that gradually works through your existing CoreProtect history. Installing the plugin on a server that's been running for months therefore doesn't leave older sessions unanalyzed.
- The backward pass resumes where it left off after a restart.
- The
/exposure/coverageendpoint reports how far the backfill has progressed over a given time window. - Fully optional: disable the section and sessions are scored as before — nothing breaks.
Cave sessions: far fewer false positives
Sessions taking place in natural caves are now detected and tagged automatically, then evaluated with dedicated scoring instead of the general one. A player exploring a cave legitimately finds a lot of already-exposed ore — they're no longer penalized for it. Reports flag these sessions explicitly.
Performance
- Exposure backfill is significantly faster: the ore filter was pushed down
into SQL, neighbor block history is now cached, and the scan window is bounded
(
scan-window-rowids, roughly 62 ms per million rowids). - Sync to the analysis service is 2.5× faster thanks to a page cache on the mirror side.
- Configurable sync batch size via
max-page-size. Measured over a 61 M block pass: ~12,500 blocks/s, with 96% of the time spent sending over the network and 4% reading locally. Raising the value cuts the number of HTTP round trips proportionally, at the cost of more memory per batch. - Chunks are now preloaded in parallel during terrain reads.
- Lower memory use when loading break data.
3D reports
- Ore selection with color coding.
- Format adjusted to surface cave sessions.
Fixes
- The backward backfill stopped after a single batch instead of continuing.
- The backward backfill ignored terrain exposure.
- Application memory thresholds now follow the actual allocated limit.
Upgrade notes
No action required: the new settings ship with working defaults and the history backfill starts on its own. The plugin still never writes to the CoreProtect file.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:zpP2prtk:ooGhMuBU"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:zpP2prtk:ooGhMuBU"
}

