All versions
0.2.0
Release
LogiGraph Factory Manager 0.2.03 weeks ago 3
Compatibility
Minecraft: Java Edition
26.1.2
Platform
NeoForge
Supported environments
Client and server
Changes
0.2.0 — 2026-06-15
Added
- Inventory popup — "SHOW ALL" button appears in the Node Details panel when an inventory holds more than 5 distinct item types. Opens a 360 px overlay listing every item with fixed columns (icon · name · mod · count). Dismissed by X, clicking outside, or Escape.
- Inventory sort controls — sort by Amount, Name, or Mod; click the active button or the standalone ▲/▼ button to flip ascending/descending (AE2-style). Amount defaults to descending, Name/Mod default to ascending.
- Inventory totals footer — shows type count, total item count, and number of full stacks of 64.
Changed
- Complete package rename:
net.doole.doolesutils→net.doole.doolestoolsacross all Java source files, resource directories, and build config. - README rewritten: emoji removed, prose tightened, formatting standardised.
- GUI header corrected from "DOOLE'S UTILS" to "DOOLE'S TOOLS".
- Scanner now sends up to 500 distinct item types per block (was 5) so the full inventory is available client-side without a follow-up request.
Fixed
LogisticsMonitorBlockEntitypersistence: replaced fragilehasLinkboolean + raw long pair withstoreNullable(BlockPos.CODEC). Forward-compatible with existing save data.ModMenusregistry holders typed asDeferredHolderinstead of rawSupplier.- Network string payloads (
SetBlockLabelPayload,SetGunLabelPayload) now cap label length at the Netty decode layer before server code runs. LogisticsScanner.probeDirections()no longer allocates a newDirection[7]on every capability query — extracted to astatic finalconstant.
0.1.0 — 2026-06-14
Initial release. Ships the LogiGraph MVP: a read-only logistics diagnostics and planning tool. No item/fluid/energy transport — observation and visualisation only.
Added
- Logistics Computer block — scans an 8-block cube on demand and hosts a
node-graph editor terminal. Manual-trigger and read-only; unreadable blocks are
reported as
UNKNOWNrather than crashing the scan. - Logistics Monitor block — mirrors the state of a linked Logistics Computer on a separate screen.
- Label Gun item — assign and view custom labels on nearby blocks, surfaced as in-world holograms on the client.
- Read-only scanner (
LogisticsScanner) covering inventory, fluid, energy, furnace/machine-progress summaries, with per-block try/catch guarding. - Node-graph editor — programmatic terminal-style GUI with draggable nodes,
links, ports, frames, and free text; design-space scaling with matched
hit-testing. All edits route through
LogisticsGraphso client and server apply identical rules. - Warnings — pure, side-effect-free diagnostics generated from scan data
(
WarningGenerator) and displayed in the terminal warning bar. - Networking — codec-driven C2S/S2C payloads (scan, clear, save graph, sync, labels, monitor mode). Every C2S handler validates the sender's open menu, target position, and chunk-loaded state, and sanitises/clamps all client-supplied graph data.
- Persistence — block-entity state via Value I/O; block labels stored in
world saved data (
BlockLabelSavedData). - CC:Tweaked soft integration — optional peripheral hooks that degrade gracefully when the mod is absent.
- Creative tab grouping the mod's blocks and items.
Technical
- Built for Minecraft 26.1.2 on NeoForge 26.1.2.76, Java 25, Gradle 9.1, ModDevGradle 2.x.
- Hard client/server split: all rendering/GUI code is isolated under
client/and gated byDist.CLIENT; client classes are referenced from common code only inside lambda bodies, so they never load on a dedicated server. - One Mojang
CODECper data record drives both persistence and networking.
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:RE8KiNaJ:st83F6VZ"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:RE8KiNaJ:st83F6VZ"
}

