Tags
Creators
Details
1.7.7
Compatibility
Required content
Changes
[1.7.7] - 2026-07-30
变更 / Changes
-
ScalableLux 兼容性修复 / ScalableLux compatibility fix: 修复 ScalableLux 与 Sable 的光照引擎不兼容问题(Issue #8)。/ Fixed ScalableLux incompatibility with Sable's light engine (Issue #8).
- 问题 / Issue: Sable 的
ServerLevelPlot构造函数从主世界LevelLightEngine读取blockEngine/skyEngine字段判断 SubLevel 是否有方块光/天空光。ScalableLux 的LevelLightEngineMixin.construct清空了这两个字段(用StarLightInterface替代 vanilla 光照引擎),导致 Sable 误判 SubLevel 无方块光、无天空光,SubLevel 光照完全失效。/ Sable'sServerLevelPlotconstructor reads theblockEngine/skyEnginefields of the main worldLevelLightEngineto determine if the SubLevel has block light / sky light. ScalableLux'sLevelLightEngineMixin.constructclears these fields (replacing vanilla light engine withStarLightInterface), causing Sable to misjudge SubLevel as having no block light and no sky light, completely disabling SubLevel lighting. - 修复 / Fix: 新增
scalablelux-compat修复项,拦截ServerLevelPlot构造函数中new LevelLightEngine(...)调用,当 ScalableLux 存在时通过StarLightInterface.hasBlockLight()/hasSkyLight()重新计算正确的光照参数。/ Addedscalablelux-compatfix: interceptsnew LevelLightEngine(...)inServerLevelPlotconstructor; when ScalableLux is present, recalculates correct light parameters viaStarLightInterface.hasBlockLight()/hasSkyLight().
- 问题 / Issue: Sable 的
-
物理结构崩溃修复 / Physics structure crash fix: 修复 simulated mod 的
EndSeaPhysics.physicsTick调用RigidBodyHandle.getLinearVelocity访问已移除的 rapier native body 导致RuntimeException: Body has been removed崩溃。/ FixedRuntimeException: Body has been removedcrash when simulated mod'sEndSeaPhysics.physicsTickcallsRigidBodyHandle.getLinearVelocityon a removed rapier native body.- 新增
RigidBodyHandleMixin,拦截getLinearVelocity和getAngularVelocity方法,try-catch 捕获RuntimeException并返回零向量,复用panic-guard修复项开关。/ AddedRigidBodyHandleMixin: interceptsgetLinearVelocityandgetAngularVelocity, catchesRuntimeExceptionand returns zero vector, reuses thepanic-guardfix toggle.
- 新增
-
配置文件修复 / Config file fix: 修复配置文件不存在时未重新生成的问题,以及执行命令修改配置后未立即保存的问题。/ Fixed config not regenerating when missing, and config not saving immediately after command modification.
- 配置保存时记录修复项的显式启用状态(
isExplicitlyEnabled)而非isEnabled,避免环境条件未满足的修复项被误写为 false。/ Config now saves explicit enable state (isExplicitlyEnabled) instead ofisEnabled, preventing fixes with unmet environment conditions from being written as false. - 首次启动或配置文件被删除时立即重新生成。/ Regenerates immediately on first launch or when config is deleted.
- 配置保存时记录修复项的显式启用状态(
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:YS1hdEUp:8VNkpwLS"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:YS1hdEUp:8VNkpwLS"
}

