When using Fabrication on the client and connecting to a server with custom sound events, the game freezes for a minute after which it will show it disconnected from the server:

Received ID map for minecraft:sound_event contains IDs unknown to the receiver!

This is an issue that FabricAPI used to have, but was fixed. Servers that register custom sound events are vanilla-friendly and vanilla clients will even process and handle these custom sound events, and play the appropriate sounds if the clients have the required resource packs.

The full logs are not very interesting, but included them anyway as a courtesy. Deleted server address from the logs as I tested it on a private server.

https://gist.github.com/Binero/772f6f14cff31e9271429ebebf676692

I reproduced the interesting part of the logs below:

[20:42:04] [Netty Epoll Client IO #1/INFO]: Logging in...
[20:42:04] [Render thread/ERROR]: Registry remapping failed!
net.fabricmc.fabric.impl.registry.sync.RemapException: Received ID map for minecraft:sound_event contains IDs unknown to the receiver!
 - server_namespace:music_disc.custom_disc_01
 - server_namespace:music_disc.custom_disc_02
 - server_namespace:music_disc.custom_disc_03
 - server_namespace:music_disc.custom_disc_04
 - server_namespace:music_disc.custom_disc_05
 - server_namespace:music_disc.custom_disc_06
 - server_namespace:music_disc.custom_disc_07
 - server_namespace:music_disc.custom_disc_08
 - server_namespace:music_disc.custom_disc_09
 - server_namespace:music_disc.custom_disc_10
 - server_namespace:music_disc.custom_disc_11
 - server_namespace:music_disc.custom_disc_12
 - server_namespace:music_disc.custom_disc_13
 - server_namespace:music_disc.custom_disc_14
 - server_namespace:music_disc.custom_disc_15
 - server_namespace:music_disc.custom_disc_16
 - server_namespace:music_disc.custom_disc_17
 - server_namespace:music_disc.custom_disc_18
 - server_namespace:music_disc.custom_disc_19
 - server_namespace:music_disc.custom_disc_20
	at net.minecraft.class_2370.remap(class_2370.java:704) ~[client-intermediary.jar:?]
	at net.fabricmc.fabric.impl.registry.sync.RegistrySyncManager.apply(RegistrySyncManager.java:314) ~[fabric-registry-sync-v0-0.9.17+23c4cfefa9-cb5b8f9d97efa7a7.jar:?]
	at net.fabricmc.fabric.impl.registry.sync.RegistrySyncManager.lambda$receivePacket$0(RegistrySyncManager.java:125) ~[fabric-registry-sync-v0-0.9.17+23c4cfefa9-cb5b8f9d97efa7a7.jar:?]
	at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) [?:?]
	at net.minecraft.class_1255.redirect$zho000$redirectExecuteTask(class_1255.java:521) [client-intermediary.jar:?]
	at net.minecraft.class_1255.method_16075(class_1255.java:131) [client-intermediary.jar:?]
	at net.minecraft.class_1255.method_5383(class_1255.java:116) [client-intermediary.jar:?]
	at net.minecraft.class_310.method_1523(class_310.java:1095) [client-intermediary.jar:?]
	at net.minecraft.class_310.method_1514(class_310.java:734) [client-intermediary.jar:?]
	at net.minecraft.client.main.Main.main(Main.java:237) [client-intermediary.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:461) [fabric-loader-0.14.8.jar:?]
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74) [fabric-loader-0.14.8.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) [fabric-loader-0.14.8.jar:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
	at org.multimc.impl.OneSixLauncher.invokeMain(OneSixLauncher.java:104) [NewLaunch.jar:?]
	at org.multimc.impl.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:175) [NewLaunch.jar:?]
	at org.multimc.impl.OneSixLauncher.launch(OneSixLauncher.java:185) [NewLaunch.jar:?]
	at org.multimc.EntryPoint.listen(EntryPoint.java:127) [NewLaunch.jar:?]
	at org.multimc.EntryPoint.main(EntryPoint.java:57) [NewLaunch.jar:?]
[20:42:04] [Downloader 0/INFO]: Encrypting...
[20:42:04] [Netty Epoll Client IO #1/INFO]: Joining world...
[20:42:33] [Netty Epoll Client IO #0/ERROR]: Registry remapping failed!

The sounds indeed work fine even when not registered.

Connect to a server with custom sound events.

figured as much but i don't know how to do that as i haven't ever done that.
do i just boot a server and do /playsound notanactuall:sound because i've tried that and it doesn't error

I feel like this is an issue with Fabric API Registry Sync, not Fabrication. All Fabrication does is register some client-only sounds; the inverse of you.

Technically, this shouldn't work at all... It should desync the client and server registries.

You need to actually register the sound event on the server. It would require a (dummy) server-side mod. The sound doesn't need to actually play for the error to occur, merely exist.

If this works in vanilla, that suggests vanilla is doing registry syncing of its own, and Fabric API Registry Sync shouldn't touch the sound event registry.

I am not convinced that is the entire story, since other mods that just add custom sounds have worked in the past, although I am having trouble finding any such mods for 1.19. That said I am unsure what is the full cause of it, but it is likely something silly.

I cannot stress enough though that this is completely fine and intended in vanilla.

I am not convinced that is the entire story

It is, check the code:

https://github.com/unascribed/Fabrication/blob/3.0/1.18/src/main/java/com/unascribed/fabrication/FabricationMod.java#L99-L109=

Literally the only thing here is Fabrication registering SoundEvents via its Forge/Fabric abstraction only on the client.

I did some further research and I get it now. The Custom Sound Effect packet sends the whole Identifier in the packet, not the registry ID. So in the vanilla case, the registry IDs are desynced, but it doesn't matter as the IDs are not used.

I suppose FAPI is expecting mods may rely on the IDs in the sound event registry. Hm.

I don't believe there's a way Fabrication can adequately fix this (other than simply not adding any custom sounds) — FAPI's registry syncing on sound events likely needs to be reconsidered.

Just checked it - not registering those sound events does fix the issue. I am curious how some of the other mods adding client-side sounds work around this, as well as interested if having Fabrication on the server would fix this issue.

No, as Fabrication will not register these sounds server-side. They're used solely by client-side code, and this worked fine in 1.16 and 1.17.

is there any downside to not registering the sounds.
iirc you don't have to register them to play them

i have no clue how fabrication would cause this and kinda doubt it does, please provide steps to reproduce

The steps to reproduce are:

1. Install Fabrication and Fabric API.
2. Connect to a server with custom sound events.

The game will disconnect with the error I summarised above.

net.fabricmc.fabric.impl.registry.sync.RemapException: Received ID map for minecraft:sound_event contains IDs unknown to the receiver!

I just booted up a game with just Fabric API and Fabrication, the following versions. The issue will persist with no other mods present.

  [✔️] fabric-api-0.57.0+1.19
  [✔️] fabrication-3.0-pre6+1.19

Removing Fabrication will cause the error to disappear.

I don't know much else about what causes it, other then:

• Some other mods (used to) produce the same error.
• Fabric API used to briefly produce the error, but this was swiftly fixed.