juliarn
WrappedDataWatcher Error
This is with 1.21.3 and beta 10 using no provided packet factory (which defaults to ProtocolLib).
I switched to the PacketEvents factory which seems to work, but figured i'd log this issue anyway for ProtocolLib users.
java.lang.NullPointerException: Cannot invoke "java.util.Map.get(Object)" because "com.comphenix.protocol.wrappers.WrappedDataWatcher$Registry.RAW_REGISTRY" is null at ProtocolLib.jar/com.comphenix.protocol.wrappers.WrappedDataWatcher$Registry.get(WrappedDataWatcher.java:1031) ~[?:?] at TheArtifact.jar/com.github.juliarn.npclib.bukkit.protocol.ProtocolLibPacketAdapter.createWatchableObject(ProtocolLibPacketAdapter.java:247) ~[?:?] at TheArtifact.jar/com.github.juliarn.npclib.bukkit.protocol.ProtocolLibPacketAdapter.lambda$createEntityMetaPacket$12(ProtocolLibPacketAdapter.java:547) ~[?:?] at TheArtifact.jar/com.github.juliarn.npclib.api.protocol.DefaultNpcSpecificOutboundPacket.schedule(DefaultNpcSpecificOutboundPacket.java:57) ~[?:?] at TheArtifact.jar/com.n9works.bukkit.story.npcs.LokaNPCCopy.onShow(LokaNPCCopy.java:544) ~[?:?] at TheArtifact.jar/com.n9works.bukkit.story.npcs.NPCHandler.onNPCTrack(NPCHandler.java:151) ~[?:?] at TheArtifact.jar/com.github.juliarn.npclib.api.event.manager.DefaultNpcEventManager.post(DefaultNpcEventManager.java:76) ~[?:?] at TheArtifact.jar/com.github.juliarn.npclib.common.npc.CommonNpc.lambda$forceTrackPlayer$0(CommonNpc.java:203) ~[?:?] at org.bukkit.craftbukkit.scheduler.CraftTask.run(CraftTask.java:78) ~[slice-1.21.3.jar:1.21.3-DEV-e966e72] at org.bukkit.craftbukkit.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:57) ~[slice-1.21.3.jar:1.21.3-DEV-e966e72] at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22) ~[slice-1.21.3.jar:?] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
Was there a previous error during initialization of the registry? because just by looking at the code in ProtocolLib it does not look like the maps can be null at all, unless there is some sort of race between two threads initializing them.
Not really that I can see, I was using ProtocolLib v5.4.0-SNAPSHOT-736 for it