Closed Maxopoly closed 5 years ago
Any updates on this pull?
@Maxopoly New thoughts or ideas on this? Moved on?
This probably works now, at least it did when I messed around with it locally. Follow up to it might be needed, but I probably wont know what to fix until it actually runs on Civclassic prod.
from https://www.reddit.com/r/civclassics/comments/8tyaml/changelog_for_6262018/ sounds like this PR is confirmed working? If so, great work man!
It was more like a live test, hold on for a bit before merging until I hear back whether everything works as intended.
Any updates on this Max? Good to merge? Has fixes?
Supposedly it's working, so yeah it's probably fine to merge.
still looks great. I will try to get to merging it soon.
ok to build
Build finished.
ok to build
build this please
test this please
First of all, this isn't ready for merging yet, I need to read over it again, add more docu and test it. That being said, it's probably far enough to at least get some thoughts regarding the approach in general.
BanStick seems to have been built around Devoteds single account policy. While it supports more than one account per player, it's handling of player association groups is not powerful enough to deal with the situation that multi accounting servers bring with them.
For example:
Player A plays on IP1, Player B plays on IP1 and IP2, Player C plays on IP2.
It's likely that Player A and C are the same person or at least ip sharing in a way that should be trackable. In the current system they do not have a share though and there is no direct way to find their connection, likely it would go unnoticed forever.
The solution here is to do a recursive lookup through shares to retrieves not only direct shares, but also transitive ones to create alt groups. Basically we're doing graph theory here, players are nodes and shares are edges. To determine alt groups, we are finding the biggest fully connected subgraph containing a given player. An additional config option allows limiting both bans and the account number limitation not only based on shares, but these transitive alt groups.
In an ideal world we'd be done here, but sadly we have to deal with players who use each others account/computer/VPN and get all mixed up in ways they shouldnt be.
Banstick already offers pardoning shares to combat this, but when dealing with situations where we have to assign n different accounts to m players each, pardoned shares are too weak of a concept to solve this problem, especially because new ones may be created in the future, for example when people play in the same house on dynamic ips.
To deal with this, I decided to introduce the concept of exclusions, which are like the opposite of a share. They contain 2 players and specify an edge in the graph, which will be assumed nonexistent when trying to find the alt group subgraph. To create an exclusion, a share between the two players doesnt even have to exist yet though.
Admins are supposed to simply give a list of accounts which make up a real player via command and BanStick will create exclusions to cut all of those accounts out of the alt group they are currently in and create their own little pocket.
As you might have already noticed, the usage and kind of the thought behind it is heavily inspired by MiscLog's approach.