Tags
Creators
Details
Licensed LGPL-3.0-or-later
Published last year
Updated 3 weeks ago
All versions
0.3.0-alpha
Alpha
Complexity Analyzer 0.3.0-alpha11 months ago 65
Compatibility
Minecraft: Java Edition
1.21.1
Platform
NeoForge
Supported environments
Client and server
Changes
v0.3.0-alpha: Global update
๐ Major Architectural Rework
- Rewritten Complexity Solver: The core
IterativeSolverhas been replaced with anEnhancedIterativeSolverto support multi-layered resource analysis. The new engine now calculates complexity across three distinct layers: Items -> Fluids -> Chemicals. - Full Fluid & Chemical Support:
- Added
FluidIngredientSlotandChemicalIngredientSlotto represent non-item resources in recipes. RecipeGraphnow includes methods for analyzing fluid and chemical production chains (e.g.,getRecipesProducingFluid,getItemsUsingFluid).- The entire analysis pipeline, from recipe parsing to tree visualization, is now aware of these new resource types.
- Added
โจ New Features
- Machine Infrastructure Cost ("Machine Tax"):
- Implemented a new configurable system to factor in the cost of machinery into recipe complexity.
- By default, adds 7.5% of a machine's own complexity to each craft it performs.
- This feature can be enabled/disabled and its percentage can be configured.
- Automatic Machine Detection:
- The engine now automatically discovers which machine (catalyst) is used for each recipe type by hooking into JEI's plugin data. This eliminates the need for manual configuration files.
- Redesigned Crafting Tree System:
- The
/complexity treecommand now uses a newCraftingTreeBuilderthat correctly visualizes multi-resource type recipes. - Fluids (๐ง) and chemicals (๐งช) are now displayed in the crafting tree alongside items.
- Added detailed hover-tips with information about recipes and the machines used.
- The
๐ Improvements
- JEI Integration Overhaul:
- The
AdaptiveRecipeConverterhas been completely rewritten for improved robustness and extensibility. - Enhanced reflection-based parser can now dynamically extract item, fluid, and chemical inputs/outputs from a wide range of modded recipes, including those using modern Java records.
- Improved sandboxing ensures server stability when parsing JEI plugins that contain client-side code.
- The
- Performance Optimizations:
- Implemented batch processing and intelligent queue management in the solver's refinement phase, resulting in a performance increase of up to 160x on large modpacks.
- Improved caching strategies for recipe costs.
- Dynamic Recipe Reclassification:
- The engine now performs a post-analysis pass to dynamically reclassify "reverse" recipes (e.g.,
Ingot -> Dust) asPROCESSING. This prevents logical paradoxes in the crafting graph and ensures the solver always prefers the most efficient production path.
- The engine now performs a post-analysis pass to dynamically reclassify "reverse" recipes (e.g.,
- Resource Source Analysis:
EmpiricalBlockSource(Geo-Scanner) now analyzes and stores data for each dimension separately, providing more accurate resource rarity values.
๐ Bug Fixes
- Fixed Cyclic Dependencies: Resolved the core issue where the crafting tree would enter an infinite loop on certain recipe chains. The tree now correctly displays cycles as base resources.
- Fixed
NoClassDefFoundError: Improved error handling and class loading to prevent server crashes related to client-side JEI classes. - Fixed Fluid Normalization: Correctly handles flowing vs. source fluid types in recipe ingredients.
๐ง Technical & Build
- Project refactoring:
DatapackSyncHandlerrenamed toAnalysisBootstrapfor clarity. - Added
.vscode/settings to.gitignore.
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:RQjlpUyI:TtvKudDR"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:RQjlpUyI:TtvKudDR"
}

