[BUG]The client's background is being spammed with error logs.
Tollainmear opened this issue · 10 comments
Firstly, this is an issue that can only be reproduced on the server; I have not encountered the same error logs in local gameplay.
When the client connects to a server with the Apotheosis mod loaded, the output log is spammed with errors. The keyword to look for is:
[023月2024 02:56:03.029] [Render thread/WARN] [net.minecraft.client.multiplayer.ClientPacketListener/]: Entity Bat['蝙蝠'/346, l='ClientLevel', x=31.88, y=3.64, z=-52.98] does not have attribute null
[023月2024 02:56:03.029] [Render thread/ERROR] [net.minecraft.util.thread.BlockableEventLoop/FATAL]: Error executing task on Client
java.lang.NullPointerException: Cannot invoke "net.minecraft.world.entity.ai.attributes.AttributeInstance.m_22135_()" because "inst" is null
at net.minecraft.client.multiplayer.ClientPacketListener.handler$zzj000$apoth_postAttrChangedEvent(ClientPacketListener.java:2571) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.client.multiplayer.ClientPacketListener.m_7710_(ClientPacketListener.java:2222) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.network.protocol.game.ClientboundUpdateAttributesPacket.m_5797_(ClientboundUpdateAttributesPacket.java:59) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.network.protocol.game.ClientboundUpdateAttributesPacket.m_5797_(ClientboundUpdateAttributesPacket.java:15) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.client.multiplayer.ClientPacketListener.m_264308_(ClientPacketListener.java:2305) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.network.protocol.game.ClientboundBundlePacket.m_5797_(ClientboundBundlePacket.java:13) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.network.protocol.game.ClientboundBundlePacket.m_5797_(ClientboundBundlePacket.java:6) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.network.protocol.PacketUtils.m_263899_(PacketUtils.java:22) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.util.thread.BlockableEventLoop.m_6367_(BlockableEventLoop.java:156) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.util.thread.ReentrantBlockableEventLoop.m_6367_(ReentrantBlockableEventLoop.java:23) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.util.thread.BlockableEventLoop.m_7245_(BlockableEventLoop.java:130) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.util.thread.BlockableEventLoop.m_18699_(BlockableEventLoop.java:115) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.client.Minecraft.m_91383_(Minecraft.java:1106) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.client.Minecraft.m_91374_(Minecraft.java:718) ~[client-1.20.1-20230612.114412-srg.jar%23164!/:?]
at net.minecraft.client.main.Main.main(Main.java:218) ~[Karoglan-TFC-Create.jar:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
at net.minecraftforge.fml.loading.targets.CommonLaunchHandler.runTarget(CommonLaunchHandler.java:111) ~[fmlloader-1.20.1-47.2.20.jar:?]
at net.minecraftforge.fml.loading.targets.CommonLaunchHandler.clientService(CommonLaunchHandler.java:99) ~[fmlloader-1.20.1-47.2.20.jar:?]
at net.minecraftforge.fml.loading.targets.CommonClientLaunchHandler.lambda$makeService$0(CommonClientLaunchHandler.java:25) ~[fmlloader-1.20.1-47.2.20.jar:?]
at cpw.mods.modlauncher.LaunchServiceHandlerDecorator.launch(LaunchServiceHandlerDecorator.java:30) ~[modlauncher-10.0.9.jar:?]
at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:53) ~[modlauncher-10.0.9.jar:?]
at cpw.mods.modlauncher.LaunchServiceHandler.launch(LaunchServiceHandler.java:71) ~[modlauncher-10.0.9.jar:?]
at cpw.mods.modlauncher.Launcher.run(Launcher.java:108) ~[modlauncher-10.0.9.jar:?]
at cpw.mods.modlauncher.Launcher.main(Launcher.java:78) ~[modlauncher-10.0.9.jar:?]
at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:26) ~[modlauncher-10.0.9.jar:?]
at cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:23) ~[modlauncher-10.0.9.jar:?]
at cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:141) ~[bootstraplauncher-1.1.2.jar:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
at oolloo.jlw.Wrapper.invokeMain(Wrapper.java:71) ~[?:?]
at oolloo.jlw.Wrapper.main(Wrapper.java:51) ~[?:?]
I have noticed the keyword apoth_postAttrChangedEvent
. Is this an exception triggered by Apotheosis? Although I have not yet observed any impact on the gaming experience, I believe it could potentially have negative effects on the game's performance. If possible, I hope this issue can be resolved.
The full log is as follows: https://gist.github.com/Tollainmear/55ab2093566e44f6f42afaca7c2333e6
Envinfo:
- Mc 1.20.1
- ForgeVer 47.2.20
Modlist:
- Apotheosis-1.20.1-7.3.1
- Placebo-1.20.1-8.6.1
- Patchouli-1.20.1-84-FORGE
- ApothicAttributes-1.20.1-1.2.1
Codec failure for type affixes, message: Unknown registry key in ResourceKey[minecraft:root / minecraft:attribute]: forge:step_height
outdated datapack files?
the attribute should be named forge:step_height_addition
you need to fix these:
affix: apotheosis:armor/attribute/elastic
gem: apotheosis:core/solar
gem: apotheosis:overworld/royalty
The code path you are seeing a NPE in is already guarded by a null check at the injection site:
for(ClientboundUpdateAttributesPacket.AttributeSnapshot clientboundupdateattributespacket$attributesnapshot : pPacket.getValues()) {
AttributeInstance attributeinstance = attributemap.getInstance(clientboundupdateattributespacket$attributesnapshot.getAttribute());
if (attributeinstance == null) {
LOGGER.warn("Entity {} does not have attribute {}", entity, BuiltInRegistries.ATTRIBUTE.getKey(clientboundupdateattributespacket$attributesnapshot.getAttribute()));
} else {
attributeinstance.setBaseValue(clientboundupdateattributespacket$attributesnapshot.getBase());
attributeinstance.removeModifiers();
// First injection point
for(AttributeModifier attributemodifier : clientboundupdateattributespacket$attributesnapshot.getModifiers()) {
attributeinstance.addTransientModifier(attributemodifier);
}
// Second injection point
}
}
You may have another mod applying a mixin to the same site, causing my injection to be incorrect, but since you have only provided the latest.log I cannot investigate further. I need at the very least the debug.log file, or a mixin debug export of the ClientPacketListener
class.
The code path you are seeing a NPE in is already guarded by a null check at the injection site:
for(ClientboundUpdateAttributesPacket.AttributeSnapshot clientboundupdateattributespacket$attributesnapshot : pPacket.getValues()) { AttributeInstance attributeinstance = attributemap.getInstance(clientboundupdateattributespacket$attributesnapshot.getAttribute()); if (attributeinstance == null) { LOGGER.warn("Entity {} does not have attribute {}", entity, BuiltInRegistries.ATTRIBUTE.getKey(clientboundupdateattributespacket$attributesnapshot.getAttribute())); } else { attributeinstance.setBaseValue(clientboundupdateattributespacket$attributesnapshot.getBase()); attributeinstance.removeModifiers(); // First injection point for(AttributeModifier attributemodifier : clientboundupdateattributespacket$attributesnapshot.getModifiers()) { attributeinstance.addTransientModifier(attributemodifier); } // Second injection point } }You may have another mod applying a mixin to the same site, causing my injection to be incorrect, but since you have only provided the latest.log I cannot investigate further. I need at the very least the debug.log file, or a mixin debug export of the
ClientPacketListener
class.
Hi, here is my latest.log and debug.log file.
Based on the debug log, the only other mod with a mixin into ClientPacketListener
is nochatreports, which doesn't mixin into this method (handleUpdateAttributes
). So the only thing that I can potentially look at is a mixin debug export of ClientPacketListener
.
To retrieve this, you will need to launch with -Dmixin.debug.export=true
and -Dmixin.debug.export.filter=ClientPacketListener
. The generated file will then be in your <instance>/.mixin.out/
folder.
Based on the debug log, the only other mod with a mixin into
ClientPacketListener
is nochatreports, which doesn't mixin into this method (handleUpdateAttributes
). So the only thing that I can potentially look at is a mixin debug export ofClientPacketListener
.To retrieve this, you will need to launch with
-Dmixin.debug.export=true
and-Dmixin.debug.export.filter=ClientPacketListener
. The generated file will then be in your<instance>/.mixin.out/
folder.
Hello, thank you for your patient help. I followed the method you mentioned and added the corresponding parameters to my MC's startup parameters. However, I did not find the mixin.out
folder you mentioned anywhere. Here are the parameter sets of the startup script I used. Did I do something wrong?
-XX:+UseG1GC -XX:-UseAdaptiveSizePolicy -XX:+ExplicitGCInvokesConcurrent -XX:-OmitStackTraceInFastThrow -Dfml.ignoreInvalidMinecraftCertificates=True -Dfml.ignorePatchDiscrepancies=True -Dlog4j2.formatMsgNoLookups=true -Dmixin.debug.export=true -Dmixin.debug.export.filter=ClientPacketListener
The syntax for the filter is not exactly specified (at https://github.com/SpongePowered/Mixin/wiki/Mixin-Java-System-Properties)
It may need to be =ClientPacketListener.class
instead of =ClientPacketListener
Alternatively you can drop the entire -Dmixin.debug.export.filter=ClientPacketListener
argument. It will cause all mixin classes to be exported (and may take a while), but the ClientPacketListener
export will be there.
The syntax for the filter is not exactly specified (at https://github.com/SpongePowered/Mixin/wiki/Mixin-Java-System-Properties) It may need to be
=ClientPacketListener.class
instead of=ClientPacketListener
Alternatively you can drop the entire
-Dmixin.debug.export.filter=ClientPacketListener
argument. It will cause all mixin classes to be exported (and may take a while), but theClientPacketListener
export will be there.
Hi, thanks again for your help. After trying to replace =ClientPacketListener
with =ClientPacketListener.class
, I still didn't find mixin.out
anywhere. However, when I dropped the entire -Dmixin.debug.export.filter=ClientPacketListener
field as you said, Mixin.out appeared. I found ClientPacketListener.class
there. Considering that you may need other class files and to avoid omissions, I have packaged this directory. I hope this can resolve the issue this time.
I think the class path is
.mixin.out\class\net\minecraft\client\multiplayer\ClientPacketListener.class
The only differences in the bytecode are the absence of
140: new #4874 // class org/spongepowered/asm/mixin/injection/callback/CallbackInfo
143: dup
144: ldc_w #4875 // String handleUpdateAttributes
147: iconst_0
148: invokespecial #4878 // Method org/spongepowered/asm/mixin/injection/callback/CallbackInfo."<init>":(Ljava/lang/String;Z)V
which has been replaced with 140: aconst_null
(probably due to an optimization eliding CallbackInfo
when unnecessary) - this will not cause the issue we are seeing here.
The injection point is still within the loop, as it is still before the final goto
in both cases.
Ah, hell, wait a second. I've realized there isn't an explicit continue
statement in the if-block, which means the jump isn't to the head of the loop, but rather to the end.
This means if the modifier is null it will still hit my hook, so I need to account for that there.
This does mean something weird is going on - which looking back at the logs, something exceptionally weird is going on, because the attribute is null
. This means a ClientboundUpdateAttributesPacket
is being sent with attributes the client has no knowledge of whatsoever, which typically would indicate a screwed up instance (or at the very least a mod mismatch where something is absent from the client).
I can add in a nullcheck, but your instance is broken. You should double check that all mods are present on both sides of the server/client.
Hi there, have the same problem and its VERY annoying cuz the server logs will be massive. Can't afford this mod in modpack until there will be a fix. PLEASE PLEASE fix it, I don't want to delete your mod from modpack, it's so big and usefull
This is an external problem, even if I nullcheck on my end, you will still be spammed by the vanilla log message (below) until you fix the issues with your game instance.
[023月2024 02:56:03.029] [Render thread/WARN] [net.minecraft.client.multiplayer.ClientPacketListener/]: Entity Bat['蝙蝠'/346, l='ClientLevel', x=31.88, y=3.64, z=-52.98] does not have attribute null