Moonlight Lib

BEFORE CONTINUING:

Always check you are using the latest version of these mods and its dependencies
Remove known problematic rendering mods such as Optifine, Sodium and others

Version-Loader

1.21.1-NEOFORGE

Moonlight Lib Version

1.21-2.18.13-neoforge
1.21-2.18.18-neoforge (breaks with a different serializer)

Describe the Issue

With the latest Moonlight & Supplementaries, the Map Atlases mod sends a ByteArray of size 111 that exceeds the allowed 17 through a Velocity proxy, which then fails the connection when an atlas is in the hotbar (assuming that any inventory slot would do that too).
Earlier versions of the mods have worked without issues, so I must assume that any of the related mods have changed stuff around packets or networking that now in combination causes the issue. When the Map Atlas is disabled, maps work just fine otherwise.

/cc MehVahdJukaar/mapatlases-neoforge#220
/cc Gabwasnt/NeoVelocity#21

Log Attachment

See the client logs: https://mclo.gs/WMut3PY

OPTIONAL: To Produce

No response

OPTIONAL: Which mods are affected?

https://github.com/MehVahdJukaar/mapatlases-neoforge

Looks like the related version is https://modrinth.com/mod/moonlight/version/neoforge_1.21-2.17.34

Following up here with the information provided at MehVahdJukaar/mapatlases-neoforge#220 (comment)

The issue is confirmed with the

Moonlight/common/src/main/java/net/mehvahdjukaar/moonlight/api/map/MapDataRegistry.java

Lines 40 to 48 in 04887bd

    
           public static <P, T extends CustomMapData<?, P>> CustomMapData.Type<P, T> registerCustomMapSavedData(CustomMapData.Type<P, T> type) { 
        
               return MapDataInternal.registerCustomMapSavedData(type); 
        
           } 
        
           public static <P, T extends CustomMapData<?, P>> CustomMapData.Type<P, T> registerCustomMapSavedData( 
        
                   ResourceLocation id, Supplier<T> factory, 
        
                   StreamCodec<? super RegistryFriendlyByteBuf, P> patchCodec) { 
        
               return registerCustomMapSavedData(new CustomMapData.Type<>(id, factory, patchCodec)); 
        
           }

and

Moonlight/common/src/main/java/net/mehvahdjukaar/moonlight/api/misc/MapRegistry.java

Lines 129 to 131 in 7580563

    
           public int getId(T value) { 
        
               return this.tToId.getInt(value); 
        
           }

Where using static initializers, the order of the registered packets is not guaranteed between the server and the client, especially when they have different mods such as terrain generation mods on the server side, which would be one of the most common setups.

To solve the issue, an alternative approach should be used to avoid relying on the static registration order. Especially that it is one of the code smells in Java coding as they are widely unreliable.

are you using latest version here?

It was the latest at the time,

Will test again with the one released 21 hours ago.

not much i can do there. im registering that data serializer to the neoforge added registry on both server and client. the 2 should always match

Sorry for the delay. I just tested it on the server where the previous version was throwing a packet error, and now it appears to be fixed.

However, a new error:

client side: https://mclo.gs/keIFLco
server does not seem to say anything wrong

the custom build that Moulberry made works flawlessly

	public static <P, T extends CustomMapData<?, P>> CustomMapData.Type<P, T> registerCustomMapSavedData(CustomMapData.Type<P, T> type) {
	return MapDataInternal.registerCustomMapSavedData(type);
	}

	public static <P, T extends CustomMapData<?, P>> CustomMapData.Type<P, T> registerCustomMapSavedData(
	ResourceLocation id, Supplier<T> factory,
	StreamCodec<? super RegistryFriendlyByteBuf, P> patchCodec) {
	return registerCustomMapSavedData(new CustomMapData.Type<>(id, factory, patchCodec));
	}

	public int getId(T value) {
	return this.tToId.getInt(value);
	}

Share to