With the latest Moonlight & Map Atlases, the connection through a Velocity proxy fails when an atlas is in the hotbar (assuming that any inventory slot would do that too).
See the client logs: https://mclo.gs/WMut3PY

UPDATE:
I can now confirm that the issue happens even without Velocity, even without the Connector involved:

• Server Logs: https://mclo.gs/AA9u5Q7
• Client logs: https://mclo.gs/RzhOc6y
• Client crash with Sinytra: https://mclo.gs/4Kro4Sb
• Client crash without Sinytra: https://mclo.gs/LpvGfCW

I tested with nearly identical servers, within the same region and on the same map, but one server works, while the other crashes.
The difference between them is survival vs creative mode, and worldedit.

I can now confirm that the issue happens even without Velocity, even without the Connector involved:

• Server Logs: https://mclo.gs/AA9u5Q7
• Client logs: https://mclo.gs/RzhOc6y
• Client crash with Sinytra: https://mclo.gs/4Kro4Sb
• Client crash without Sinytra: https://mclo.gs/LpvGfCW

I tested with nearly identical servers, within the same region and on the same map, but one server works, while the other crashes.
The difference between them is survival vs creative mode, and worldedit.

Hello,

Posting on behalf of adaliszk.

This is an issue with Supplementaries and MoonlightLib.
MoonlightLib has a system where custom data needs to be registered using registerCustomMapSavedData, which uses Moonlight's MapRegistry.
MapRegistry's StreamCodec uses getId/byId for serializing the ids.
The problem is that the IDs now depend on the registration order of the calls to registerCustomMapSavedData.
I added debug logging to a custom build of Moonlight to see the registration order.

Server logs:
[03:44:18] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:depth_lock
[03:44:18] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:antique
[03:44:18] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:color_data
[03:44:18] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:light_data

Client logs:
[03Jun2025 03:51:10.407] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:light_data
[03Jun2025 03:51:11.432] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:depth_lock
[03Jun2025 03:51:11.445] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:antique
[03Jun2025 03:51:11.462] [modloading-worker-0/INFO] [STDOUT/]: [net.mehvahdjukaar.moonlight.core.map.MapDataInternal:registerCustomMapSavedData:38]: Registering custom map codec: supplementaries:color_data

As you can see, the server registration happens in the order depth_lock, antique, color_data, light_data while the order on the client is light_data, depth_lock, antique, color_data. So when the server tries to send one of the custom datas to the client, it will fail and it will cause the Failed to decode packet error.

The order is different because Supplementaries relies on static initialization to call registerCustomMapSavedData. On the client, the MapLightHandler class gets loaded early, causing the light_data to be registered first instead of last.

The two solutions I see are to either:

1. Rewrite registerCustomMapSavedData to not depend on the order in which it's called.
2. Make the MapRegistry StreamCodec use resourcelocation instead of ids to serialize the type.

Best Regards,
Moulberry

velocity isnt for modded, its for vanilla. report there if you think it shouldnt be

I reported it here because previous version of Moonlight and Supplementeries worked without any issues, it got broken with the latest few versions as we upgraded the pack

Plus those work even now, only the atlas that breaks

doesnt really matter. new stuff gets added,new content all the times. Velocity isnt for modded, we modders have had many issues with it in thepast

Because previous update for 1.21 was broken due to packet changes. The requited stuff to make it work properly like in 1.20 was only added later.

Which part of the setup is that? Neoforge (was unchanged), Velocity (was unchanged), the Moonlight, Supplementaries, or Map Atlas?

FYI: I added a 30€ bounty on this on https://gitpay.me/#/profile/task/1177. However, if you prefer another platform, I'm happy to move it there.

I see, so you won't look into any potential fixes where the latest versions of Moonlight, Supplementaries, and Atlasses together create a packet with a ByteArray of size 111 that exceeds the allowed 17. Not even try to upgrade to the latest versions of Moonlight, where they have been working on the networking stack out of spite?

In my experience, Velocity works perfectly fine with modded Minecraft for mods that do not mixin packets wrongly or otherwise declare their packets correctly.
Also, I should note that the combination of the mods was working perfectly fine for months, but it broke with an update of the dependencies and related mods.

There aren't. Velocity is meant for vanilla and uses vanilla packets. Any mod that alters vanilla packets will have such issues and that's critical for that atlas to work. Report there but I doubt they will do anything as as I've said that mod isn't meant for modded and has given us countless issues in the past

And needless to say that the packet stuff works perfectly on proper servers that have the mod. Client sends a bigger packet, server is ready to accept it. Velocity has passes it to a vanilla connection and that crashes. Map atlas is a server client mod and is needed on both sides

I am confused here. How can it be that a perfectly fine setup breaks after mod updates, and somehow that is the fault of the setup?
Yes, velocity will ensure that you do not send bad packets, but the packets you and your dependencies declare.

From what I gathered from the changelogs, two main things I know have happened compared to earlier versions of the related mods:

• Map Atlases expanded their maximum allowed maps within the Atlas itself (probably unrelated, as I am opening an empty atlas in creative)
• Moonlight, the underlying library, has been working on improving the network stack

I have the two versions of the modpack here for repro:

Modpack-0.7.2.zip
Modpack-0.9.1.zip

The 0.7.2 worked fine, and 0.9.1 breaks on the same version of Neoforge+Velocity.
There are a lot of changes between those two. My guess for Atlases here is purely because when removed, everything else works.

The updated map packet that is in moonlight lib and was only fixed properly at a later date

Which version of Moonlight should I revert to that does not have the updated map packet?

Not sure. If you do however the atlas won't work. All maps will be placed at 0.0 as the server won't be sending over the position data. Thecusotm map markers wont work either, same for the colored map data

So even if I revert Map Atlas too, that means we still won't be able to use it? The issue then by you as the expert here is in Moonlight, right?

It might load but the atlas will for sure have many bugs at best or not work at all in worst as all maps will be placed all in top of eachother as client has no idea what their coordinates are as server won't send them

Just a quick update:

I received confirmation from the Leadership Team at the PaperMC server that Velocity does nothing with the packets. They are as big or small as any mods or plugins use; they do not alter them in any way, they are only routing them. However, some plugins may modify the packets; in my case, the only one related to packets is designed explicitly for signing them, though it allows modifications by other plugins if I had any.

With my local version of the entire setup, I have no issues, so I am currently debugging the differences beyond the actual location of the machine and the use of containerd instead of dockerd. I will roll out a version to the servers without signing to verify that part, but other than that, I am unsure what could cause it.

Quick question though: Do you know which particular property is that that could throw the ByteArray size limit, and if it's not the actual modified vanilla map packet, then when was it as low as 17?

That's not true. It allows for modded clients to talk with non modded ones. That's why it complains here because it's talking to a server that is seemingly without the mod so when the client get the vanilla in modifed packet it doesn't know what to do. The mod need the modified map data to work and doing it like that is the most compatible way to do stuff

What are the conditions that do enable https://github.com/MehVahdJukaar/Supplementaries/blob/681f328385f40fe4e93f239dba80d17a4d5ba703/common/src/main/java/net/mehvahdjukaar/supplementaries/common/misc/MapLightHandler.java ?

configs. doesnt matter tho, the entirety of map atlas relies on having map info that are sent by thatpacket on the client.
If you were to get a version without the packet modification nothng will work as expected there.
Moreover i could technically make it so it doesnt crash when it receives a vanilla packet but that wontsolve any of the issues. as it stands velocity doesnt work with any kind of packet modification. That's where this ends really, as ive said before such hybrid servers are generally not supported by the modding community for these very reasons, rare inconsistent interactions that make stuff misbehave like this. You can bring this up to them but i doubt the would do anything, or if anything could even be done

Well, it crashes on the client side when that MapLightHandler tries to decode a ByteArray with the wrong size, so I am not entirely sure that your hostility towards Velocity is all that justified when the intended "supports vanilla packets" compatibility does not work. Perhaps with a bit more open-minded approach, you may find something that needs to be considered in future updates:

I went through the entire call stack, disabled mods that were mentioned one by one, and eventually identified the culprit: the Forgified Fabric API. They can load before or after the regular NeoForge mixing resolution, and depending on the order, it can reapply the vanilla packet format on the map data.

Now, sadly, a few developers have started to include the FAPI libraries in their JAR files, mods like Sodium, and many connected tools created by Txni. This is especially problematic, as they contain a different version of FAPI, which causes them to reapply the same mixins multiple times at various points in the loading sequence or straight create packets intended for a previous version.

So after going through all the mods and back, I found that OwO library overwrites the otherwise fine FAPI and breaks your custom packet, so with that, Accessories, Accessories' Curios Compatibility, and Tony's Immersive Lanterns needed to be removed to make it work with Map Atlases.

Luckily, Sodium, TxniLib, and MaFgLib embed FAPI libraries, but they do not do anything with the Networking API, so your packet is safe from them at least.

In the end, the error has nothing to do with Velocity.
Could you be a bit more open-minded next time?

Generally it's advised to steer clear of hybrid stuff such as fabric on forge or plugins/vanilla on forge. A pure forge server is what mods are built upon

The hostility is because I've gotten many of these super weird reports over the years over hybrid server usages. Sometime very hard to track down and most of the time there isn't much anybody can do as those servers will always be considered a hack when used in the modded context. Also to some extent this also applies to connector as it's a hybrid thing itself but they do have a huge warning in the log to say to report all issues to them

Fundamentally, Velocity is a Proxy; it does nothing with the packets but routes them out of the box. It can modify them with specific plugins, but when someone uses those, they are usually aware of that.

Yes, Sinytra would be similar in the sense that it can unexpectedly break stuff, but there isn't much you can do to avoid it. It is already embedded in Sodium; whether that is a good or bad thing does not matter; it exists, and too many people rely on it.

Honestly, in this case, OwO is engaging in a redistribution that is not okay; however, I was able to determine this by reviewing the logs after becoming frustrated with the situation.

Anyhow, to properly close this, I think there are a few options:

• Marking OwO as an incompatible mod
• Avoid using the ByteArray or catch it and provide a default behaviour
• Creating a custom map item to replace the mixin

Quick update, when I added Connector+FAPI to the server side, the issue also happens, so this mod single-handedly blocks Fabric mods from being used on the server side. Cool found from Moulberry (Axiom/Flashback): https://github.com/Sinytra/Connector/blob/bb80f89fe7a51e7ad3a61e769881b6e61a541db4/src/mod/java/org/sinytra/connector/mod/mixin/network/StreamCodecMixin.java#L9-L21

If I understand correctly, then another option is to implement the buffer encoding and decoding to support FAPI.

The id mismatch was an issue that was fixed. The message stuff is still that server client mismatch since clients doesn't know its receiving a vanilla unmodified message so it crashes or vice versa

Hello. I would like to work on this issue. Is it still needed?

The issue remains in the StreamCodec on the MehVahdJukaar/Moonlight#341 side. While the actual map error no longer occurs with the latest Moonlight, it still fails to serialize correctly and thus breaks with other data.