-
Notifications
You must be signed in to change notification settings - Fork 36
Migrating from Protocolize v1
Hello there,
you find yourself here because you have interest in migrating your existing plugin to Protocolize 2. Great news. In the following, I will show you which methods have changed.
You only need one maven dependency from now on. You can completely remove all other protocolize dependencies from your project. Just add:
<dependency>
<groupId>dev.simplix</groupId>
<artifactId>protocolize-api</artifactId>
<version>2.0.0</version>
<scope>provided</scope>
</dependency>The repository hasn't changed though.
The namespace was changed from de.exceptionflug.protocolize to dev.simplix.protocolize. This means you have to fix your imports in your project.
The naming scheme for accessors and mutators have been changed in favor of a more fluent looking api. All get and set prefixes for accessors and mutators have been removed and the methods are now returning this. Example:
// old
inventory.setTitle("Hello");
inventory.setItem(0, itemStack);
// new
inventory.title("Hello").item(0, itemStack);The ProtocolAPI class has been completely restructured and is now the central platform independent component registry of Protocolize. It's name has changed to Protocolize and offers access to the providers.
The PacketRegistration class has been changed in the favor of platform independence to an interface called ProtocolRegistrationProvider. The instance can be accessed using Protocolize#protocolRegistration.
The EventManager class has been changed in the favor of platform independence to an interface called PacketListenerProvider. The instance can be accessed using Protocolize#listenerProvider.
All traffic related features have been completely removed from Protocolize. There is no replacement for that.
Now I will go into detail about what has changed in packet listening.
The api for listening to packets has been reworked. There is no PacketAdapter<T> class anymore. Just use AbstractPacketListener<T> from now on.
The event classes have been completely rewritten to be platform independent. The player method (formerly getPlayer) is now returning an instance of ProtocolizePlayer. If you want to get the platform dependend player from it, just call ProtocolizePlayer#handle.
The server method (formerly getServer) is still returning the platform dependent ServerInfo but it's return type depends now on a generic S.
When manipulating received packets, calling markForRewrite is only necessary on BungeeCord. Though it is recommended to also call the method on Velocity for compatibility reasons.
The registration has been changed due to the ProtocolizeAPI changes:
// old
ProtocolAPI.getEventManager().registerListener(new MyListener());
//new
Protocolize.listenerProvider().registerListener(new MyListener());There are no static module classes anymore. Their functionality has been moved into the new ProtocolizePlayer class. Opening or closing inventories and playing sounds are now handled by that api. To get an instance of ProtocolizePlayer you have to access the ProtocolizePlayerProvider.
ProtocolizePlayer player = Protocolize.playerProvider().player(uniqueId);The ItemType enum constants have been renamed and will be named after the official latest minecraft item names.
The constant NO_DATA has been removed. To achieve the same result, set the item type of the ItemStack to null.
Due to the lack of an platform independent event api, there are no events anymore.
In order to listen to inventory clicks, you have to register a Consumer<InventoryClick> by using the Inventory#onClick method.
In order to listen to an inventory close, you have to register a Consumer<InventoryClose> by using the Inventory#onClose method.
This event has been completely removed. There is no simple replacement for that but you can register an AbstractPacketListener<OpenWindow> to listen for opened windows. You can obtain the Inventory instance by using the windowId:
Inventory inventory = event.player().registeredInventories().get(event.packet().windowId());You can register a Consumer<PlayerInteract> using ProtocolizePlayer#onInteract. This will register the interact consumer only for that specific player. If you wish to register interact consumers for all players, consider using something like this during enable:
Protocolize.playerProvider().onConstruct(player -> {
player.onInteract(interact -> {
// handle interact
});
});This will automatically execute your interact consumer registration when a ProtocolizePlayer has been constructed.
Protocolize v2 packets are beeing implemented platform independent. This means that one packet implementation is used on BungeeCord and Velocity. You can take a look at some Protocolize predefined packets.
In Protocolize v1, you could also directly extend BungeeCord's DefinedPacket class but in Protocolize v2, the AbstractPacket class is now mandatory to use for custom implemented packets. You can only register packets using the ProtocolRegistrationProvider that are extending AbstractPacket.
Protocolize v2 adapts the already existing Protocolize v1 item protocol mapping system for every protocol aspect. Packet mappings are now used to be a List<ProtocolIdMapping> and are ranged. Here is an example on how to create such a list for your custom implemented packet:
public final static List<ProtocolIdMapping> MAPPINGS = Arrays.asList(
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_8, MINECRAFT_1_8, 0x08),
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_9, MINECRAFT_1_11_2, 0x1C),
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_12, MINECRAFT_1_12_2, 0x1F),
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_13, MINECRAFT_1_13_2, 0x29),
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_14, MINECRAFT_1_15_2, 0x2C),
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_16, MINECRAFT_1_16_1, 0x2D),
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_16_2, MINECRAFT_1_17_1, 0x2E)
);Just static import dev.simplix.protocolize.api.util.ProtocolVersions.* so that you can directly use the protocol version constants.
Ranged mappings work in the way that they are valid for all protocol versions between the start version and the end version:
// id 0x1C for 1.9, 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.10.x, 1.11, 1.11.1, 1.11.2
AbstractProtocolMapping.rangedIdMapping(MINECRAFT_1_9, MINECRAFT_1_11_2, 0x1C)Custom packets are now beeing registered by the ProtocolRegistrationProvider:
Protocolize.protocolRegistration().registerPacket(WindowItems.MAPPINGS, Protocol.PLAY, PacketDirection.CLIENTBOUND, WindowItems.class);