Fabwork 1.3.0 for Minecraft 1.20.5 - 1.21

Changelog

• Updated to 1.20.5, 1.20.6, and 1.21
• Removed deprecated API (ServerConnectionEvents and ClientConnectionEvents)

Breaking Changes

• PacketType#id has been changed to a CustomPayload.Id<Payload<T>> field rather than an Identifier
• PacketType#constructor has been replaced with a PacketCodec<PacketByteBuf, Payload<T>>
• Creating and registering packets are unchanged. The new version can be used as a drop-in replacement for the old.

Fabwork 1.2.0 for Minecraft 1.20.2 - 1.20.4

Changelog

• Updated to 1.20.2
• Fabwork will now do its verification in the configuration stage before a player enters the world
• The sender generic type for HandledPacket no longer has to extend PlayerEntity
• Removed the unneccessary generic type from Packet
• Deprecated ServerConnectionEvents (use Fabric API's own ServerConfigurationEvents instead)

Fabwork 1.2.0 for Minecraft 1.20.X

Changelog

• Updated to 1.20-pre6

Fabwork 1.1.9 for Minecraft 1.19.X

• Compatible with 1.19.2, 1.19.3, 1.19.4

• Mod resolution is now more reliable and should lead to fewer disconnects due to server or client not receiving notice in time:

  • Fixed the order of events so the server has a chance to send mod lists to the client before either side attempts to verify
  • The client is more forgiving for slower connection. It will attempt to verify the mod list sent by the server up to 5 times with a wait of 300ms between each check, so even in the event of the first fix not working, the second should ensure a reliable experience, albeit with a slight delay.

• Relating to this, Fabwork has introduced its own networking events (currently not part of the api):

  • ClientConnectionEvents.CONNECT (fired after fabric's regular JOIN event)
  • ServerConnectionEvents.CONNECT (fired after fabric's regular JOIN event but before the client's corresponding JOIN event)

  The reason for adding these events are because the existing events provided by Fabric do not occur in the expected order which makes them unsuitable for mods like Fabwork that require messages to be transmitted in a specific order to work.

  The normal order of events as they are exist like this:

  Fabric:Client:INIT -> Fabric:Server:INIT -> Fabric:Server:JOIN -> Fabric:Client:JOIN

  With Fabwork's events, the flow is extended with an additional phase:

  Fabric:Client:INIT -> Fabric:Server:INIT -> Fabric:Server:JOIN -> Fabric:Client:JOIN -> Fabwork:Client:CONNECT -> Fabwork:Server:CONNECT

  Because these events are reliant on a packet being received by the client, which is true of both Fabric and Fabwork, what's important here is that the event is fired after the corresponding notice has been sent off to the client. So even if the network introduces delays, any packets sent during the Fabwork:Server:CONNECT event can at least be guaranteed to arrive on the client after it has received the Fabwork:Client:CONNECT event.

Fabwork 1.1.8 for Minecraft 1.19.X

• Fixed server error when specifying invalid/null mod ids via the config

Fabwork 1.1.7 for Minecraft 1.19.X

Changelog

• Fixed config not being generated at startup
• Fixed server-side error due to mods without ids (modContainer.getMetadata().getId() == null)
• Added exception handling around all network/login based events
• Added a config setting to disable login protocol checks and to log instead of rejecting players who attempt to join with mistmatched mods.

Fabwork 1.1.1 for Minecraft 1.19.X

Initial release

Build 1.1.0

Change these logs back to debug level statements since we don't need …

…to them any more