Tags
Creators
Details
6.0.0-beta.3
Compatibility
Changes
Version 6.0.0:
Updated to 1.20.5
This update introduces multiple breaking changes - a migration guide is available on the Ladysnake website.
Beta 3
Fixes
- Fixed the most basic binary incompatibilities with mods compiled for beta 1
Beta 2
Changes
- All the serialization methods now take an additional registry lookup argument
- Warning: due to the above change, level components may not be deserialized correctly if a mod calls
LevelProperties.readPropertiesinstead ofLevelStorage.parseSaveProperties
Removals
- The deprecated
utilpackage incardinal-components-blockhas been removed
Beta 1
Additions
- Added
C2SSelfMessagingComponent, a new experimental utility interface to simplify client-to-server messaging on player components - Added
WorldComponentRegistry#registerFormethods, allowing for dimension-specific world components - Scoreboard and team components now support client ticking
Changes
- Migrated all packages from
dev.onyxstudiostoorg.ladysnake - Updated documentation and licenses to reflect package change
RespawnCopyStrategynow also applies on mob conversion- The
cardinal-components-levelis now deprecated, as it is redundant with thecardinal-components-scoreboardmodule- Mods are encouraged to move to scoreboard components, which serve the same purpose of global data storage and have an API more consistent with other modules
Removals
- Removed item components. The
cardinal-components-itemmodule now contains anItemComponentMigrationRegistry, which is used to help you migrate to vanilla components. - Removed
PlayerCopyCallback- if you were using it, you can switch toServerPlayerEvents.COPY_FROMfrom Fabric API
see full changelog here
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:K01OU20C:ba9S2OFd"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:K01OU20C:ba9S2OFd"
}

