Tags
Creators
Details
1.6.3
Compatibility
Changes
Takion 1.6.3
Major update from 1.3 to 1.6.3, focused on the new Gradle multi-module structure, cleaner published artifacts, stronger version compatibility helpers, improved game rule support, and a better chat component pipeline.
Added
- Added a Gradle multi-module project structure with
common,core,shaded, andpluginmodules. - Added published per-module artifacts under
me.croabeast.takion, includingcommon,core,shaded, andplugin. - Added a
shaded:allclassifier for users who want a larger bundled distribution with extra runtime libraries. - Added a dedicated
commonartifact for reusable utilities such as GUI helpers, reflection helpers, service access, webhook utilities, time utilities, and dependency helpers. - Added a dedicated
coreartifact for the main Takion API, managers, formatting, placeholders, channels, logging, messaging, bossbars, titles, and game rules. - Added VNC-based server/version compatibility checks.
- Added improved GameRule support through
GameRule,GameRuleManager, and version-aware rule resolution. - Added player-head hover formatting support through player head tokens/components.
- Added a configurable PrismaticAPI
ChatProcessorowned byTakionLib. - Added
getChatProcessor()andsetChatProcessor(...)so plugins can reuse Takion's default component processing or replace it when needed. - Added expanded README/Javadocs covering installation, module usage, common APIs, formatting, logging, game rules, and chat processor usage.
Changed
- Migrated the build and release flow from the old Maven-style layout to Gradle.
- Updated the publishing workflow to build and publish all Takion modules, source jars, javadocs, shaded jars, and release assets.
- Changed the Maven coordinates to the new
me.croabeast.takionmodule-based layout. - Merged the old
shaded-alldistribution into theshadedartifact as anallclassifier. - Updated PrismaticAPI to
1.5.0. - Updated CommandFramework to
1.2.1. - Updated VaultAdapter to
1.2. - Updated GlobalScheduler to
1.1. - Updated InventoryFramework support to
0.12.0. - Delegated Takion chat component handling to PrismaticAPI instead of maintaining local duplicated chat component classes.
- Modernized server metadata checks through VNC instead of older direct server-version logic.
- Simplified message formatting and color/component handling around the new PrismaticAPI flow.
- Refreshed the README installation examples for the current published artifacts and runtime choices.
Fixed
- Fixed GUI compatibility by updating InventoryFramework support.
- Fixed
TakionLibresolution so multiple plugins can resolve the correct library instance instead of falling back to the wrong provider. - Fixed animated bossbar update handling, including safer cleanup for offline players and more stable animation intervals.
- Fixed common plugin supplier compatibility by keeping
setPluginSupplier(...)as a deprecated bridge tosetPlugin(...). - Fixed version/docs drift by aligning
1.6.3usage examples, coordinates, and Javadocs with the new chat processor API.
Notes / Recommendations
- If you only need Takion APIs at compile time, use
commonand/orcoreas compile-only dependencies. - If you want a runtime jar with Takion bundled, use
shaded. - If you need the larger bundled runtime with extra dependencies, use
shaded:all. - If you deploy Takion directly as a plugin, use the
pluginartifact. - Plugins using interactive chat components should use
takion.getChatProcessor()instead of creating their own default processor. - Only use
setChatProcessor(...)when you intentionally need custom component preprocessing. - Existing integrations using
CommonServices.setPluginSupplier(...)should migrate toCommonServices.setPlugin(...), but the old method remains as a compatibility bridge. - All modules continue targeting Java 8 bytecode.
Supplementary resources
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:Z7kpjY2c:rmq1OK7h"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:Z7kpjY2c:rmq1OK7h"
}
