v1.3
Compatibility
Required content
Changes
Support for Kawamood's Waystones datapack 3.6.1+ added.
New features
-
Proper Waystone Models — Waystones now appear as proper 3D models for Bedrock players. These are created with the block sections attached to an invisible armor stand. These new models function just like the original java versions in that they allow proper attachment of things like torches and even allow snow to collect on the top of the Waystones. There are three models and four options to choose from; classic, legacy, modern, and default.
- classic — a model reminiscent of the original models I used for this plugin.
- legacy — mimics Kawamood's legacy models from the Waystones datapack.
- modern — mimics Kawamood's modern models from the Waystones datapack.
- default — sets the Waystones to represent the Waystone models that are set in the Waystones datapack. Note that changes to the datapack are not immediate and will take effect the next time a Bedrock player loads a chunk.
You can set the models in the config.yml or ingame by typing /pkcom set waystones followed by classic, legacy, modern, or default.
-
Customize The Waystone Inventory Screen — two options to choose from; classic and legacy.
- classic — the inventory screen native to Bedrock.
- legacy — mimics the java inventory screen by swapping the glass panes to look closer to what Java players see.
You can set which inventory screen to use in the config.yml or ingame by typing /pkcom set interface followed by classic or legacy.
Changes
- Removed my recipe workaround due to recipes from the datapack show now that the Waystones are using glowing item frames as placeholders instead of being player heads.
- Repurposed the icons that were used for my recipes to Kawamood's recipes and inventory icons so that they aren't showing up as glowing item frames for Bedrock players.
- Packetevents is used to reassign held and dropped Waystones back to the player heads for Bedrock players so that they're not showing up as glowing item frames.
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:QQebISPv:MI3ja9OP"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:QQebISPv:MI3ja9OP"
}
