26 lines
1.0 KiB
Plaintext
26 lines
1.0 KiB
Plaintext
|
*** This is a warning about bip's replay/backlog system ***
|
||
|
|
|
||
|
|
Bip has a backlogging system which will send back parts of the last logs upon
|
||
|
|
client connection. Depending on your configuration, that may mean a *lot* of
|
||
|
|
data sent back to your client.
|
||
|
|
|
||
|
|
Users' messages will be replayed as if they were being sent at the moment your
|
||
|
|
client connects to bip, and if not disabled, system messages will appear as
|
||
|
|
coming from the "-bip" user.
|
||
|
|
|
||
|
|
Considering that, you may want to disable your client's anti-flood system,
|
||
|
|
totally or not, depending on it's flexibility.
|
||
|
|
Since bip doesn't relay CTCP messages, you can safely let your client's
|
||
|
|
anti-flood system manage them.
|
||
|
|
|
||
|
|
[Xchat]
|
||
|
|
If you're using Xchat, you can "disable" it by issuing these commands :
|
||
|
|
/set flood_msg_num = 1000
|
||
|
|
/set flood_msg_time = 10
|
||
|
|
In fact you'll tell xchat to activate its anti-flood system when you're
|
||
|
|
receiving more than 1000 messages in less than 10 seconds.
|
||
|
|
|
||
|
|
If you forgot to set these, private messages may not appear in separate tabs
|
||
|
|
as usual. If so, simply issue a :
|
||
|
|
/set gui_auto_open_dialog on
|