just a reminder --- there are changes in it you don't want #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
create whitelist and blacklist headers also when the Enable Defaults button for xantispam is used
allows to blacklist all online notifications and allowing only those that are whitelisted fixed creating whitelist and blacklist headers when pressing the xantispam default settings button
from getting autoresponses sent to them
xantispam_transparentlookup() only once, after that use cache lookups only
+ save and load to and from files + saving and loading supports base64 encoding so non-text files can be interchanged via notecards
when appling a diff
annoying warnings
for the internal text editor
+ allowing xantispam rules to use arbitrary strings in the "from" part
+ format of whitelist and blacklist changed in the process (they are
emacs org-mode tables now)
+ limit of simultaneously open queries removed, avoiding duplicate
queries
+ now blocking by default when an identical query is issued again
before an open one hasn't been answered
+ some minor fixes to notifications created by the media filter
+ added new rule types:
&-DomainHandleMediaURLs
&-GRLogDontSave
PlayFromMediaURL
* mouse wheel scrolling accelerated experimentally
be against the Linden TOS added context menu entry for the internal editor to start an external editor fixed working directory setting in the xantispam process launcher adjusted xantispam list header creation to new format of black-/whitelist
into work --- initial merge after forking from https://github.com/Lirusaito/SingularityViewer adjusted to use LLLogChat::makeLogFileName() to solve conflicts Conflicts: indra/newview/llimpanel.cpp
offers distinctly by origin and type; involves new rules "&-InventoryHandleDistinctly" and "AcceptInventory?[type]"
chat history into the external editor
disables xantispam distinct inventory accept features which will be put back with next commit
configured for it. Otherwise inventory handling rules can be overridden by other rules, especially when non-relaxed mode is enabled.
"&-ConfigInverseOrderForSilent" which can change the order from 'deny, allow' to 'allow when not denied' for friend online status notifications which allows whitelisting such notifications only for those friends you want to see them for rather than having to blacklist all the ones you don't want to see when not in relaxed mode
it's possible that they have been prefilled on demand already through transparent lookups
not available, or when a decision-making logic is
disabled
... now is a seperate function, and disables (i. e. skips) speed rezzing when enabled because there's no point to do speed rezzing when adda is used. (Adda does a much better job anyway, and it does it all the time.) Fixes: do not fall below the minimum draw distance, and set the minimum number of frames to average to the allowed minimum if it's lower. Perhaps the compiler optimizes better when adda is in its own function, and it may be easier to solve merge conflicts.
complements making the inventory invisible on teleport
…arityViewer Conflicts: indra/newview/llglsandbox.cpp as upstream
I'm still getting an assertion when opening the radar floater after the inventory was opened, so be warned (minimize it instead of closing it). ASFAICT, this was introduced by upstream. I haven't had time to look into it yet.
I won't call it a fix because now the radar floater may remain underneath other floaters when closing and re-opening it. However, it's much better than crashing after the assertion comes up.
group-messages by message content This is now being tested. I might end up running the messages through spamassassin, or at least some perl script I'll write ...
You can specify regular expressions with xantispam rules now. Each rule comes with an integer which is the score to add to a total for the message which is being checked. The score of each matching rule adds to the total score until the total score goes over a threshold. When the total score is over the threshold, the message is considered spam. The message is replaced with "[blocked spam from]", and the sender gets a message "[spam message blocked by recipients client]". You'll be notified about this by getting an IM sent to yourself. The original message as was sent will be logged unaltered if you have logging enabled. The 'from' part of the xantispam rule gives the regular expression. For example: | come.*http | &-RxScore!6 Since the pipe sign is used as a column seperator, you currently cannot use it to specify regular expressions. I'll have to see what I can do about that. In the meantime, just use multiple rules when you need an OR. Same goes for the colon. Since it's used as a wildcard, you currently cannot use it within regular expressions. Two new settings accompany this: AntiSpamXtendedRxMinLength The default is 85 characters (UTF-8). When a message is shorter, it won't be checked. AntiSpamXtendedRxScoreThreshold This is the threshold mentioned above. The default is 5. You'll find those among the debug settings. As to the regular expression syntax: The boost library provides 'regex_search()', which is used for the matching, so you can always look it up if in doubt (seems pretty much like what perl uses). If you have not specified any '&-RxScore!' rules, processing will not find any matches, and no messages will be classified as spam. You might want to set the threshold very high in that case because that saves the lookups of the rules. Only the rules currently in the cache (i. e. in memory) are being checked. This is unlikely to change because resorting to the rules stored in the blacklist seems a bit unreasonable here performance-wise. I'm still a long way away from overflowing the rule caches (wich hold up to 64k rules). Be careful not to omit the score from a '&-RxScore!' rule, and especially don't put anything but an integer after the exclamation mark. When the rule is too short, i. e. doesn't have anything after the exclamation mark, it will be ignored. Put something else than an integer, and unexpected things might happen.
This calls for an /i flag like perl has. We'll see ...
seems to lead to performance problems
This should fix it. I don't trust it yet, so some debugging info is left in which will be removed later.
LiruMouse
force-pushed
the
master
branch
4 times, most recently
from
2a96699 to
3b5a98e
Compare
LiruMouse
pushed a commit
that referenced
this pull request
Mar 18, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.