You must login to post a comment. Don't have an account? Register to get one!
better performance / less false positives
www.Minecraft.Jee.pl - MineFox 1.5 Professional minecraft server
Include Antixray Too ,and better compability with plugins like Spleef.
Sorry for my bad english
We would love to, however we can't really test out all possibilities with high level potion effects ourselves. Best is if you can make a ticket and re-state the problem (effect level, command block, check alerts), please also state output of the "ncp version" command and if/what blocks are nearby.
Latest Release (1.6.4, approved): NoCheatPlus 3.10.6-RC-sMD5NET-b644
(Development builds: Jenkins)
More compatibility with plugins:
when I type /effect @p jump 1 15 in a commandblock, HighJump/SurvivalFly is detected.
Already fixed. Just get latest development version on our Jenkins site and delete the NoCheatPlus configuration (to generate a new one). Or just add "cancel" (without "") on the last FastHeal actions position.
Awesome plugin! A lifesaver!
Recently there has been a lot of usage of instant regen hacks, and NCP doesn't cover them well. My vote on next focus is getting something to prevent that :)
Can you guys code a little lighter on the PlayerMoveEvent? I'm trying to reduce player motion lag on my server and I see that this plugin uses the most resources on the PlayerMoveEvent.
We never had an xray system or am i mistaken?
Are you thinking of something like the Orebfsucator plugin?
Reinstate the anti X-ray system was there before. One that disables the macro and recharge the chunks!
Actually i don't want to say "multi-threading is stupid in this context". If processing of events might get delayed, say due to queuing, one could clearly start with intercepting the packets and then calculate/process something which then will be used when the event is processed, to speed up things and to gain the bit of extra-knowledge that one can have with intercepting packets. The processing routine for the event would have to force calculation (wait/force) if those are not ready at the time the event is fired.
However that needs intercepting packets (non-Bukkit-API) which is not what i would build on by default, at present. Using ProtocolLib might be a nice add-on, however a range of servers might not want to add that overhead. Hard to tell if the gain on speed compensates for that for servers that don't use ProtocolLib anyway.
One could work with chunk snapshots and do a lot of the calculation there, however the number of threads should not necessarily scale with the number of players but rather relate to the number of CPU cores available.
No gain of accuracy should be there by querying the position from the player, except for knowing the "actual" position, packets-level listening should allow keeping track fully.
Currently i don't see how that much accuracy can be gained for moving checks, while implementing something that would work is not a small project in terms of Bukkit-plugins. It is uncertain how the protocol will change so i don't see the fully-protocol-based plugin gaining that much over Bukkit-API+small extensions (and be those protocol.level listening...). Certainly i am keeping an eye open concerning this topics...