Tags
Creators
Details
1.1.0-1.21.1
Compatibility
Required content
Changes
v1.1.0 — Dimension Teleportation Crash Fix
🐛 Fixed: Princess Hold Dimension Teleport Crash
Fixed a server crash issue reported by CurseForge users: When a player in a princess hold jumps into a dimension teleportation portal (such as the Underworld or End), it causes the related players to crash and be unable to rejoin the server, and may prevent the server from shutting down normally.
Problem Description
- When a player in a princess hold enters a dimension teleportation portal, the riding relationship between the held player and the carrier player is damaged across dimensions
- The affected players crash when attempting to rejoin the server and cannot reconnect
- Damaged player data may prevent the server from shutting down normally
Fix Solution
- Added dimension teleportation event listener (
EntityTravelToDimensionEvent) to trigger before entity teleportation - When the teleporting player is in a princess hold (as a carrier or passenger), cleanly break the princess hold in advance
- The carrier player can still pass through the teleportation portal normally, while the held player remains in the original dimension, fundamentally avoiding cross-dimensional damage
🔧 Technical Changes
- Added
onEntityTravelToDimensionevent handler to theMCARomanticExpansionmain class - Reused
CarryRuntime.stopCarryForto remove the riding relationship, clear the pairing status, and broadcast client synchronization - Applies to all dimension teleportation portals (Underworld portal, End portal, and mod dimension portals)
Note: This fix only prevents new crashes. For damaged player save files (NBT containing a reference to the player's
RootVehicletag), manually edit the corresponding player.datfile to remove this tag, or delete the player data file to allow them to rejoin.
Optional dependencies
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:yGNIAsvP:gqwEPFmM"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:yGNIAsvP:gqwEPFmM"
}

