CC: Tweaked 1.117.1 for Minecraft 1.21.1
This is the documentation for CC: Tweaked 1.117.1 for Minecraft 1.21.1. Documentation for other versions of Minecraft are available on the CC: Tweaked website:
Quick links
You probably want to start in the following places:
- Registering new peripherals
-
LuaFunctionandIArgumentsfor adding methods to your peripheral or Lua objects. - Turtle upgrades
- Pocket upgrades
Using
CC: Tweaked is hosted on my maven repo, and so is relatively simple to depend on. You may wish to add a soft (or
hard) dependency in your mods.toml file, with the appropriate version bounds, to ensure that API
functionality you depend on is present.
repositories {
maven {
url "https://maven.squiddev.cc"
content { includeGroup("cc.tweaked") }
}
}
dependencies {
// Vanilla (i.e. for multi-loader systems)
compileOnly("cc.tweaked:cc-tweaked-1.21.1-common-api:1.117.1")
// Forge Gradle
compileOnly("cc.tweaked:cc-tweaked-1.21.1-core-api:1.117.1")
compileOnly(fg.deobf("cc.tweaked:cc-tweaked-1.21.1-forge-api:1.117.1"))
runtimeOnly(fg.deobf("cc.tweaked:cc-tweaked-1.21.1-forge:1.117.1"))
// Fabric Loom
modCompileOnly("cc.tweaked:cc-tweaked-1.21.1-fabric-api:1.117.1")
modRuntimeOnly("cc.tweaked:cc-tweaked-1.21.1-fabric:1.117.1")
}
You should also be careful to only use classes within the dan200.computercraft.api package. Non-API
classes are subject to change at any point. If you depend on functionality outside the API (or need to mixin to
CC:T), please start a discussion to
let me know!
Updating from Minecraft 1.20.1 to 1.21.1
Peripherals
-
On NeoForge, the peripheral capability has migrated to NeoForge's new capability system.
dan200.computercraft.api.peripheral.PeripheralCapabilitycan be used to register a peripheral.IPeripheralProviderhas also been removed, as capabilities can now be used for arbitrary blocks.
Read more on registering peripherals.
Turtle and pocket upgrades
Turtle and pocket upgrades have been migrated to use Minecraft's dynamic registries. While upgrades themselves have not changed much, the interface for registering them is dramatically different.-
TurtleUpgradeSerialiserandPocketUpgradeSerialiserhave been unified into a singleUpgradeTypeclass-
Replace
TurtleUpgradeSerialiser.registryId()withITurtleUpgrade.typeRegistry()andPocketUpgradeSerialiser.registryId()withIPocketUpgrade.typeRegistry(). -
Replace all other usages of
TurtleUpgradeSerialiserandPocketUpgradeSerialiserwithUpgradeType.
-
Replace
-
Upgrades are now (de)serialised using codecs, rather than manually reading from JSON and encoding/decoding
network packets. Instead of subclassing
UpgradeType, it is recommended you useUpgradeType.create(MapCodec)to create a new type from aMapCodec. - Upgrades are no longer aware of their ID, and so cannot compute their adjective. The adjective must now either be hard-coded, or read as part of the codec.
-
The upgrade data providers have been removed, in favour of mod-loaders built-in support for dynamic registries.
I'm afraid it's probably easier if you delete your existing upgrade datagen code and start from scratch. See
the
ITurtleUpgradedocumentation for an example. -
Upgrades now store their additional data (
ITurtleAccess.getUpgradeData(TurtleSide),IPocketAccess.getUpgradeData()) as an immutable component map, rather than a compound tag.