Tags
Creators
Details
Licensed GPL-3.0-only
Published 8 months ago
Updated 2 months ago
All versions
2.3.1-core
Release
Teleport Commands Fabric (TPC) 2.3.1 Core3 months ago 35
Compatibility
Minecraft: Java Edition
26.2
26.1.x
Platforms
Fabric
Quilt
Supported environments
Server-side
Client and server
Required content
Any compatible version
Changes
TeleportCommandsFabric v2.3.1
This maintenance release focuses on stability, safety, and map integration reliability following the v2.3 release.
๐ Improvements
- Limited target chunk preload radius to a maximum of
3chunks- Existing larger values are normalized automatically
/tpc config teleporting preloadRadiusnow enforces the same range
- Improved
/tpc helpand/tpc statusso they report whether client map synchronization is available - Updated the bundled Xaero integration metadata to reflect its client-side runtime role
๐ Fixes
- Fixed teleport safety workers attempting to load missing chunks synchronously
- Safety warmup now waits for all required chunks to finish loading
- Parallel safety checks no longer fall back to worker-thread world chunk loading
- Fixed an asynchronous cleanup edge case that could remove a newly created or updated home/warp sharing the name of an older invalid waypoint
- Fixed a BlueMap lifecycle race that could access an outdated API instance while BlueMap was being disabled or reloaded
- Hardened current and legacy map synchronization packets against malformed waypoint counts and unsafe client-side memory allocation
๐ฆ Upgrade Notes
- No config or storage migration is required
- Both Standard and Core builds retain the same core teleport and storage behavior
- Updating from
2.3to2.3.1is recommended
Supplementary resources
| File | Type | Size | |
|---|---|---|---|
| tpc-fabric-26.1.2-2.3.1-core-sources.jar | Sources jar | 439.93 KiB |
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:ez3Wxkfr:T1xaVfnw"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:ez3Wxkfr:T1xaVfnw"
}

