Bukkit

@chilgames

You can always: 1) dynamically change the number of warnings a player has through the bukkit console via "yasf setplayer <playerName> <newDemeritCount> (to an amount less than the ban amount); 2) manually change the numer of warnings a player has by editing the warnings.yml file (to an amount less than the ban amount); 3) change the settings in the config file (e.g. "maxwarnings") to increase the maxwarnings before getting banned.

I will be making other changes (as per some of the previous comments), but the existing functionality should enable you to get back on your own server.

@BrotheBear

Hm. Editing the standard filter in-game might be awkward, considering that the filters are regular expressions (which can be tricky to write/edit and get right), and the filters are associated with custom actions (it might be a bit of work to make an interface that would be easy/simple to use to select which filter you're interested in, etc.). I'll need to think on that one.

As for allowing OPs to be immune to the filter, I'll look into what it would take to implement permissions (which might be a better overall solution?), but I could probably add a quick boolean flag to indicate whether or not OPs would be checked against the filters). That option should be fairly quick to implement I'll put that in one of the next builds.

@ravenx99

Thanks for the bug report. This is fixed in version 1.2.0.

I've also added the string "group, huh" to my unit tests to ensure that one doesn't happen again. And I will try to upload the source code soon (so that people have access to the latest regexes being used).

As for this bug, someone had asked for a phonetic variations of a certain word, specifically phuc, phuck, phuk. Unfortunately in my haste I wrote the regex with "c*" and "k*", making them both optional; hence "phu" would also trigger the filter, as in "grouP, HUh?" (I also add "[^a-z]*" between most letters - with some exceptions to account for real uses of them - to catch cases where people put spaces and/or non-numeric characters between letters to try to fool the filter, such as "D, , , U , , , C , , , K").

BTW, you can use YASF to write your own regex expressions (and you don't have to use the pre-defined filters if they're not filtering how you'd like them to). So you could just use it as a custom regex filter.

@AKMiner98

At some point I'll look at uploading the source somewhere. For now, the quickest thing might be just to open up the jar file through a java decompiler.

@FurmigaHumana

For now, make sure the words you add to your filter do not have accents in them (sorry for being a bit short-sighted: I assumed English words, so the code to remove accents assumes the original word filters didn't have any accents to begin with). There might also be a greater potential for "false positives" on some of the filters (depending on whether a variant of the English swear word is a valid word or word-fragment in the other language). In that case, though, you could always disable the built-in filter and add your own.

I'll correct the accent issue in a future version (basically, with a few exceptions, the new code that I'll write for this will automatically remove any accents from the filters, as the current current code tries to strip accents from the text being checked.)

I am looking into adding additional built-in filters for some other languages, btw, although without having a good understanding of the language in question I may not be able to create the most accurate filters (I may not know what the variations of that word might be, or what acceptable exceptions might be).

@FurmigaHumana

The "filter:" keyword is used to enable the standard, built-in "smart" filters. These are pre-built filters that have been tested against a number of variations of the given word: e.g., duck, d*u*c*k, duuuuuck, D\_/CK, etc.

To define your own list of words, use the "regexFilter:" keyword (a non-trivial example is given in the default filters.yml file). The filter needs to be formatted as a "regular expression" (RegEx). It's more complicated than a basic string / word, but much more powerful.

In your example, you'd configure it like:
regexFilter: myCuteWord|myCuteWord2

The pipe ("|") symbol is like an "OR" in regEx, so you can add your words together that way (or create multiple Rules, with each word in its own Rule).

As another example, let's say you wanted to search on "Sock" as well as "$ock" or "Sok" or repeated letters like "$sssoooocck" (or any combination or variation of those options). The following regexFilter would do that:
regexFilter: [s$]+o+c*k+

As a final example, what if you wanted to filter on the word "all", but not words like "ball" or "alloy" or "balloon"? Some of the other swearing filters require you to define lists of excluded words (and hopefully you catch all of them). With RegEx, you can instead use the following rule:
regexFilter: (\b)all(\b)

The "\b" in regex denotes a word Boundary (beginning or end of a word). [The brackets around it aren't needed; you could instead use: \ball\b].

(Note: Each Rule can only have at most one "filter:" parameter and one "regexFilter" parameter. You can either separate each word with the pipe symbol, or create another Rule).

If there are additional words that you'd like added as default "smart" filters, I can look at adding those in a future release (you can build your own via RegEx expressions as well, but I may be able to come up with more powerful rules - more powerful than RegEx alone potentially - since the built-in rules can have additional logic programmed into them).

An updated version (currently being tested against the latest bukkit release) is coming soon that will:

• allow you to execute any user-defined command(s) when a rule is violated.
• take into account accented characters (e.g., "dűćķ") when performing matches.
• additional word/letter/symbol combination checks

If you change the Rule's "bumpcount" to "0", then when that Rule is violated (i.e., a swear is found) the Player's warnings will never get bumped up (maybe I needed a better name for that parameter), so they'd never reach their maxwarnings and would never get banned.

I'll add an option in a future version to configure what to do (if anything) if/when the maximum number of warnings has been reached (and/or allow that mechanism to be explicitly disabled).