Super Factory Manager is a mod for Minecraft that lets users create programs to run their factories. The mod provides a domain specific language tailored for moving items, fluids, and other resource types. A text editor is included, along with example programs.
To get started, you will need a factory manager, a label gun, and a disk.
Get the VSCode extension for syntax highlighting 🌈
The following process is designed to catch the most obvious problems that may arise from creating a new release.
.\act.ps1
Manual: Bump `mod_version` in gradle.properties
Manual: Commit bump
Action: Propagate changes
Action: Run gameTestServer for all versions
Action: Build
Action: Wipe jars summary dir
Action: Collect jars
Action: Update PrismMC test instances to use latest build output
Action: Update test servers to latest build output
Action: Launch PrismMC
Action: Launch test server
for each version:
Launch version from PrismMC
Multiplayer -> join localhost
Break previous setup
Build new setup from scratch -- ensure core gameplay loop is always tested
Validate changelog accuracy
/stop
Quit game
Action: Tag
Action: Push all
For each version:
CurseForge -> Upload file
"https://authors.curseforge.com/#/projects/306935/files/create"
Environment=Server+Client
Modloader=match mc version {
..1.20 -> Forge
1.20.1 -> Forge+NeoForge
1.20.2.. -> NeoForge
}
Java=Java 17
Minecraft=$version
Changelog= <<
```
$section from changelog.sfml
```
>>
For each version:
Modrinth -> Versions -> Drag n drop
"https://modrinth.com/mod/super-factory-manager/versions"
Adjust populated version numbers
Changelog=same as above
GitHub -> Draft a new release
"https://github.com/TeamDman/SuperFactoryManager/releases/new"
Choose a tag=latest
Target=latest
Release title=mod version
Description= <<
```
$section from changelog.sfml
```
>>
Attach=latest jar for each mc versionThere's some neat tricks used to improve the performance of the mod, here's an overview :D
The minimum timer interval of 1 second makes crappy programs 20x more performant since they aren't running every tick.
Be not afraid, regular expressions are only used when necessary.
Using the EACH keyword to count by type rather than by matcher also employs a cache.
EVERY 20 TICKS DO
INPUT 2 EACH *ingot* FROM a
OUTPUT TO b
END
This program will internally enumerate the registry to create a separate tracker for each resource type.
EVERY 20 TICKS DO
INPUT FROM a
OUTPUT TO b
END
When many inventories are involved, this can quickly result in a lot of objects being created when the program runs.
My testing shows that object pooling provides a slight increase in performance, even if there's only tens of thousands of objects involved.
I created a custom barrel block used only for testing. Running all the game tests for the mod creates 2,866 barrel blocks. Many of those barrels are so full of items that when I clear or restart the tests it causes 27,310 stacks to be dropped on the ground.
By creating a custom barrel that doesn't drop the inventory contents, the friction of doing more tests is reduced!
NAME "first"
EVERY 20 TICKS DO
INPUT FROM a
OUTPUT TO b
END
NAME "second"
EVERY 20 TICKS DO
INPUT stone, iron_ingot FROM a
OUTPUT TO b
END
Which program is more efficient? idk. Use the performance graph and compare.
Cool. Looks like the first one is twice as fast. Maybe you need to filter items though? Maybe the outcome is different if depending on the inventories?
Rather than trying to prescribe a best approach based on how I know the mod works, it's better to directly give the players the tools needed to perform experiments to find out what works best in their scenario.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent