Tags
Creators
Details
Licensed ARR
Published 2 months ago
Updated 2 months ago
All versions
1.0.0
Beta
Bapel Auto Slimefun 1.0.02 months ago 34
Uploaded by
Compatibility
Minecraft: Java Edition
26.1.2
Platform
Fabric
Supported environments
Client-side
Required content
Any compatible version
Changes
Bapel Auto Slimefun 1.0.0
Highlights
- Refactored the large Auto-Craft implementation into focused modules for easier maintenance.
- Preserved the public
AutoCraftManagerAPI and SearchFix4.4 behavior. - Added exact Network Grid Search state handling.
- Fixed the Network Grid opening transaction becoming stuck at
40t. - Added sticky Backpack destination selection so one Backpack is filled before another is used.
- Fixed repeated deposit attempts when the active Backpack is already full.
- Added safe switching to another Backpack after its capacity is exhausted.
- Allowed actively extracted intermediate items, such as Carbon, to be staged when inventory space is required.
- Prevented crafting ingredients from repeatedly bouncing between player inventory and Backpack.
- Counted validated Backpack contents as part of Auto-Craft progress.
- Changed unstackable intermediate crafting to one recipe per execution cycle.
- Preserved safe-hand selection and temporary Backpack hotbar restoration.
- Preserved the missing-material HUD and existing scraper behavior.
Internal modularization
Auto-Craft responsibilities are now separated into modules for:
- lifecycle and job execution;
- Network Grid search and extraction;
- Backpack scanning and transfers;
- crafting-machine execution;
- GUI and container interaction;
- settings;
- cache and persistence;
- runtime utilities;
- Grid and Backpack state.
Release status
This version is marked Beta. Test with a small target quantity before starting a large Auto-Craft job.
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:2fuKmcFf:hoWvvRWX"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:2fuKmcFf:hoWvvRWX"
}

