Tags
Creators
Details
1.1.0
Compatibility
Required content
Changes
v1.1.0 — M4 complete
Rolls up the five builds of the 1.0 line. If you are on v1.0.0, upgrade — it has two confirmed critical defects, both fixed here.
Minecraft 1.21.1 · Java 21 · NeoForge, Fabric, Forge
What changed
/execute as <player>no longer borrows that player's NexusCore permissions. A substituted command source is refused, and both the audit actor and the rate-limit subject resolve to the real issuer.- The same fix closed two confused-deputy paths: a
run_commandclick event on a sign, or in a written book on a lectern, built a privileged command source with the clicking player as the entity. /teleportno longer bypasses NexusCore. Only/tpwas taken over before, so/teleportran as pure vanilla — no permission check, no rate limit, no audit record.- Two permission values that failed open now fail closed, and
permissions.jsonis genuinely re-read on/nexus reloadinstead of being silently overwritten. - NexusCore now owns the vanilla commands it replaces —
/ban/kick/banlist/pardon/list/tp/teleport/gamemode. Opt out withoverrideVanillaCommands=false. - Safe mode: start with
-Dnexuscore.safemode=trueto run only the core modules and recover a server you otherwise cannot start. - The command reference is generated from the code and cannot drift — 50 commands, in
docs/admin/commands.md.
Known limitations
/seen <unknown name>can stall the server.IdentityService.resolve()falls back to a blocking Mojang HTTP lookup on the server thread, so a slow or unreachable Mojang API stalls the whole server for as long as the request takes. Reachable by any ordinary player. First item scheduled for1.1.1.- Vanish misbehaves for onlookers. Four related faults that appear only on another player's client: chat renders as a validation error, un-vanishing does not restore the entity for clients that saw it vanish, vanish is not re-applied to players who join later, and the vanished set survives death while the invisibility flag does not.
- A second ban or mute does not deactivate the first.
/unbanlifts one and reports success while the player stays banned; active counts double-count, and the strictest record is not the one returned. audit.lognever rotates. It is read fully into heap and SHA-256'd on the server thread at startup, at shutdown, and on everyverifyandtail— unbounded growth plus a synchronous full read.- A transient read error can quarantine an intact
permissions.json.JsonStore.read()quarantines on anyIOException, so a one-off read failure moves a healthy file aside and the next boot starts from defaults. config.jsonsilently loses operator keys. Loading rewrites the file from the typed object, deleting any key the schema does not know, while reportingno problems found.players.jsonis rewritten in full on every login and logout. Never pruned, and each write copies a full.bakand fsyncs twice.- Fabric death messages lose their cause. Every styled death reads
<Player> died— on Fabric only. /pardonand/banliststrand vanilla ban state. Pre-takeover vanilla bans become un-liftable, and/ban-ipand/pardon-ipare separate commands NexusCore never takes over, so IP bans are neither audited nor listed.- Only one player has ever been online at a time during testing. Everything that needs a second player is unverified — including the four vanish faults above, which appear only on another player's client.
- Every remaining confirmed defect, down to
low, is listed in IMPLEMENTATION_STATUS.md rather than withheld.
Upgrading
Existing servers need one operator action after upgrading from 1.0.0: /nexus permission group add default nexuscore.command.core.confirm
Verified
214 automated tests; all three loaders build reproducibly and CI builds all three from a bare checkout. Re-verified 2026-07-27 against the archived release bytes on all three loaders: the installed jar was confirmed by SHA-256 to be byte-identical to archived/v1.1.0/, /nexus version reported 1.1.0, /execute as against a summoned armor stand was refused, the audit chain verified intact, and no NexusCore error was logged. Reproduce with ./verify-release-jar.sh <loader> 1.1.0.
Checksums
0b8a5fccc5b0f57b62a342a17ae9d1a7ceeb4dfa7e74e00d9b887bb434cd94dc NexusCore-neoforge-1.1.0-1.21.1.jar
a64e845769e8e9bdd8971f0346ed7fd8c070ba426a65d41a7c2f7ba51b9bf212 NexusCore-fabric-1.1.0-1.21.1.jar
4a14fffdf78477a1b09271df861ee2f508d6bbc691292ff1371ed8ceb34f2f44 NexusCore-forge-1.1.0-1.21.1.jar
Full notes: https://github.com/Modzwastaken/NexusCore-Mod-NCM/releases/tag/v1.1.0
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:3vfjItZT:9WBKIjn4"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:3vfjItZT:9WBKIjn4"
}

