ProtocolLib

3M Downloads

Weapons deal no damage

yeatt opened this issue ยท 19 comments

commented

Using latest version of ProtocolLib, and players are unable to deal any damage to each other due to the fact weapons deal no damage. Almost as if I'm punching someone when I'm hitting them with a Netherite Sword.

commented

Same thing here

commented

I can't reproduce this issue (1.19.2 server)

commented

You're on the latest dev version of ProtocolLib?

commented

Same here, same as issue #1841

commented

Damm i have the same problem

does someone knows how to fix that problem i wanted to make release on my server but i can't bc of that bug

commented

Our server is affected too, crits don't work and damage is reduced or nonexistent depending on the user.

commented

we are having the same problem in the last version and still having this problem, enchantments like sharpening 10 do not cause the damage it seems to be without enchantment.

version: ProtocolLib#597
paper: 1.19.2 last version,

commented

I have tried the oldest version that I was able to download from "https://ci.dmulloy2.net/" but no version that is there fixes this error.

commented

I have the same problem, crits, sweeping edge, and 0 damage.

commented

I would like to mention, that quite a few people did report this issue to us on the DecentHolograms discord.

Some small facts:

  • DH dev said to me that ProtocolLib is only used for packet listening. And it's only used because ProtocolLib apparently doesn't like separate packet listeners being used alongside it.
  • Quite a few users also use Purpur, which made us first believe it could be a patch on that end causing the issue, but some tested it on PaperMC, so it doesn't seem to be the case.
  • All users use some version of 1.19, including 1.19.2, so if ProtocolLib is causing this (Which looking at this seems quite likely) must it be with the v5 dev builds required for 1.19.x

We hope these issues can be fixed. If dmulloy believes that in this case DecentHolograms is at fault, should they contact us, so that a fix can be found...

commented

This issue is caused by a change that all packet listeners are now called by default on the main server thread. Plugins which are listening to these packets (especially USE_ENTITY which is causing the problem) should specify the ASYNC option for now. This issue is caused by a small delay of 1 Tick until the packet is processed by the server when the packet is synced to the main server thread.

I was thinking about a fix which would require inbound listeners to specify a sync option in order to get called async, working on it and will possibly be available the next few days :)

commented

For devs wondering how you can mark listeners async in the best way, use this snippet:

new PacketAdapter(PacketAdapter.params(plugin, PacketType.Play.Client.KEEP_ALIVE).optionAsync())
commented

This issue is caused by a change that all packet listeners are now called by default on the main server thread. Plugins which are listening to these packets (especially USE_ENTITY which is causing the problem) should specify the ASYNC option for now. This issue is caused by a small delay of 1 Tick until the packet is processed by the server when the packet is synced to the main server thread.

I was thinking about a fix which would require inbound listeners to specify a sync option in order to get called async, working on it and will possibly be available the next few days :)

What build of ProtocolLib should I use to not have this change?

commented
commented

Yep also having the same problem. On Paper 1.19.2. Players are doing no damage all of them are complaining.

commented
commented

Latest development build changes back to the old behaviour by default (calling them on the event loop), calling AdapterParams#optionSync will cause the inbound listener to get called synced again (if needed by anyone).

Download: https://ci.dmulloy2.net/job/ProtocolLib/lastSuccessfulBuild/

commented

Latest development build changes back to the old behaviour by default (calling them on the event loop), calling AdapterParams#optionSync will cause the inbound listener to get called synced again (if needed by anyone).

Download: https://ci.dmulloy2.net/job/ProtocolLib/lastSuccessfulBuild/

So this issue is fixed with the build 598 and onward?

commented

I can confirm this is fixed on the latest development build 598.