WTHIT

WTHIT

10M Downloads

Cursed chest immediately disconnects us from our server

sleepyuwus opened this issue ยท 7 comments

commented

Describe the issue

I play on a server with a friend, and somehow he managed to curse one of his chests? This problem occurs to both of us.
When we look at the chest, we get disconnected. Moving our client-sided wthit-fabric-12.2.2 out of our mods folder fixed the issue for both of us.

Crazily enough, he blew up the first chest, but the issue returned on another chest that previously worked. (probably the first one he interacted with) Before he did we could both access the chest just fine. And also after we removed the mod there have not been any issues.

Mind you we use a handful of mods, so it could be an interaction thing. Unfortunately as long as this issue persists, we are unable to use the mod for now. I hope this helps someone.

Log output and crash report

log output in additional context

Additional context

disconnect-2024-07-07_23.42.23-client.txt
2024-07-08-4.log

commented

Try disabling the tooltip, it should not trigger it if its hidden.
Can I get a data dump of the chest? run the /data get block x y z command.

commented

Sorry for the late response.
SO. Obviously disabling the tooltip worked.
The data dump is probably not so important anymore because i figured out the problem. It is an interaction with this mod: https://modrinth.com/mod/universal-graves
When one of us dies, we get a grave compass that leads us to our grave. Normally this compass disappears if you pick up your stuff, so i didn't bother disabling the compass in the plugins options. If a grave compass is inside the chest, the tooltip probably cannot keep up? Something about that disconnects us immediately from the server. Grave compass inside chest = EVIL.

Bild_2024-07-10_133624507

Bild_2024-07-10_134845788

commented

So it's from an item from a mod that uses Polymer, it seems to be related to server-only components.

CC: @Patbox, I need your input on this.

commented

Hmm, with Mojang's networking changes, it should convert correctly as long as it uses vanilla network itemstack codec and it uses vanilla packet payload system to write it.

commented

Ah, does Polymer also mixin into vanilla item codec?
Since item NBT/component sync is optional in WTHIT, I don't use it.

public static final StreamCodec<RegistryFriendlyByteBuf, ItemDataImpl> CODEC = StreamCodec.ofMember((d, buf) -> {
var syncNbt = d.config.getBoolean(CONFIG_SYNC_NBT);
buf.writeBoolean(syncNbt);
buf.writeVarInt(d.items.size());
for (var stack : d.items) {
if (stack.isEmpty()) {
buf.writeBoolean(true);
} else {
buf.writeBoolean(false);
buf.writeById(BuiltInRegistries.ITEM::getId, stack.getItem());
buf.writeVarInt(stack.getCount());
if (syncNbt) DataComponentPatch.STREAM_CODEC.encode(buf, stack.getComponentsPatch());
}
}
}, buf -> {
var d = new ItemDataImpl(null);
d.syncNbt = buf.readBoolean();
var size = buf.readVarInt();
d.ensureSpace(size);
for (var i = 0; i < size; i++) {
if (buf.readBoolean()) continue;
var item = buf.readById(BuiltInRegistries.ITEM::byId);
var count = buf.readVarInt();
var stack = new ItemStack(Objects.requireNonNull(item), count);
if (d.syncNbt) stack.applyComponents(DataComponentPatch.STREAM_CODEC.decode(buf));
d.add(stack);
}
return d;
});

commented

Cool, I'll also change that. Thanks.

commented

Looks like I missed a patch to DataComponentPatch.STREAM_CODEC / ComponentChanges.PACKET_CODEC. Will fix that on polymer side. Through you also should use PacketCodecs.registry(RegistryKeys.ITEM) (not sure yarn name) instead of [write/read]ById