View Issue Details

IDProjectCategoryView StatusLast Update
0002394unrealinstallingpublic2015-08-08 16:01
ReportervonitsanetAssigned Tosyzop 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionno change required 
Product Version3.2.2 
Target VersionFixed in Version 
Summary0002394: Kicking/Changing modes for multiple channels
DescriptionUnreal does not support: /kick user1,user2,user3,.....,.....,..

It will be nice if such feature added on unreal.
It for eggdrops (they supports mass kicks) and for mirc scripts too.
1 command for many kicks. Clone detectiong etc..

Of course everything can be done without it and its not needed for most situations but it will make more easy some things for some of the reasons i have said before.

Also, we could add support for /mode channel1,channel2,channel3 ...
TagsNo tags attached.
3rd party modules

Relationships

has duplicate 0003258 closed New core feature: Seperate multiple channels in /kick and /mode with commas 

Activities

aquanight

2005-03-05 13:30

reporter   ~0009435

Might want to also see ht tp:/ /www.phpmemx.net/~unrealir/forums/viewtopic.php?p=7846#7846 (remove the spaces) and the posts below

Int21h

2005-03-05 17:15

reporter   ~0009440

Maybe it also would be useful if you could kick by mask, f. eg. : /kick #probe *a*!*@* (would kick everybody with an "a" in his/her nickname).

Stealth

2005-03-05 17:58

reporter   ~0009441

These both can easily be done with client side scripts.

codemastr

2005-03-05 20:04

reporter   ~0009443

[quote]Maybe it also would be useful if you could kick by mask, f. eg. : /kick #probe *a*!*@* (would kick everybody with an "a" in his/her nickname).[/quote]
Might as well just replace that with a command called /channeltakeover

aquanight

2005-03-05 23:27

reporter   ~0009444

No... kick masks would not be a good thing. If multi-kicking (at least /kick #channel user1,user2,user3,etc - I just don't want to even think about the multi-channel format right now :) ) is added, I would say limit it to ~4 users per kick (probably the most eggdrop/etc should ever need to kick with proper masks). I don't know what the limit is for ircds that do implement multi-kicks, but I think 4 would be safe number to start with :) .

White_Magic

2005-03-06 09:55

reporter   ~0009446

Last edited: 2005-03-06 09:56

[quote]quote:
--------------------------------------------------------------------------------
Maybe it also would be useful if you could kick by mask, f. eg. : /kick #probe *a*!*@* (would kick everybody with an "a" in his/her nickname).
--------------------------------------------------------------------------------


Might as well just replace that with a command called /channeltakeover[/quote]

rotflmao! so true so true :D
another point i would say is, " where does the /kick nick1,nick2,nick3 " end? nick59271 maybe?
Oh and in saying that, sure add this command but id say u better make +f have " kick protection to set +Q (which can be removed anyway / let alone +f can be removed) to stop the take over, - i dont like this much

( edit: i cant use the quote thingie on here :( )

vonitsanet

2005-03-06 10:18

reporter   ~0009448

[quote] another point i would say is, " where does the /kick nick1,nick2,nick3 " end? nick59271 maybe? [/quote]

No. it will have a limit for 3-4 users of course.

Trocotronic

2005-03-06 10:24

reporter   ~0009449

It could keep privmsg's logical of MAXTARGETS (as /privmsg nick1,nick2,...,nickN_MAX text) but for /kick ick1,nick2,...,nickN_MAX # reason.

Shining Phoenix

2007-03-11 01:35

reporter   ~0013303

Hmm...take square root of MAXTARGETS, then round to the nearest whole number. That number could be the maximum number of channels and maximum number of nicks specified in the /kick

tabrisnet

2007-03-14 01:22

reporter   ~0013310

kickmask can be done, but it probably should be done in services where more permission checks can be done. SrSv takes this approach.

as to multikick including multiple channels, hmmm. have to think about it. meanwhile, SrSv has /cs kick #chan user1,user2,user3 reason here

vonitsanet

2007-03-14 19:54

reporter   ~0013315

Not all services.

tabrisnet

2007-03-19 16:30

reporter   ~0013318

Did I say all? I specifically said that it _should_ be done in services due to better knowledge about the channel. And I said that SrSv did so.

vonitsanet

2007-03-22 16:44

reporter   ~0013319

Many kicks (with a limit 3 at once) at once are supported on a bahamut network i am for years now and i've not seen any problems at all with this..
IMO it's a good idea to add this one.. Anyway.. ;)

aquanight

2007-03-24 10:27

reporter   ~0013325

I could *maybe* see allowing /kick # nick1,nick2,nick3 (hardlimit at 3, or just *maybe* 5, 12 is possible too but a very big stretch (12 == max bans per /mode)), but not #chan1,#chan2,#chan3 - that just makes my head explode (the whole "kick everyone on each channel or match up one user to one channel?" deal). Considering a good majority of clients are window-based and thus make it difficult to write out commands (irssi and other similar console clients *might* make it actually possible) to affect more than one channel at once, I would say any sort of #chan1,#chan2,#chan3 (not just kick, but anywhere) is not very likely to be used.

vonitsanet

2007-04-16 13:39

reporter   ~0013465

*bumb*

Trocotronic

2007-05-19 14:44

reporter   ~0014180

So, how many targets? MAXTARGETS? MAXKICKTARGETS as well?

tabrisnet

2007-05-19 15:41

reporter   ~0014182

presumably maxmodes, or 12.
that would also mean that the max param list is 30*12+12=372.
It should not be a problem for sending back to client mode, assuming that we split the kicks when sending to client-protocol (although I believe it would be legal (RFC1459) not to).
Assuming we needed to worry about sending it back to the clients unsplit... let's see

:src KICK #chan targetlist :reason
COLON(1) + MASKLEN(106) + SPACE(1) + CHANLEN(32) + SPACE(1) + 372 = 512

Unfortunately that won't leave ANY room for a reason (and in fact has us overbudget by 2 chars)

Assuming we want to leave a budget for a reason, make it 10.

:src KICK #chan targetlist :reason
COLON(1) + MASKLEN(106) + SPACE(1) + CHANLEN(32) + SPACE(1) + 310 = 450

leaving us ~60 characters for a reason.

Shining Phoenix

2007-05-19 19:09

reporter   ~0014184

Last edited: 2007-05-19 20:48

"/mode channel,channel,channel stuff" is the other issue in this thread, don't forget that ;)

syzop

2015-08-08 16:01

administrator   ~0018591

I think it's fine as-is :)

Issue History

Date Modified Username Field Change
2005-03-05 13:23 vonitsanet New Issue
2005-03-05 13:30 aquanight Note Added: 0009435
2005-03-05 17:15 Int21h Note Added: 0009440
2005-03-05 17:58 Stealth Note Added: 0009441
2005-03-05 20:04 codemastr Note Added: 0009443
2005-03-05 23:27 aquanight Note Added: 0009444
2005-03-06 09:55 White_Magic Note Added: 0009446
2005-03-06 09:55 White_Magic Note Edited: 0009446
2005-03-06 09:56 White_Magic Note Edited: 0009446
2005-03-06 10:18 vonitsanet Note Added: 0009448
2005-03-06 10:24 Trocotronic Note Added: 0009449
2007-03-11 01:35 Shining Phoenix Note Added: 0013303
2007-03-14 01:22 tabrisnet Note Added: 0013310
2007-03-14 19:54 vonitsanet Note Added: 0013315
2007-03-19 16:30 tabrisnet Note Added: 0013318
2007-03-22 16:44 vonitsanet Note Added: 0013319
2007-03-24 10:27 aquanight Note Added: 0013325
2007-04-16 13:39 vonitsanet Note Added: 0013465
2007-04-18 05:14 stskeeps Status new => acknowledged
2007-04-19 02:38 stskeeps Relationship added has duplicate 0003258
2007-05-19 14:43 Trocotronic Status acknowledged => assigned
2007-05-19 14:43 Trocotronic Assigned To => Trocotronic
2007-05-19 14:44 Trocotronic Note Added: 0014180
2007-05-19 15:41 tabrisnet Note Added: 0014182
2007-05-19 19:09 Shining Phoenix Note Added: 0014184
2007-05-19 19:22 WolfSage Summary Many kick at once => Kicking/Changing modes for multiple channels
2007-05-19 19:22 WolfSage Description Updated
2007-05-19 20:48 Shining Phoenix Note Edited: 0014184
2007-06-11 12:50 stskeeps Assigned To Trocotronic =>
2007-06-11 12:50 stskeeps Status assigned => acknowledged
2015-08-08 16:01 syzop Note Added: 0018591
2015-08-08 16:01 syzop Status acknowledged => closed
2015-08-08 16:01 syzop Assigned To => syzop
2015-08-08 16:01 syzop Resolution open => no change required