Closed fuyutsuki closed 3 years ago
There are quite some protocol changes that aren't packet-specific, and sometimes it's unclear which packets to bump protocol version for, and sometimes it's unclear which packets to constraint protocol to.
Yes, you are right. Maybe we should also keep the old directives for plugins that deal with packet-independent stuff, and implement this RFC in a new one. Think of this RFC as covering packet-dependent plugins.
Introduction
The current
mcpe-protocol
directive in theplugin.yml
disables the plugin when the protocol is updated. This RFC proposes to improve and make it more developer-friendly.Changes
The current spec uses only the protocol described in mcpe-protocol to determine whether to enable or disable, regardless of the packets used by the plugin, but this is not desirable because developers with low update frequency are rushed to support the latest version by Poggit and others.
So, I think it would be a good to disable the plugin only when the specific packet used by the plugin is updated by using the following structure for mcpe-protocol and writing the last updated protocol version of the packet.
Examples
plugin.yml
PacketVersion(temporary)
Result
If even one of the versions is less than the tested version of the packet, disable the plugin.
PacketVersion::{PACKET_NAME} >= mcpe-protocol.{PacketName}
=true
PacketVersion::{PACKET_NAME} < mcpe-protocol.{PacketName}
=false
BCBreak
With this change, mcpe-protocol will accept associative array values, but since the values it receives are originally protocol version integers. It can easily coexist with the old format using
is_array
and not cause a BCBreak. The old format should be removed in the future, but I don't think it needs to be now.Follow-up maintainer (...dktapps)
When updating packet, you need to update the packet version at the same time.
Reference