Links
Tags
Creators
Details
0.7.2-alpha+26.2
Compatibility
Changes
[0.7.2-alpha] - 2026-08-13
Fixed
- Moonrise compatibility crash at boot (#12). Moonrise replaces
the vanilla light engine internals, which removed the injection
targets of the two ThreadedLevelLightEngine diagnostic mixins and
hard-crashed the game at init. A mixin config plugin now detects
Moonrise and skips those two mixins; for now the
[light]monitor reports no data when Moonrise is installed, since Moonrise owns lighting at that point. A Moonrise-aware light probe may come later. Verified against Moonrise 1.1.0: boot, existing-world play, and fresh world creation all clean.
Changed
- Monitor logging defaults off on small heaps. Max heap of 3 GB
or less (Pi-class servers, often on slow SD-card I/O) now boots
with the periodic monitor reports silenced instead of paying ~5
log lines/sec. Counters still run;
/ferrite log monitors onor-Dferrite.log.monitors.on=truere-enables at any time. Normal heaps keep the old default. - Dispatch and oracle telemetry respects the small-heap monitor
default (PR #10, contributed by cwright814). The
[cramming-dispatch],[physics-dispatch],[redstone-oracle], and[chunkgen-features]periodic lines predate MonitorLog and bypassed it; on a Pi-class server they were most of the log file. Now routed through MonitorLog, so heaps of 3 GB or less boot with them silenced and/ferrite log monitors onre-enables them.
Added
-
Per-category log muting (#14).
/ferrite log <category> offsilences one monitor tag (physics-dispatch,cramming-dispatch,redstone-oracle, and every other bracket tag) without touching the rest;onresumes it on the next report window and/ferrite log statuslists what is muted. Counters keep running while muted. The global/ferrite log monitorsswitch is unchanged. -
Module toggles persist across restarts (#13). Cramming, the hopper layer, AC redstone, monitor logging, and muted log categories now save to
config/ferrite.propertieson every toggle and reload at boot. The file stores only deviations from defaults, so it stays empty (absent, in fact) until something is changed, and reverting a toggle removes its line. Diagnostic and experiment flags stay session-only on purpose, as does prewarm, since enabling it during boot breaks spawn loading. -
Entity spatial query index (opt-in,
-Dferrite.entityquery.cache=true). Sections holding 32+ entities get a per-section bitset grid (4-block cells); box queries visit only candidate entities in vanilla iteration order, so consumer order, abort semantics, and mid-tick liveness are preserved exactly. At a 1022-zombie farm: query cost 14.4-16.8 down to 10.3 ms/tick (34% cut), whole-server mspt 36-40 down to ~32.7, zero oracle mismatches across 83,000+ sampled queries. Default off pending broader soak;-Dferrite.entityquery.oracle=<1-in-N>enables field validation. -
-Dferrite.pregen.inflight=<n>sets the pre-gen inflight cap at boot (dedicated servers and headless benches; the runtime command still overrides). While adding it, the 200 default was re-validated on a constrained 4-core / 2 GB profile: 42.8 chunks/s vs 34.8 at cap 50, the same relationship as on desktop hardware, so the default stands on weak CPUs too. -
One-line hardware stamp at boot:
[hw] arch cores maxHeap jvm native monitors, so shared log excerpts self-describe the host they came from. Field reports from low-end hardware no longer need follow-up questions about specs. -
[entity-tick] misc-topbreakdown. When the misc entity bucket has a tick over 5 ms in a window, a second line names the top three entity types by time (total, worst single entity, count). Prompted by a Raspberry Pi field report (PR #8) where misc spiked to 47.8 ms with no way to tell which entity type was responsible.
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:c2DHmFvV:dJAkJVrU"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:c2DHmFvV:dJAkJVrU"
}

