Tags
Creators
Details
4.3.0
Compatibility
Changes
Ghost Pokemon Fix
We identified three causes of ghost (phantom) Pokemon entities:
- Redundant entity.discard() in AdaptiveSpawnManager — When blocking a spawn, the code called both event.cancel() and entity.discard(). The cancel alone is sufficient; the extra discard created a race condition where the entity tracker could send spawn packets to clients before the entity was removed server-side, leaving a visible but non-interactive ghost on the client.
- Missing velocity sync in MobEntityAiMixin — When AIFreeze zeroed a Pokemon's horizontal velocity, it never flagged the entity for network sync. The server had the Pokemon stopped, but the client kept rendering it with the old velocity, causing visual drift/desync. Fixed by setting velocityDirty = true (Fabric) / hasImpulse = true (NeoForge) after zeroing velocity, which forces the entity tracker to send the updated velocity to all clients.
- Silent exception swallowing in GhostEntityHandler — The early delegate.tick() calls that prevent ghost entities were catching all exceptions silently. Now they log at DEBUG level with species name and position, making it possible to diagnose any remaining ghost issues.
ServerCore Compatibility
ServerCore and CobbleOptimizer both inject into the same method (tickNewAi / customServerAiStep) to skip entity AI ticks. When both mods are loaded, they independently cancel the AI tick — causing Pokemon to never get their AI processed, leading to unresponsive ghost-like entities.
Solution: Created a ServerCoreCompat module that:
- Auto-detects ServerCore at startup via the mod loader API
- When detected, suppresses TickThrottle and AIFreeze (the two features that conflict with ServerCore's entity activation ranges)
- Keeps AdaptiveSpawn, BatchDespawn, and Emergency active (these use Cobblemon events and periodic sweeps, not AI tick injection)
- Logs a clear warning at startup explaining what was disabled and why
- Adds a config option compat.auto_disable_with_servercore (default true) so users can override the behavior if needed, reloadable at runtime
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:qPJLoYyi:bJeSv6Lp"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:qPJLoYyi:bJeSv6Lp"
}

