Tags
Creators
Details
v0.3.1-mc1.21.1
Compatibility
Required content
Changes
Bug-fix release for Minecraft 1.21.1 (Fabric + NeoForge).
Fixed
Premium players now get their skin and cape (#6)
The Mojang session server returns the player's signed profile properties — textures, which carries the skin and cape — alongside the id and name. Vouch was reading only the id and name out of that response, so the profile handed to the server had an empty property map. Premium UUID and inventory were correct; the player rendered as Steve or Alex. The response is now parsed properly and the signed properties are preserved.
New option, on by default:
[auth]
premium_fetch_skins = true
NeoForge servers no longer crash at startup (#8, thanks @denmoth)
BouncyCastle ships signed and multi-release. Once its classes were relocated into the mod jar, the signature files no longer matched and NeoForge's ModuleClassLoader refused to load it. Reported and tested on a NeoForge 1.21.1 server with 300+ mods.
The same fault, latent in the Fabric jar
While verifying the fix above, the Fabric jar turned out to still ship META-INF/services/java.security.Provider naming org.bouncycastle.jce.provider.BouncyCastleProvider — a class that no longer exists there after relocation, so any ServiceLoader pass over security providers would hit ServiceConfigurationError. Both platforms are now sanitised by a shared build step, and the build fails if that metadata ever returns.
Added
Brazilian Portuguese — thanks @guigiffoni. Vouch now ships English, Spanish (Mexico), Brazilian Portuguese, Russian and Ukrainian.
Changed
CurseForge is no longer a distribution channel. Vouch is published on Modrinth and GitHub Releases.
Upgrading: drop-in replacement for 0.3.0. No configuration or database changes required.
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:E4nhP7pz:K9TiyjU2"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:E4nhP7pz:K9TiyjU2"
}

