Tags
Creators
Details
v2.0.3+26.1
Compatibility
Changes
NeoOrigins 2.0.3 — server boot fix + datapack auto-merge
Critical patch for anyone running NeoOrigins on a dedicated server: 2.0.0, 2.0.1, and 2.0.2 all crash at boot before the world loads. 2.0.3 fixes that. Also includes a quality-of-life change for datapack authors so origin packs no longer create a separate picker screen.
EntityMakeStuckInBlockMixin (a common mixin for cobweb-affinity)
contained an instanceof LocalPlayer check. Mixin resolves type
references at transform time, and LocalPlayer.class isn't on the
dedicated-server distribution — every server bricks at boot with
ClassMetadataNotFoundException. Singleplayer was unaffected because
the integrated server runs on the client distribution where
LocalPlayer exists.
Fix: trampoline the LocalPlayer reference through a new
ClientStuckInBlockHelper class. The mixin calls a static method on
the helper only inside level().isClientSide(); the helper class is
loaded lazily and only ever on the physical client. Server JVM never
resolves LocalPlayer.
Datapacks that ship their own e.g. erin:origin layer (the most
common Apoli/Origins-style structure) were creating a separate picker
screen alongside the main NeoOrigins origin tab. New
mergeForeignSamePathLayers pass folds any layer whose path is
origin or class into the canonical destination
(origins:origin or neoorigins:class respectively).
Pack authors who genuinely want a separate picker tab opt out via
"standalone": true on their layer JSON. INFO-level log line
announces each fold so debugging is straightforward:
Folded foreign layer erin:origin (7 origins) into origins:origin
Carried over from 2.0.2: the [sun_damage] block in
neoorigins-common.toml exposes helmet_dura_damage_chance
(default 0.07, range 0–1). Live-read each evaluation, so server
admins can tune helmet wear without restarting.
If you maintain a dedicated server running NeoOrigins, update immediately. There is no workaround for the 2.0.0–2.0.2 boot crash short of removing the mod or running on the integrated server.
Optional dependencies
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:RUtQ9kfe:9ky24sZ2"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:RUtQ9kfe:9ky24sZ2"
}


