1.0.10
Compatibility
Changes
LootRun 1.0.10 Changelog
LootRun 1.0.10 is a compatibility hotfix built after 1.0.9. It keeps the stable 1.0.9 gameplay feature set and intentionally does not include the experimental broad death-state compatibility rewrite that was tested locally, so future compatibility fixes can be handled one mod at a time.
Compatibility Strategy
- Kept raid failure settlement on the known 1.0.9 behavior.
- Kept the current focused compatibility approach instead of applying broad global player-state changes.
- Future compatibility fixes should target specific mods and specific events, reducing the chance of new side effects.
Raid Death And Return Stability
- Keeps the existing extraction-failure flow used by ordinary fatal damage, raid timeout, self
/kill, and PlayerRevive bleed-out handling. - Keeps the existing hideout-return timing, failure lock, and result sync behavior.
- Avoids broad immediate-respawn and persistent pending-death-return logic that could interact unpredictably with other mods.
Upgrade Notes
- Replace
lootrun-1.0.9.jarwithlootrun-1.0.10.jaron every client and the server. - LootRun 1.0.10 does not intentionally change map data, player data, custom hideouts, custom maps, prices, tasks, or loot chest settings.
- Existing 1.0.9 worlds should remain compatible.
- Back up the world and LootRun configuration before updating a production server.
Recommended Testing
- Test ordinary raid death and verify the extraction-failure screen appears.
- Test PlayerRevive bleed-out or give-up if that mod is installed.
- Return to the hideout after a failed raid and verify movement, jumping, sprinting, and status effects are normal.
- Enter a custom map and verify tasks, extraction points, custom loot chests, and custom hideout behavior still work as in 1.0.9.
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:9BfkbLEO:Hxzchwhp"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:9BfkbLEO:Hxzchwhp"
}

