Forums Bug Reports /ignore

I just noticed that /ignore -t only ignore ctcps and not ctcp replys...

Maybe not a bug, but I think you should add another optinon for ignoring ctcp replys to

Yeah, as far as I know this is not a bug. It might be nice to have an option to ignore CTCP replies. Although, you can use:

on *:CTCPREPLY:*:{ halt }

Although, if you CTCP someone why would you not want to receive the reply?

Regards,

maybe becouse people like to send fake replys.. :P?

and if somebody are flooding you, it will be nice to be able to block all of the ctcp's, including the replyes..

Surely if someone else sends *you* a CTCP you do not see *their* CTCP reply, or your own?

Regards,

actually, the ctcp ignore switch should technically work for replies since it IS a ctcp event shouldnt it?? I mean isnt a ctcpreply still a ctcp event? If it's NOT a ctcp event, then an ignore switch should be made for it.

you got my point

Good point landon, although I don't know if CTCPREPLY is an event in it's own right?

I still do not understand the point of an ignore for CTCP replies in either case though - you surely would not send a CTCP to someone if you did not intend to get a reply? The only case I can think of off the top of my head is if you're trying to abuse someone with CTCP flooding. I'm not suggesting for a second this is what you want to do, just a way it could be abused.

Regards,

yeah, that's the ONLY thing I can see it doing (flooding), but I think this is a valid issue if not a bug and worth my weighing in on The Replies are another event, but they're ctcpreply events so even if they're not official ctcp events, they should be ignorable (among other things not related to this thread). As for me, I have a very good ignore system in place for ctcps of all kinds and REPLIES are worked in such a way that if they dont match a certain level, shut all ctcp replies off for "X" amount of time (per incursion) which effectively kills flooding. I think it'd be easier to jsut add ctcpreply events into the CTCP ignore vs adding a new switch and be done with it This way a ctcp ignore will ignore ALL ctcps based off of entry

noooo!! Not include ctcp replys.. add a new swicht for it...
Many people use /ignore -t to ignore all ctcp's they get..
and some of them do want to be abel to get ctcp replys..

if there was added a new switch, everyody would be happy

Well, a new switch could be used. That wouldnt bother me nearly as much as not being able to /ignore ctcp replies (just because it doesnt ignore all ctcps yet lol). I think the original creator of this thread should post to the feature suggestion board and reference this thread (if it turns out this is not a bug but simply the way it works) so we can get this valuable option on paper (as it were)

Maybe the reason ctcp replies aren't ignored with /ignore -t is that they are NOTICE messages, not PRIVMSG, and according to the RFC, an automated client (bot) must not respond to NOTICEs. So, if client doesn't respond to notices (which means ctcpreplies too), there really isn't any problem. Besides, /ignore doesn't stop the messages from coming, it just hides them. So letting ctcpreplies pass through wouldn't affect a client in any different way than ignoring them.

The only difference is the display of the ctcpreply messages, of course. This (and only this) is where a /ignore switch for ctcpreplies would come in handy, although this is a minor issue because /ignore -n already ignores ctcpreplies. Of course, there's always the scripted solution:

In fact what is more annoying for me is that ignoring "notice" will also ignore CTCPREPLIES (they are in fact notice). It would be better if mirc could differentiate CTCPREPLIES from regular NOTICES.