Newly Generated SlimeWorlds with existing spawner YAML files cause NullPointException errors when mob attempts to spawn
Summary
SlimeWorlds with MythicMobs static spawners indicated in yml files that are deleted and recreated in a short timeframe, of which the new SlimeWorld has the same name as the deleted SlimeWorld, sends a NullPointException error when the spawner attempts to activate, unless approximately 1-5 minutes have passed or an administrator runs /mm reload
.
This issue was not tested with Multiverse.
This was created on Paper 1618 (1.12.2-R0.1-SNAPSHOT) with MythicMobs 4.9.0 build 3255 as well as 4.10.1 build 3456 non-premium.
Steps to reproduce
Create a yml file for a mob spawner for a given SlimeWorld.
Join the slimeworld and the mob will spawn.
Unload and delete the slimeworld, then create a new slimeworld from a template using the same name as before. In my example this is testbugworld5.
Join the new slimeworld and experience the NullPointerException error when attempting to activate the spawner by going within range. This passes after ~5 minutes or if /mm reload
is ran by an administrator.
Current behavior
When players join the newly created world, spawners do not work and MythicMobs do not spawn. Console spits out many NullPointerException errors. After a few minutes or if an administrator runs /mm reload
to relaunch the spawner activation code, spawners work again. No file changes are made during this time.
Intended correct behavior
It is intended that MM will recognize the player is within activation distance of the spawner and spawn the mobs according to the configuration file.
Server log file
Provide a link to a Pastebin paste with a copy of your server's latest.log file from startup to "Done!" AND includes a player connecting.
Debug log snippet
Provide a link to a Pastebin paste with an excerpt of your latest.log file that includes debug output where you trigger the bugged behavior.
Proposed fixes
Describe what you think the issue or any potential fixes may be.
If there is an internal index of worldnames and internal UUID's, update this index more frequently and possibly add a listener event for worldchanges to update this index.
Since it works after a few minutes, there is some sort of internal timer that is updating something of this behavior. Consider decreasing this timer length or add methods to force an update that could be configured by the server admins.