A regression from fca23c7d5594ba098324c0236bd5f6f62488e93b overwrote the target UID with a nick before passing it into applyModes(), which raises an "unknown mode target" warning and causes the mode change to be dropped.
(cherry picked from commit af210638342651dcb86c83319231dbb5ed4de98d)
This should now support SVS2MODE without account info, used by Anope versions < 2.0? Also, the protocol module no longer stores umode +r as an actual user mode, as doing so isn't needed.
Closes#296.
(cherry picked from commit 97d09c5015865e4236e13e855628beab9373338f)
This prevents mode bounces, kick failures, and the HACK server notices from showing up.
(cherry picked from commit fca23c7d5594ba098324c0236bd5f6f62488e93b)
A regression from fca23c7d5594ba098324c0236bd5f6f62488e93b overwrote the target UID with a nick before passing it into applyModes(), which raises an "unknown mode target" warning and causes the mode change to be dropped.
This should now support SVS2MODE without account info, used by Anope versions < 2.0? Also, the protocol module no longer stores umode +r as an actual user mode, as doing so isn't needed.
Closes#296.
Some of the logic was inverted so that the Clientbot would try to kick invalid things like GLolol/ovd, and send clientbot KICK payloads when it's supposed to forward an actual kick.
This also fixes KICKs from servers not being relayed by clientbot.
Suggested by @cooper.
This tracking system solves the problem of failed relay kicks causing channel desyncs, because what's seen as a successful KICK when PyLink is linked as a service might not forward
successfully on clientbot network. This can be caused due to the clientbot not being opped, the target being immune or having higher access than the clientbot, etc. When a NAMES reply
(delayed in this case) is received for any channel where an initial /WHO has already been received, a JOIN hook will be sent for any users on the kick queue to rejoin them on the relay.
