Для чего нужен protocolsupport
ProtocolSupport
Загрузка
Предыдущие версии
Название | Размер | Обновлено | Версия игры | Загрузок | |
ProtocolSupport v1.16.5-3 release | 12.89 MB | Jun 7, 2021 | 1.16 | 280 | |
ProtocolSupport v1.16.5-2 release | 12.82 MB | May 18, 2021 | 1.16 | 238 | |
ProtocolSupport v1.16.4-1 release | 12.68 MB | Nov 16, 2020 | 1.16 | 2,158 | |
ProtocolSupport v1.16.3-1 release | 12.28 MB | Sep 10, 2020 | 1.16 | 469 | |
ProtocolSupport v1.16.2-3 release | 12.28 MB | Sep 10, 2020 | 1.16 | 76 | |
ProtocolSupport v1.16.2-1 release | 12.27 MB | Aug 27, 2020 | 1.16 | 200 | |
ProtocolSupport v4.28 release | 5.30 MB | Oct 29, 2017 | 1.12 | 17,391 | |
ProtocolSupport v4.26 release | 5.53 MB | Jul 29, 2017 | 1.12 | 2,203 | |
ProtocolSupport v4.25 release | 4.08 MB | Feb 27, 2017 | 1.11 | 3,228 | |
ProtocolSupport v4.24 release | 801.19 KB | Aug 22, 2016 | 1.10 | 3,131 | |
ProtocolSupport v4.23 release | 737.70 KB | May 21, 2016 | 1.9 | 4,514 |
Описание
Добавляет 1.12.*, 1.11.*, 1.10.*, 1.9.*, 1.8.*, 1.7.*, 1.6.*, 1.5.*, 1.4.7 поддержка клиентов на вашем сервере spigot 1.12.2
Примечание:
Я поддерживаю только последнюю версию protocolsupport dev build. Кроме того, используйте github issues для публикации вопросов, я не читаю сообщения на форуме большую часть времени.
Уведомление об установке:
Если у вас возникли проблемы с внезапным отключением всех игроков и сервер перестает работать, установите use-native-transport в server.properties значение false
Уведомление об использовании:
Не пытайтесь не загружать/выгружать этот плагин динамично, он не будет работать.
И это никогда не сработает.
ProtocolSupport / ProtocolSupport Go PK Goto Github PK
Support 1.17, 1.16, 1.15, 1.14, 1.13, 1.12, 1.11, 1.10, 1.9, 1.8, 1.7, 1.6, 1.5, 1.4.7 clients on Spigot/Paper 1.17
License: GNU Affero General Public License v3.0
ProtocolSupport’s Introduction
Support 1.18, 1.17, 1.16, 1.15, 1.14, 1.13, 1.12, 1.11, 1.10, 1.9, 1.8, 1.7, 1.6, 1.5, 1.4.7 clients on Spigot/Paper 1.18
Known wontfix issues:
Licensed under the terms of GNU AGPLv3
ProtocolSupport’s People
Contributors
Stargazers
Watchers
Forkers
ProtocolSupport’s Issues
1.5.2/1.6.4 MOTD is Black
Using the default Minecraft Server MOTD.
[1.5.2/1.6.X/1.7.X] Can’t edit/write on different colored signs
If a 1.7.2 client tries to write a birch/spruce/jungle/acacia/dark oak sign, the edit sign GUI is never displayed, and the sign is automatically placed on the ground.
The oak sign is unaffected.
Client crash caused by scoreboard.
the client will crash everytime they join with 1.7.10
i’m using latest spigot and latest protocolsupport (Dev build)
Here is the log:
You spawn lower than normal in minecarts in 1.5.2
When you enter Minecarts in 1.5.2 you are sort of inside the minecart instead of above it.
This also applies to 1.5.1 and 1.5 (I’ve added support for those)
1.5 and 1.5.1 use the same protocol that 1.5.2 uses, the only thing that was changed is the protocol revision number so all that has to be done is add them to the ProtocolVersion.java and wherever else 1.5.2 is referenced add a 1.5.1 protocolversion
Mobile chat apps are not compatible with servers running protocolsupport
For some reason Minechat and other variants of mobile chat apps don’t work on servers with ProtocolSupport or ProtocolSupportBungee, it keeps saying «Pinging. » and fails to connect to the server.
1.5.2 /1.6.X Crash Some Location (like Dungun)
1.7.X and 1.8.X Version is fine. Here is the PS debug LOG
Bug with enchantments on 1.8.3
Compiled from source code with your last commit on March 8 to start Spigot 1.8.3 server. All working fine, BUT big bug is in enchantments. It reverts back to 1.7 version (without lapis and taking many levels) with every client. /ps list command can’t identify which version every player uses. I can’t understand one more thing: server on Linux-based machine with only ProtocolSupport plugin uses 1.7 enchantments, but when I download this server on Windows-based machine it works like a charm, with 1.8 enchantments.
I can provide access, logs, screenshots and other needed information and help to fix this issue.
P.S. Server uses BungeeCord proxy.
1.8.8 error on startup
[12:40:53 INFO]: [ProtocolSupport] Loading ProtocolSupport v4.19
[12:40:53 WARN]: java.lang.IllegalAccessException: Class protocolsupport.injector.NettyInjector can not access a member of class io.netty.bootstrap.ServerBootstrap$ServerBootstrapAcceptor with modifiers «private final»
[12:40:53 WARN]: at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
[12:40:53 WARN]: at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:296)
[12:40:53 WARN]: at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:288)
[12:40:53 WARN]: at java.lang.reflect.Field.set(Field.java:761)
[12:40:53 WARN]: at protocolsupport.injector.NettyInjector.inject(NettyInjector.java:22)
[12:40:53 WARN]: at protocolsupport.ProtocolSupport.onLoad(ProtocolSupport.java:18)
[12:40:53 WARN]: at org.bukkit.craftbukkit.v1_8_R3.CraftServer.loadPlugins(CraftServer.java:297)
[12:40:53 WARN]: at net.minecraft.server.v1_8_R3.DedicatedServer.init(DedicatedServer.java:203)
[12:40:53 WARN]: at net.minecraft.server.v1_8_R3.MinecraftServer.run(MinecraftServer.java:557)
[12:40:53 WARN]: at java.lang.Thread.run(Thread.java:745)
[1.5.2/1.6.x/1.7.x] Carpets glitch the player
Because carpets were added a slight «Step» in 1.8 the server knows that the client should go up a bit however in 1.7 and below the clients don’t know that and don’t go up resulting in the server glitching them a bit where the carpet is.
Skull Heads without Skin?
I don’t know if this is a known issue, but, when someone places a Player Skull Head with a skin, only the player who placed it will see the skin, the rest of the players will see a Steve Head.
But, if someone equips the Player Skull Head, the others players can see the skin on the equiped player, but the issue still persists on placed Player Skull Heads.
Server Version: 1.8.3-R0.1-SNAPSHOT (compiled yesterday)
Client Version: 1.7.2
1.5.2 Client Crash while ticking a Zombie
Happened when I died, as soon as I died it crashed, didn’t respawn.
[1.5.2/Maybe 1.6.4, didn’t test] Random Crash
I will try to find what block/entity is causing this crash.
Add support to spigot 1.8.3
It’s no work in spigot 1.8.3!
Dev. ProtocolSupport bug
When server works for a few hours server stops accepting new players. Server thread does work, and all connection that was before works too. I’m using latest spigot build.
Plugin list:
UralClans, HideStream, PVPGunPlus, WorldEdit, NoCheatPlus, Fixer, DynPad, JoinCommands, Vault, CPFix, ScoreboardStats, PermissionsEx, KillerMoney, GodItem, RainbowArmour, WorldGuard, Stop127, ProtocolSupport, boosCooldowns, SiberianChatFilter, MineResetLite, AntiSwear, AutoMessage, AuthMe, Marriage, ChestCommands, DrugsFTW, ClearLag, EndlessOnline, NoFlyPvp, TrophyHeads, WGExtender, Essentials, ChatManager, EssentialsSpawn, ShoppingCartReloaded, LimitedWorldEdit.
Almost all plugins are latest version. WG and WE is 6.x build.
Plugin improvements thoughts
Hello,
I noticed that for example ChunkUtils class is the same in both 1.6.4 and 1.5.2. Wouldn’t it be better to merge it into just one class? Not only for better future-proof, but for better general code management.
1.7 clients being allowed to see holograms.
Is it possible to allow 1.7 clients to see holograms? I know this was done with the protocol hack and with this plugin » https://www.spigotmc.org/resources/holographic-displays-patch.1039/ » the plugin currently does not work for 1.8.8. Are you able to add support for this?
Add a way to disable certain versions.
Could you add a config.yml where I can disable certain versions, I would like to disable 1.5.2 specifically because it is very buggy, but the rest are quite good.
1.5.2 and 1.6.X user opposite Time
what is mean. 1.7.X and 1.8.X User set time set morning. Then 1.5.2 and 1.6.X User see the night.
1.5.2 and 1.6.X User are opposite time to 1.7.X 1.8.X user (but No console Error)
i use 1.8.8 Spigot and 8/1 Protocolsupport Build
Please add support to glowstone server!
1.5.2 and 1.6.X Client kick some Server
Here is the PS debug log. I use lastest bungeecord and bukkit and Protocolsupport suite.
NoSuchMethodError
Am i the only one recieveing this error? Today’s spigot built 10h ago.
[21:15:55] [Server thread/INFO]: [ProtocolSupport] Loading ProtocolSupport v4.19 [21:15:55] [Server thread/WARN]: java.lang.NoSuchMethodError: net.minecraft.server.v1_8_R3.MinecraftServer.getServerConnection()Lnet/minecraft/server/v1_8_R3/ServerConnection; [21:15:55] [Server thread/WARN]: at protocolsupport.injector.NettyInjector.inject(NettyInjector.java:19) [21:15:55] [Server thread/WARN]: at protocolsupport.ProtocolSupport.onLoad(ProtocolSupport.java:16) [21:15:55] [Server thread/WARN]: at org.bukkit.craftbukkit.v1_8_R3.v1_8_R3.CraftServer.loadPlugins(CraftServer.java:296) [21:15:55] [Server thread/WARN]: at net.minecraft.server.v1_8_R3.v1_8_R3.DedicatedServer.init(DedicatedServer.java:198) [21:15:55] [Server thread/WARN]: at net.minecraft.server.v1_8_R3.v1_8_R3.MinecraftServer.run(MinecraftServer.java:524) [21:15:55] [Server thread/WARN]: at java.lang.Thread.run(Unknown Source) [21:15:55] [Server thread/INFO]: [ProtocolSupport] Enabling ProtocolSupport v4.19
[1.7/1.8] Problem with 1.7 clients animation
Feature: Change name of «replacement» blocks
When you give a 1.8.X block to a older version (1.7.2, etc), it gives you a stone, because the block don’t exist on the older version.
It would be good if those «stones» blocks had a different name at least (like, when you change a item name in an Anvil), because you can’t identify most 1.8 blocks in older versions because everything is «stone».
So, if someone gives you an Birch Fence, it would display an normal fence on a 1.7.X (or older) client, but it’s name will be «Birch Fence».
Of couse, this can’t apply to different item localizations, but is better than nothing 😄
Can’t Log in to server if don’t have hostname
im using #195 build.
most korea ip is don’t have hostname.
and it makes can’t connect to server
please fix Thanks!
it is error:
[21:27:11 INFO]: /119.149.12.244:55302 lost connection: Internal Exception: java.lang.NoSuchFieldError: hostname
[21:27:11 INFO]: /127.0.0.1:50982 lost connection: Internal Exception: java.lang.NoSuchFieldError: hostname
[21:27:11 INFO]: /127.0.0.1:50983 lost connection: Internal Exception: java.lang.NoSuchFieldError: hostname
[21:27:11 INFO]: /39.127.241.166:50985 lost connection: Internal Exception: java.lang.NoSuchFieldError: hostname
and its debug mode log:
[23:18:56 INFO]: Enabled debug
[23:19:10 WARN]: java.lang.NoSuchFieldError: hostname
[23:19:10 WARN]: at protocolsupport.protocol.transformer.AbstractHandshakeListener.a(AbstractHandshakeListener.java:81)
[23:19:10 WARN]: at net.minecraft.server.v1_8_R3.PacketHandshakingInSetProtocol.a(PacketHandshakingInSetProtocol.java:29)
[23:19:10 WARN]: at net.minecraft.server.v1_8_R3.PacketHandshakingInSetProtocol.a(PacketHandshakingInSetProtocol.java:1)
[23:19:10 WARN]: at net.minecraft.server.v1_8_R3.NetworkManager.a(NetworkManager.java:124)
[23:19:10 WARN]: at net.minecraft.server.v1_8_R3.NetworkManager.channelRead0(NetworkManager.java:325)
[23:19:10 WARN]: at net.minecraft.server.v1_8_R3.NetworkManager.channelRead0(NetworkManager.java:1)
[23:19:10 WARN]: at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
[23:19:10 WARN]: at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
[23:19:10 WARN]: at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:163)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
[23:19:10 WARN]: at com.comphenix.protocol.compat.netty.independent.NettyChannelInjector$4.channelRead(NettyChannelInjector.java:280)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
[23:19:10 WARN]: at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:163)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
[23:19:10 WARN]: at protocolsupport.protocol.core.initial.InitialPacketDecoder.setProtocol(InitialPacketDecoder.java:108)
[23:19:10 WARN]: at protocolsupport.protocol.core.initial.InitialPacketDecoder.channelRead(InitialPacketDecoder.java:90)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
[23:19:10 WARN]: at io.netty.handler.timeout.ReadTimeoutHandler.channelRead(ReadTimeoutHandler.java:150)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
[23:19:10 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)
[23:19:10 WARN]: at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[23:19:10 WARN]: at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:130)
[23:19:10 WARN]: at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
[23:19:10 WARN]: at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
[23:19:10 WARN]: at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
[23:19:10 WARN]: at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
[23:19:10 WARN]: at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[23:19:10 WARN]: at java.lang.Thread.run(Unknown Source)
[23:19:11 INFO]: /127.0.0.1:51559 lost connection: Internal Exception: java.lang.NoSuchFieldError: hostname
Shutdown bukkit on errors?
Maybe juat try to disable your plugin and send a huge error message to console and ingame chat.
Cannot see HolographicDisplays with 1.7.* client
Cannot see HolographicDisplays with 1.7.* client
Spigot: 1.8.3
Character now leaves a bed but he isn’t standing and GUI doesn’t close.
The change that fixed sneaking and running in 1.5.2 improved beds, in a way that you now leave the bed and teleport 1 block away but you aren’t standing so you fall to the ground and the bed GUI doesn’t close.
Construction #9 (22 déc. 2014 16:54:15)
1.5.2 Client Connection Problem to Bungee Connected Server
I user Lastest Bungeecord and ProtocolsupportBungee And ProtocolSupport And Today Spigot Build.
1.7.X and 1.8.X Clinet is all Fine. but 1.5.2 client have problem to connect bungee connected Server.
1.5.2 client connect to lobby server is fine. but if 1.5.2 client try to connect bungee connected server crash
Internal exception: Java.io.IOException: Bad compressed data format
I Think lasteset bungeecord use Compress system. i use ps debug. but bukkit is not any log. and bungeecord have too many ps debug log. sorry to i cant catch any log
Play Server When Crash Sunddenly 1.5.2 Client User
Hello. I found Another Issue. 1.5.2 Client User play normaly. But Sunddenly Player Crash and kick the Server. Here is the Debug Log. (Player Get message to End of Stream)
Server Use Spigot 1.8.8 and Use Protocolsupport 8/1 Build Version
[00:07:56 WARN]: io.netty.handler.codec.DecoderException: NettyChannelInjector.d
ecode() did not read anything but decoded a message.
[00:07:56 WARN]: at io.netty.handler.codec.ByteToMessageDecoder.callDecod
e(ByteToMessageDecoder.java:268)
[00:07:56 WARN]: at io.netty.handler.codec.ByteToMessageDecoder.channelRe
ad(ByteToMessageDecoder.java:149)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invoke
ChannelRead(AbstractChannelHandlerContext.java:333)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireCh
annelRead(AbstractChannelHandlerContext.java:319)
[00:07:56 WARN]: at com.comphenix.protocol.compat.netty.independent.Netty
ChannelInjector$4.channelRead(NettyChannelInjector.java:280)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invoke
ChannelRead(AbstractChannelHandlerContext.java:333)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireCh
annelRead(AbstractChannelHandlerContext.java:319)
[00:07:56 WARN]: at io.netty.handler.codec.ByteToMessageDecoder.channelRe
ad(ByteToMessageDecoder.java:163)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invoke
ChannelRead(AbstractChannelHandlerContext.java:333)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireCh
annelRead(AbstractChannelHandlerContext.java:319)
[00:07:56 WARN]: at io.netty.handler.timeout.ReadTimeoutHandler.channelRe
ad(ReadTimeoutHandler.java:150)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.invoke
ChannelRead(AbstractChannelHandlerContext.java:333)
[00:07:56 WARN]: at io.netty.channel.AbstractChannelHandlerContext.fireCh
annelRead(AbstractChannelHandlerContext.java:319)
[00:07:56 WARN]: at io.netty.channel.DefaultChannelPipeline.fireChannelRe
ad(DefaultChannelPipeline.java:787)
[00:07:56 WARN]: at io.netty.channel.nio.AbstractNioByteChannel$NioByteUn
safe.read(AbstractNioByteChannel.java:130)
[00:07:56 WARN]: at io.netty.channel.nio.NioEventLoop.processSelectedKey(
NioEventLoop.java:511)
[00:07:56 WARN]: at io.netty.channel.nio.NioEventLoop.processSelectedKeys
Optimized(NioEventLoop.java:468)
[00:07:56 WARN]: at io.netty.channel.nio.NioEventLoop.processSelectedKeys
(NioEventLoop.java:382)
[00:07:56 WARN]: at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.ja
va:354)
[00:07:56 WARN]: at io.netty.util.concurrent.SingleThreadEventExecutor$2.
run(SingleThreadEventExecutor.java:116)
[00:07:56 WARN]: at java.lang.Thread.run(Unknown Source)
[00:07:56 INFO]: Song_gi lost connection: Internal Exception: io.netty.handler.c
odec.DecoderException: NettyChannelInjector.decode() did not read anything but d
ecoded a message.
And How can i Donation to you? always Thanks to you to develop this plugins
1.7.X Version client cant use Uskyblock Server
Hello i m using Uskyblock v2.3-HF7i version. i use Protocolsupport #178 build is all is ok. But i update to #184 build. 1.7.X client user try to go island. they are crash. here is the PS debug log
ah, and i use ProtocolsupportBungee Too. BungeeServer and Spigot Server all Lastest Build (spigot 1.8.8)
sorry for my bad english
1.5.2, 1.7.X Client have problem
1.5.2 crash ranbomly and 1.7.X User go some location they are kick to server a java error masage. I dont know This is Spigot Bug or Protocolsupport bug. But 1.8 higher Client is all ok.
Im enable PS debug. But console only show client java error masage. How do you think about this errors.
This issue is, I update to spigot 1.8.8 and 8/2 protocolsupport
[1.5.2/1.6.4] When viewing a map item, the client crashes.
If you view a map in a 1.5.2 client, the client will crash.
The crash will also happen if you pick up a map and view it.
Old Versions For the risk-takers among us
Are you attempting to support 1.7 (and up) players on an older server? ProtocolSupport’s old versions are unsupported, and the build for 1.8.8 in particular has quite a few problems. However, a great alternative approach would be to use a setup involving two (three if you’re on 1.10.x) other plugins.
All of these plugins are required for this approach, but this is an entirely supported setup, and bugs are likely to be fixed for all of these plugins. If, however, you really want to stick with ProtocolSupport, you can find the old builds below.
This page contains old, unsupported versions of ProtocolSupport.
If you really need them, you can download them here. However, in doing so, you are agreeing that:
- You will receive no support if you decide to use these builds. Any problems you find in these builds will not be fixed. Any issues you report for these builds will be closed. Requesting support on Discord for these builds will result in a mute or kick.
If you decide to update to the current build of ProtocolSupport, we will once again provide you with support.
Additionally, we request that you do not share these builds with anyone directly. If you’d like to link these builds to another user, then feel free to link to this page instead. Do not rehost these builds.
Please answer the following questions to gain access to the downloads