I want to hear opinions about this conversation and please try and remain productive so this can turnout to be a good discussion.
[09-03-25][12:21:19] im wondering of we should publish the chatcontrol as an extension
[09-03-25][12:21:27] 1 = guest (everybody), 2=registered (password protected), 3=operator (can kick), 4=super user (can promote operators), 5=admin (hub owner, can do everything)
[09-03-25][12:21:52] what do u think about that ?
[09-03-25][12:22:22] don’t know, need to see more detailed use-cases
[09-03-25][12:22:39] u remember what it was right
[09-03-25][12:22:55] [09-03-25][12:22:45] <-DCDev-> [command:] !chatcontrol
- [09-03-25][12:22:45] <-DCDev->
The chatcontrol command:
Usage: chatcontrol list
– brings up a list of chat controls and their unique ID
Usage: chatcontrol add “regular expression” flags [modification]
– adds the regular expression with corresponding flags. The expression must be enclosed in quotes.
The flags are :
Drop user 1
Kick user 2
Don’t do anything to client 4
Hide the matching word from chat 8
Replace matching word with stars ( **** ) 16
Modify matching word with given modification 32
Control private chat as well 64
Report to operator’s chat 128
Also check searches 256
As you can see, you must not select all flags, but one of each category.
Example: Drop user and replace word with stars : Use flag 1+16=17
Note: flag 64, 128 and 256 are independent of others.
Note: The modification parameter is only available for flag including 32.
Usage: chatcontrol mod ID/“regular expression” flags [modification].
– mods the regular expression already listed given by string or it’s unique ID. Parameters are same like on adding.
Usage: chatcontrol del ID/“regular expression”
– deletes the regular expression given by itself or by it’s unique ID.
Usage: chatcontrol save “filename”
– saves the current wordlist into file specified by path. For security reasons, you can write to DSHub installation dir only.
Usage: chatcontrol load “filename”
– load the wordlist configuration from the file specified by path. For security reasons, you can read from DSHub installation dir only.
[09-03-25][12:23:01] yes, but ionly have a partialimage
[09-03-25][12:23:20] this system is probly one of the best ive ever tried
[09-03-25][12:23:33] and it could be implmented into any hubsoft
[09-03-25][12:25:08] hm, yes
[09-03-25][12:25:16] i’d do that as a plugin
[09-03-25][12:25:37] but it could be converted into a hubsoft extension
[09-03-25][12:25:41] right ?
[09-03-25][12:28:22] kind of, but… what do you wish to accomplish? basically having a UI in your client for configuring filters?
[09-03-25][12:30:58] the idea is a antispam system blue print that hubsoft developer can implement
[09-03-25][12:31:03] into thier hubsofts
[09-03-25][12:31:37] right, so basically a “specification” ?
[09-03-25][12:32:25] yeah basicly it would be
[09-03-25][12:33:07] then it doesn’t need to be a extension, in case it doesn’t change the ADC protocol
[09-03-25][12:33:41] then how to get a good spread on it
[09-03-25][12:34:52] change the protocol
[09-03-25][12:34:54] should we start up a specification pool at adcportal perhaps
[09-03-25][12:35:13] yeah, that could be useful
[09-03-25][12:35:32] that developers can submit ideas that arent exactly changes in the protocol but usefull non the less
[09-03-25][12:35:47] call it whitepapers perhaps ?
[09-03-25][12:35:51] or something
[09-03-25][12:36:50] So many devs thinks rfc need to be the real deal
[09-03-25][12:37:09] me and pietry had a conversation about that
[09-03-25][12:37:17] well, we could of course submit ADC as an RFC
[09-03-25][12:37:19] we have been brainstorming about this before
[09-03-25][12:37:22] after some cleanups
[09-03-25][12:37:43] i do want developers to use adcportal more
[09-03-25][12:37:47] for brainstorming
[09-03-25][12:37:56] instead of going cowboy solo on everything
[09-03-25][12:38:20] (i like cowboy)