Tags
Creators
Details
All versions
1.7.4
Release
FPSFlow 1.7.44 months ago 14
Compatibility
Minecraft: Java Edition
1.21.11
Platform
Fabric
Supported environments
Client-side
Required content
Any compatible version
Changes
[1.7.4]
Fixed
- Entities no longer disappear when moving around corners — The occlusion cache stored whether an entity was hidden, but did not track where the camera was when that raycast was taken. After the player moved, the old "occluded" result stayed in the cache for up to 10 ticks (0.5 s), making previously-hidden entities invisible even when now in plain sight. The cache now records the camera position at raycast time; if the camera has moved more than 1.5 blocks since then, the result is immediately discarded.
- Entities within 8 blocks are never occlusion-culled — The previous safety margin was only 4 blocks. At 5–8 blocks the raycast is susceptible to precision errors (slab edges, floor-level geometry, crawling/swimming camera clips). Raising the threshold to 8 blocks eliminates false-positive culling at close range without any meaningful performance cost.
- Stale "occluded" result no longer used for nearby entities while async re-check is pending — When a cache entry expires and the new check is queued asynchronously, entities within 24 blocks now show as visible while waiting for the result. Previously the old "hidden" answer was used unconditionally, so rapidly-moving close entities could wink out for several frames.
- Entities behind invisible blocks (barrier, light, structure void) are now visible — The occlusion raycast treated these invisible blocks as solid, hiding any entity behind a barrier wall or inside a light-block setup. The raycast now steps past visually-passable blocks and retries, so only genuinely solid geometry counts as occlusion.
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:ayg7iYUG:zZHFdJa4"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:ayg7iYUG:zZHFdJa4"
}
