This is with OpenModsLib-1.7.10-0.6-snapshot-218.

Only occurs on Cauldron(MCPC) and not Forge server so this is FYI.
MinecraftPortCentral/Cauldron#1524

https://github.com/OpenMods/OpenModsLib/blob/master/src/main/java/openmods/network/IdSyncManager.java

His IdSyncManager breaks our plugin registration. I'm working on a fix.

Can you explain, how exactly are you modifying connection startup? I can add check for existing handler, but I would like to know why CustomPacketRegistrationEvent is sent more than nce per channel.

@boq

CustomPacketRegistrationEvent is only fired once on our end through FML's fireNetRegistrationEvent.

[03:30:16] [Netty IO #2/INFO]: fireNetRegistrationEvent for channelSet [FML|HS, FML, OpenMods|E, OpenMods|M, FORGE, TConstruct, OpenMods|RPC, OpenMods|I, MoCreatures], channel REGISTER

Only a single entry is shown in my test

As for the conflict between Cauldron and OpenMods, the following line causes the issue

https://github.com/MinecraftPortCentral/Cauldron/blob/master/src/main/java/org/bukkit/craftbukkit/entity/CraftPlayer.java#L1093

This seems to cause the client to register your handler.

If event is fired once, then why this method is called at least two times? And you send second REGISTER packet that IIRC (can't check in code right now) causes that event?

Proper solution is probably to add explicit check for registered channels.

Why are you listening to FML's channel?

We have framework for synchronization of ids. They are assigned at startup and all lib OpenModsLib users have common pool, so it's probably impossible to synchronize without some kind of information send on connection.

Problem is, I want this message to be sent and received before any other mod messages for world are possibly sent or processed. Since NetworkManager.processReceivedPackets is called after world ticks on both client and server, I decided to tap into pipeline much earlier.

I'm not happy with this solution, since it's little bit convoluted. I have to hijack player channel and partially parse FML|HS messages (so I can send message after FMLHandshakeMessage.ModIdData, which is probably safest place to do that).

Please notice, that current builds of OB and OM are early alphas, so I'm still experimenting with available solutions and not really sure which one I will use. I was considering other approaches, including possible FML PRs (priority channels - FMLProxyPacket.hasPriority() == true for selected channels, exposing NetworkDispatcher.handshakeChannel) but they all had issues. So this may be considered hack until I can figure if there is better, more reliable solution.

@boq Thanks for fix. Build 223 works fine.

A proper way to do this would to make {or use if it exists} a event that is fired after FML's registration handshakes are done, but before it continues with the vanilla connection.
I can see the use for sending synchronizing data.
However you guys have your own full netty channel and should be sufficient to do it.
TCP preserves order of packets being sent so there should be no need for a priority system of any kind, just send your stuff before the world data.

Thanks for the fix. Can confirm working.

@LexManos Yes, sending could be done by adding event before last handshake message is sent. Problem is on receiving side, where world can tick (and send messages with local data instead of remote) before synchronization message is processed. We could add busy loop with network ticks, but I have no idea what will happen if packets are processed before world.

This should be closed some time ago. Also, whole synchronization should now be more robust, due to OpenMods/OpenBlocks#498 (we are doing it now same way as ForgeMessage.FluidIdMapMessage)