Ticket #9 (closed enhancement: wontfix)

Opened 4 years ago

Last modified 4 years ago

Better handling of flood and lags

Reported by: ite Owned by:
Priority: minor Milestone:
Component: Core Version: 1.6.20
Keywords: Cc:

Description

I ones wrote a botnet tcl that made the bot that lagged least
give the joining person voice. That way ppl that joined knew
which bot to ask for op since it lagged leaste relative to them
and there where no mode floods (not all nets are like undernet that
wont allow you to do the same mode several times)

It worked well the idea was good.
The basic idea is when a bot triggers on some set event
tell the other bots in the botnet hey i think im first with this and a
random nr
if another bots lag more there aint a problem they just say ok i will let
you
handle it (just does nothing no returning data so not much more traffic)
if another bot thinks he lag just as litle and also wanna do the thing they
just
compare the random nr and the one with the higest wins. (no additional text
sending is nessessary in this case either).

Do you understand the idea?
Basicly with very litle extra botnet traffic this consept lets all the bots
watch same events and w/o flooding and with less relative lag.

Wouldn't it be nice to make a framework for this in a module
that adds a tcl command so ppl can use the consept for any tcl event
right now I'm not totally clear how this should look/work
but I thought it was to good of idea to just forget about it w/o
letting other ppl think about it too.

To clarify and give an easy example of the implemation
When a person joins the channel the bot that lags least to them sends
channel rules. (sometimes a bot lags 10mins or so and a person can brake the
rules alot quicker then that)
another example:
the voice thing which i find handy
another example:
?? FAQ scripts... !seen scripts etc.

Basicly one can run same stuff on the botnet w/o getting flooded by more
then 1 reply
and it will descreese the relative lag.

Change History

comment:1 Changed 4 years ago by pseudo

  • Reporter changed from pseudo to ite

comment:2 Changed 4 years ago by pseudo

  • Status changed from new to closed
  • Resolution set to wontfix

This belongs to the scripting level. We won't implement this in the core.

Note: See TracTickets for help on using tickets.