Some of the changes this plugin allows for generates FP's with Spartan. I don't know if you can add support for it but I thought I would ask. This biggest noticable false positive it generates is from your regen system. Everything else seems to have minimal FP's.

I did also put a request in to Spartan dev to support this plugin or account for it, but it can't hurt to ask here too since it can be done on either side. I would appreciate it!

Thanks :)

I don't really know how much we can do to fix this false positive with Spartan anti-cheat, seeing as it is a closed-source project so there is no way for us to determine how Spartan detects false positives for player regen. However, if you happen to know of some place that documents how Spartan detects "cheats" like that, it might be possible to find a way to avoid those false positives.

I'd test it and figure it out myself, but Spartan is over $20 USD :p

The correct way seems to be API.cancelCheck(player, HackType.FastHeal, 5);
Note that this might make the FastHeal check completely useless, as it disables it for a 5 ticks after getting hit.

So yea, one could probably add an optional soft-depend on Spartan and hide these checks behind a guard to make it compatible and not crash on servers without it.

If somebody could tell me where the documentation and javadoc is hiding I would be thankful. I can't believe anybody would expect others to include compatiblity methods they have to essentially piece together from the compiled code or other unrelated plugins.

I was looking at the API methods on spartan too and it seems that might be the way. When regen packets are sent, cancel the check for that tick. Not sure why you'd set it to 5 ticks after, but that seems to be the right method. The API is downloadable from spartan main page and is sort of documented on it too.

Spartan dev said:

My plugin provides a developer API. They can download the api file and add compatibility. The link and documentation can be found in the overview page.

I saw that page, but there is literally no documentation besides an API jar blob without any javadoc. So you guesstimate your way through based on parameter and method names, as well as the other plugins linked.

If that really is all (s)he offers that sounds a bit sad. It's their project though.

Well, if you can guarantee that his check will fire in the next tick (documentation?), using one tick is fine too. I just prayed that 5 are enough in that answer, the plugin I looked at actually used 20(!). Though that may be due to the kind of plugin it was (some enchantment thingy).

The issue that I can't test things still remains though. I am not sure what you mean with "regen packet", the plugin just uses the plain bukkit API (it literally calls "setHealth"). If it sent packets it would cause a client-server desync here, which you do not want. However I don't know how "fast regen" works in the first place, so maybe you referred to serverbound packets. In that case I am not aware of any filter for that inside the plugin.

The doc is not your fault I am just a bit sour that (s)he wants others to be compatible with them and seemingly doesn't take the time to properly reason out what methods you can use to reliably prevent any misfiring. Posting a snippet of an event handler with no more information than what I'd get by looking at the class structure isn't all that helpful IMHO. Just documenting the methods that benefit from some explanation and actually providing either the source or the javadoc along with them could help and shouldn't be all too hard to do. If I still missed some documentation, I apologize for that and would like a link.

I can not test it, but I can make a PR Rayzr or gvlfm could approve/deny. The problem is that before that can be done, I need to test it. And until you actually run my changes I will not be able to see if things work. Some kind of test builds would be needed, I'm not sure how to get them to you though. I will toss a quick fix together and push it to my fork of this repo (https://github.com/I-Al-Istannen/BukkitOldCombatMechanics). Then you can build it from source yourself or, if you can't do that, I can upload a release artifact for you.

If you want to build it and link me I'll test it and get back to you.

I did verify with the dev that 1 tick should be enough. By packet, I was just trying to portray the idea of regen happening. I think your example would be sufficient.

Thanks for the help :)

https://github.com/I-Al-Istannen/BukkitOldCombatMechanics/releases/tag/test-spartan-one

It doesn't crash, but I have no idea if it does anything for you. If it doesn't I will upload one with a lot more debug logs... ;)

I am not sure how. I was hoping in API there was a way to tell spartan you are giving player regen, but seems there might not be. I have asked Spartan dev for help. Hope we can find a way to fix this :)

Yeah, I didn't reply yet because I wanted to wait to confirm before feedback. I do not get the false positive anymore, but:

[12:10:55] [LoginProcessingThread/INFO]: UUID of player SilverRevolt is 467d9f79-6c05-4ffa-b4c7-c0bbf8ba7bd6
[12:10:55] [Server thread/ERROR]: Could not pass event PlayerJoinEvent to OldCombatMechanics v1.6.5
org.bukkit.event.EventException: null
at org.bukkit.plugin.EventExecutor$2.execute(EventExecutor.java:72) ~[patched_1.12.2.jar:git-Paper-1441]
at co.aikar.timings.TimedEventExecutor.execute(TimedEventExecutor.java:78) ~[patched_1.12.2.jar:git-Paper-1441]
at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:62) ~[patched_1.12.2.jar:git-Paper-1441]
at org.bukkit.plugin.SimplePluginManager.fireEvent(SimplePluginManager.java:515) [patched_1.12.2.jar:git-Paper-1441]
at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:500) [patched_1.12.2.jar:git-Paper-1441]
at net.minecraft.server.v1_12_R1.PlayerList.onPlayerJoin(PlayerList.java:370) [patched_1.12.2.jar:git-Paper-1441]
at net.minecraft.server.v1_12_R1.PlayerList.a(PlayerList.java:183) [patched_1.12.2.jar:git-Paper-1441]
at protocolsupport.zplatform.impl.spigot.network.handler.SpigotLoginListenerPlay.joinGame(SpigotLoginListenerPlay.java:124) [ProtocolSupport.jar:?]
at protocolsupport.protocol.packet.handler.AbstractLoginListenerPlay.tryJoin(AbstractLoginListenerPlay.java:132) [ProtocolSupport.jar:?]
at protocolsupport.protocol.packet.handler.AbstractLoginListenerPlay.tick(AbstractLoginListenerPlay.java:94) [ProtocolSupport.jar:?]
at protocolsupport.zplatform.impl.spigot.network.handler.SpigotLoginListenerPlay.e(SpigotLoginListenerPlay.java:70) [ProtocolSupport.jar:?]
at net.minecraft.server.v1_12_R1.NetworkManager.a(NetworkManager.java:255) [patched_1.12.2.jar:git-Paper-1441]
at net.minecraft.server.v1_12_R1.ServerConnection.c(ServerConnection.java:150) [patched_1.12.2.jar:git-Paper-1441]
at net.minecraft.server.v1_12_R1.MinecraftServer.D(MinecraftServer.java:941) [patched_1.12.2.jar:git-Paper-1441]
at net.minecraft.server.v1_12_R1.DedicatedServer.D(DedicatedServer.java:427) [patched_1.12.2.jar:git-Paper-1441]
at net.minecraft.server.v1_12_R1.MinecraftServer.C(MinecraftServer.java:767) [patched_1.12.2.jar:git-Paper-1441]
at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:665) [patched_1.12.2.jar:git-Paper-1441]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NoSuchFieldException: networkManager
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketInjector.(PacketInjector.java:43) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketManager.addListener(PacketManager.java:73) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.module.ModulePlayerCollisions.onPlayerLogin(ModulePlayerCollisions.java:31) ~[?:?]
at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor640.execute(Unknown Source) ~[?:?]
at org.bukkit.plugin.EventExecutor$2.execute(EventExecutor.java:70) ~[patched_1.12.2.jar:git-Paper-1441]
... 17 more
Caused by: java.lang.RuntimeException: java.lang.NoSuchFieldException: networkManager
at gvlfm78.plugin.OldCombatMechanics.utilities.reflection.Reflector.getField(Reflector.java:78) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.reflection.Reflector.getInaccessibleField(Reflector.java:83) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.reflection.Reflector.getFieldValue(Reflector.java:89) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketInjector.attach(PacketInjector.java:59) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketInjector.(PacketInjector.java:41) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketManager.addListener(PacketManager.java:73) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.module.ModulePlayerCollisions.onPlayerLogin(ModulePlayerCollisions.java:31) ~[?:?]
at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor640.execute(Unknown Source) ~[?:?]
at org.bukkit.plugin.EventExecutor$2.execute(EventExecutor.java:70) ~[patched_1.12.2.jar:git-Paper-1441]
... 17 more
Caused by: java.lang.NoSuchFieldException: networkManager
at java.lang.Class.getDeclaredField(Class.java:2070) ~[?:1.8.0_121]
at gvlfm78.plugin.OldCombatMechanics.utilities.reflection.Reflector.getField(Reflector.java:76) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.reflection.Reflector.getInaccessibleField(Reflector.java:83) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.reflection.Reflector.getFieldValue(Reflector.java:89) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketInjector.attach(PacketInjector.java:59) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketInjector.(PacketInjector.java:41) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.utilities.packet.PacketManager.addListener(PacketManager.java:73) ~[?:?]
at gvlfm78.plugin.OldCombatMechanics.module.ModulePlayerCollisions.onPlayerLogin(ModulePlayerCollisions.java:31) ~[?:?]
at com.destroystokyo.paper.event.executor.asm.generated.GeneratedEventExecutor640.execute(Unknown Source) ~[?:?]
at org.bukkit.plugin.EventExecutor$2.execute(EventExecutor.java:70) ~[patched_1.12.2.jar:git-Paper-1441]
... 17 more

Can I just go cry in a corner? What the heck is that??

I can also not reproduce it on:

[23:36:56 INFO]: This server is running Paper version git-Paper-1448 (MC: 1.12.2) (Implementing API version 1.12.2-R0.1-SNAPSHOT)
[23:36:56 INFO]: Checking version, please wait...
[23:36:56 INFO]: You are running the latest version

And also not on

[23:39:50 INFO]: This server is running Paper version git-Paper-1441 (MC: 1.12.2) (Implementing API version 1.12.2-R0.1-SNAPSHOT)
[23:39:50 INFO]: Previous version: git-Paper-1448 (MC: 1.12.2)
[23:39:50 INFO]: Checking version, please wait...
[23:39:50 INFO]: You are 7 version(s) behind

Can you detail what you did to get it to appear?

Could just you write a reply stating whether it works or not when you get around to testing it? Forgot to mention that in my last reply, but it would be most helpful.

Paperspigot 1.12.2 build 1441
ProtocolSupport
OCM
Log in on any version.

Other than that, no idea.

Can't reproduce with the Latest build of this and OCM:

[13:27:24 INFO]: Plugins (2): OldCombatMechanics, ProtocolSupport

Running on

[13:28:02 INFO]: This server is running Paper version git-Paper-1441 (MC: 1.12.2) (Implementing API version 1.12.2-R0.1-SNAPSHOT)
[13:28:02 INFO]: Previous version: git-Paper-1448 (MC: 1.12.2)
[13:28:02 INFO]: Checking version, please wait...
[13:28:02 INFO]: You are 7 version(s) behind

I am joining an 1.12.2 server with a minecraft 1.12.2 or 1.8.9 client.

@elstur Any updates?

Still working fine, even with the error I posted before. No idea what was causing that, but anyway, fixes the AC spam for sure.

Alright, sounds good. Thank you :)

@rayzr522 Should I PR that in as a softdependency?

Sure, @I-Al-Istannen. Sounds good.

Created a separate issue for the player join event. Updated to current OCM version on my practice server and found the issue exists there without this PR.