Hexhub, Описание

corrected: the right for $UserIP was required for passive client connections (thanks to RoLex for reporting this problem)
corrected: users who had the right to flood the hub were still blocked by DDoSflt (thanks to RoLex for reporting this problem)

if a client sends a tag with a client version that would support extended protocol but without sending $Supports, the tag is considered fake
new option: "Kick bots that send $Quit" (!set cmd ucommands noclientquit , default is on)
new option: "Kick bots that send $Version 1.0091" (!set cmd version nodecimal , default is on)
new option: "Users must get nicklist to be able to search" (!set cmd getnicklist search , default is on)
new option: "Minimum online time to enable searches" (!set cmd search minonlinetime , default is 5 seconds)
new event for plugins: onBadSettings(userId,59) (fake client version)
new event for plugins: onBadSettings(userId,60) (search without $GetNickList)
new event for plugins: onBadSettings(userId,61) (search requests are not yet enabled for this connection)
new right for plugins: broadcast (!set ext %[dll] rights broadcast)
BayTSP search bots get banned in firewall by default
GeoIP information was updated with GeoIPCountryWhois.csv from January 3th

2011-12-03 HeXHub 5.07a Firewall 1.10

corrected: error parsing an index with a missing "</key>"

2011-05-29 HeXHub 5.07 Firewall 1.10

corrected: the function SetMode applied the chat filter to a wrong user (thanks to Meka][Meka and RoLex for reporting this problem)
added: usersearch at http://hublist.feardc.net , usersearch script was written by RoLex
GeoIP information was updated with GeoIPCountryWhois.csv from May 2nd

Changes:
added a new registration server: hublist.te-home.net
added a workaround for plugins that free the names of registered commands and help strings before unregistering them
the user search procedure that used hublist.feardc.net now uses hublist.te-home.net
new supported protocol extensions: ZLine and ZPipe0 (http://nmdc.sourceforge.net/NMDC.html?#41;; if one of these extensions is supported and the support for these extensions is enabled, the hub will compress private buffers that will be sent (needs zlib1.dll)
new option: "ZLine enabled" (!set cmd supports zline, default is off)
new option: "ZPipe0 enabled" (!set cmd supports zpipe, default is off)
new option: "ZLine required" (!set cmd zlinereq, default is off)
new option: "ZPipe0 required" (!set cmd zpipereq, default is off)
minimum possible send cycle was lowered to 1 (was 10)
GeoIP information was updated with GeoIPCountryWhois.csv from April 2nd

2013-04-14 HeXHub 5.08b

corrected: private messages from users who had clients that support compression were always compressed even when they were sent to an older client (thanks to RoLex for reporting this error)
corrected: the restrictions for $MyINFO strings were sometimes verified before a $MyINFO was received (thanks to RoLex for reporting this error)
corrected: the hub showed a wrong language string for minimum hubs (thanks to RoLex for reporting this error)

(HeXHub 5.08a)

corrected: if support for ZPipe is enabled, the hub no longer compresses original data that may be sent to old clients (thanks to RoLex for reporting this error)
corrected: the $Lock string showed an older version in Pk (thanks to RoLex for reporting this error)
resolved a compatibility problem with clients that send $MyPass after $GetNickList and $MyINFO
if a nick is bigger than HeXHub's maximum allowed nick length, a warning message is shown and, if the client supports NickChange, a $ClientNick is sent; clients that don't support NickChange get a $Hello with their old huge nick (suggested by RoLex)
when a soft hyphen is used in a nickname, it is replaced with a minus character (suggested by PлttлrOSS)

corrected: if support for ZPipe is enabled, the hub no longer compresses original data that may be sent to old clients (thanks to RoLex for reporting this error)
corrected: the $Lock string showed an older version in Pk (thanks to RoLex for reporting this error)
resolved a compatibility problem with clients that send $MyPass after $GetNickList and $MyINFO
if a nick is bigger than HeXHub's maximum allowed nick length, a warning message is shown and, if the client supports NickChange, a $ClientNick is sent; clients that don't support NickChange get a $Hello with their old huge nick (suggested by RoLex)
when a soft hyphen is used in a nickname, it is replaced with a minus character (suggested by PлttлrOSS)
corrected: private messages from users who had clients that support compression were always compressed even when they were sent to an older client (thanks to RoLex for reporting this error)
corrected: the restrictions for $MyINFO strings were sometimes verified before a $MyINFO was received (thanks to RoLex for reporting this error)
corrected: the hub showed a wrong language string for minimum hubs (thanks to RoLex for reporting this error)
corrected: users who validated a nick that was truncated were kicked for nick faking (thanks to RoLex for reporting this error)
corrected: when invalid characters were replaced in a nickname at login, the hub didn't add original nick to nicklist if the client didn't support NickChange (thanks to RoLex for reporting this error)

corrected: dchublist.com is no longer advertised for its user search function that is no longer available (thanks to RoLex for reporting this problem)
corrected: auto-renamed users with nicknames bigger than maximum nick length will have their nick truncated to a lower size to make room for the extra characters that are added (thanks to RoLex for reporting this problem)
corrected: auto-renamed users with nicknames bigger than maximum nick length were kicked when sending private messages (thanks to RoLex for reporting this problem)

corrected: when renaming users to prevent nick collisions, the hub could had re-used a buffer that didn't have the last generated nickname in it (thanks to RoLex for reporting this error)
(HeXHub 5.09b)
corrected: the hub sent $Hello 3 times and a $Quit to renamed users if the rename was caused by a nickname collision (thanks to RoLex for reporting this error)