Closed ETcodehome closed 6 years ago
I can vouch for this, when using an eff. 5 pick and haste 2 there's a LOT of rubber banding.
We need to overhaul the NCP config as a complete set and make sure that requests to lower the value are not influenced by lagged users.
Would you like me to work on this, @uncovery ? I'm pretty versed with how NCP works.
we need to go through setting by setting and make sure we do not get too many false-positives. However, we also need to make sure we do not just lower the limits too far just for some people with bad connections that it becomes ineffective.
One way to do that would be to go through the logfile and run a statistic on it to see what get's hit from by the most diverse (i.e. number of) individual users, then lower that limit, wait a couple of days, do it again.
Current logfile (17MB): https://www.dropbox.com/s/5emoxpy6ua7nc8a/ncp.tar.bz2?dl=0
It looks like the problem is that the config is too strict. We should really lower the values. Can you send me the config file currently?
This is the current config: https://www.dropbox.com/s/4glpthuyrs1lowa/config.yml?dl=0 Points I want to make:
What I'm noticing is that a lot of very trustworthy players (Dani, Sleeping_Owl, alleywig, bdecima, etc) are getting these errors. This somewhat proves my point that the values need to be lowered. Here's the stats:
Passable: 26737 Matches SurvivalFly: 20819 Matches Visible: 14905 Matches FastBreak: 4060 CreativeFly: 2520 MorePackets: 1793 Direction: 1300
Our biggest problem is Passable.
that's great. can you tell me what percentage those are over the whole file? Then we can compare to future results.
ok so to fix passable, what violation levels do we normally talk about when we get cancelled events?
The violation level averages out to about 200.
Here's the percentages.
84990 Lines Passable: 26737 Matches, 31.459% SurvivalFly: 20819 Matches, 24.4958% Visible: 14905 Matches, 17.5374% FastBreak: 4060, 4.777% CreativeFly: 2520, 3.9651% MorePackets: 1793, 2.1097% Direction: 1300, 1.5296%
I spent a lot of time today looking at this data. I don't know anything about NCP, but I cleaned up the data and put it in a database. Here's an Excel sheet that I believe gives you the details you're wanting, Uncovery. If you don't have Excel, I can just provide the summary data in text, but I thought this would be more useful. If you want some more intricate results, I can do that from the database.
If you want to know what "cleaned up the data" means, and particularly why there are a total of 75,522 records in my data while the log file had over 84k lines, there are 2 things I cleaned up. First the plugin reloaded or something 294 times, each time inserting 11 lines of detail about that. I deleted all those. Second, there are over 5k records for the user NoCheatPlus that are irrelevant to this analysis.
Overall, I concur with darthandrew. His percentages are actually low after removing the irrelevant lines. I think most of these records represent false positives, depending on how you define that. I can tell you I get kicked for flying when sailing in a boat.
Wow, @dani0010, I don't know how you did it but this helps a lot. Thanks for the spreadsheet!
(P.S: I am Relavis. My old username was darthandrew1.)
@dani0010, this is great. Can you do me one more favor and split the VL's out into another column? thanks!
In the long run I think we have to write an import script that moves those logfiles into a DB so we can visualize them. I would imagine that we could have a "false-positive" ranking weighted by user level even. Then a dropdown by violation type, a JS chart to visualize.
Okay. So we should definitely update to the newest version, that is very important (bugfixes, security patches, etc). We should then build our config from scratch.
yeah let me download it so that it will be updated on reboot.
Okay. I'll get the newest version of the config so we can edit it.
Let me know what version you are going to download, just so I can get the same config.
Make sure you install ProtocolLib if we don't have it, according to the changelog it's the only way to log attack frequency.
Yeah no worries on that, it's used by many plugins.
Here is the data with a separate VL field at the end. This is a semi-colon delimited file you can dump into any tool or DB you have. If you'd like any summary of it, I can do that. ncpData-withVL.txt
thanks a lot, this is very helpful. No need for the summary for now, will see what I can get out of this
Here is the default config for the version we will be running soon. https://www.mediafire.com/?6fww5g22ipd1ota
I'm trying to find some way to collaboratively edit this.
That would be here then. we can add it as a file to github.
The file is here now: https://github.com/uncovery/uncovery_me/blob/master/plugin_configs/nocheatplus.conf
This seems to be fixed now. It can be closed.
What exactly is fixed?
I'm not seeing any more rubber banding blocks. That's what he originally made this post for.
I am not sure if psiber made the post for your issues only. from the stats in the logfile I still see that there might be some issues. Also we hardly changes anything in the config.
Well, my PR is still open. It's not only my issue, it was his as well.
to clarify, I made the issue that NCP seemed to be causing me a lot of grief due largely to my lag.
the NCP reporting you have both conducted since then seems to indicate that false positives are a serious issue with NCP (and not limited to my experiences due only to client side latency).
I think that uncoveries recent review of stats from the logfile should be our basis to work off.
Perhaps we increase grace values on high incidence statistics by 50% increments then wait a week to gather new data, repeating until incidence rates plateau?
Since we don't use NCP anymore I think we can close this.
is there any chance I could get access to the /ncp info command so I can see why I am continually getting rubber banding block breaks and movement checks during normal play?
I have reviewed the related yml config, but the settings mostly seem to match the default ones currently on github.
The only other way I can think of addressing it is changing delay to a higher value and grace to a higher value otherwise. (propose delay 135, grace 3000)
checks: blockbreak: direction: active: true actions: cancel vl>10 log:bdirection:0:5:if cancel fastbreak: active: true strict: false delay: 90 intervalsurvival: 100 grace: 2000 actions: cancel vl>0 log:fastbreak:3:5:cif cancel