- Type: Bug
- Version: MythicMobs Premium
5.14.0-SNAPSHOT-60f8b0e6, Leaf1.21.4-525 - Evidence: our maintenance plugin put 2,442 mobs back into the registry on
dungeon-1, across the 11 shutdowns that logged a total - Location:
ActiveMob.tick,ActiveMob.setUnloaded
Checked against the decompiled production jar
5.14.0-SNAPSHOT-60f8b0e6.
Logs
[02:31:12] [OrphanCleaner] Total orphaned entities cleaned: 798
[01:49:30] [OrphanCleaner] Total orphaned entities cleaned: 317
[23:41:57] [OrphanCleaner] Total orphaned entities cleaned: 474
Log prefixes are shortened. Each total covers one server session.
What we had to work around
Our plugin scans loaded living entities every 6 seconds. It looks for entities that carry mythicmobs:type in their persistent data but are missing from the MythicMobs registry. After three scans in that state, it calls loadMythicMob to register them again.
Problem
One failed check removes the mob from the registry. In ActiveMob.tick, a single isValid() result of false calls setUnloaded(). For a persistent mob, that saves it and calls setInactive, which removes it from the registry.
The unload path is more careful. ChunkListeners.unloadChunkEntities waits 5 ticks and checks isValid() again before doing the same work. ActiveMob.tick has no such delay.
Nothing registers the mob again by itself. scanChunk only runs when entities or chunks load. If the entity stays in a loaded chunk, no load event follows. getMythicMobInstance can reload it lazily, but only if something looks that mob up.
The result is a mob that exists but is unknown to MythicMobs. Timers, skills and threat do not run for it until it is reloaded. I have not identified which condition makes isValid() return false on these servers.
Solution
- Use the same delayed recheck in
ActiveMob.tickas inunloadChunkEntities. - Add a safety path that registers loaded entities carrying
mythicmobs:typewhen they are missing from the registry. - Log a debug message when a mob becomes inactive while its entity is still valid.