Apotheosis

Apotheosis

81M Downloads

[BUG]The client's background is being spammed with error logs.

Tollainmear opened this issue · 10 comments

commented

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
commented

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

commented

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.

commented

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.

latest on gist
debug on gist

File:debug.log
File:latest.log

commented

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.

commented

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.

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
commented

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.

commented

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.

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

.mixin.out.zip

commented

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.

commented

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

commented

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