1.2.4
Compatibility
Changes
v1.2.4
This pull request makes significant improvements to the build and release automation, enhances configuration flexibility, and introduces a new configurable view distance for nametags. The main changes are the consolidation and enhancement of CI workflows, updates to configuration handling, and improvements to how nametag visibility is managed in-game.
Build & Release Automation:
- Consolidated the separate
main.ymlandalpha.ymlGitHub Actions workflows into a single, unified workflow file (release-and-publish.yml) that handles both themainandalphabranches, automates tagging, artifact uploads, and publishing to GitHub Releases, Hangar, and Modrinth. This streamlines maintenance and ensures consistent behavior across release channels. [1] [2] [3]
Configuration System Enhancements:
- Migrated from the custom
Configclass to the more robustYamlConfigclass for all configuration files in theConfigsclass, improving type safety and YAML handling. - Updated configuration migration logic to support new config versions and ensure seamless upgrades, including auto-migration for the new
view_distancesetting.
Nametag View Distance Feature:
- Added a new
view_distanceconfiguration option (default: 64 blocks) to both default and main config files, allowing server owners to control how far away nametags are visible. [1] [2] - Updated the nametag rendering logic in
NametagHandlerto use the newview_distancevalue when calculating the visibility range for nametags.
Other Improvements:
- Minor code cleanup and import optimizations in
NametagHandlerfor better readability and maintainability. - Bumped the plugin version from
1.2.3to1.2.4to reflect these new features and improvements.
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:Ksss1YfG:jndW8Nut"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:Ksss1YfG:jndW8Nut"
}

