Forums Scripts & Popups CTCP VERSION Masking

yes there is a way - but it is looked down on apparently from many folks. i myself just add in an extra ctcp reply along with the standard since i wrote my own script

Tbh, i don't see any problem with the last one, so why should people look down on it? lol
It still clearly acknowledges Khaled and mIRC.

However, i do not see any point in changing the whole version reply, to something else... thats just lame.

As some1 said earlier, if you want to be able to change it by using one of the free irc clients, go ahead, their creators obviously don't care. But seemingly Khaled does care, and you should respect his decision, after-all, if he didnt create mIRC, you wouldn't have ever used it, and you wouldn't be here now.

So why not have an option to switch off the version reply but not alter it. I think most users who are an favor of CTCP masking do not want to change it to make as if they wrote the client. That is just a ridiculous assumption. They just want to hide it.

Whether its logical to you or not it has been a very popular request in the past and it has been entirely ignored. My criticism really is not so much in the fact that there is no option to hide it, nut in the fact that this issue has not even been addressed in the slightest way by the mIRC team.

As paying users i think we do have the right to make suggestions to what we want in the client. The mIRC team also has the right to say no. But the fact that nothing has been said about it makes me wonder if they care about what we want.

I did not start this topic and at the moment do not care about the CTCP replies etc, but it has come up so many times that i honestly think that something should be said by the MIRC team to stop it once and for all.

If you want an answer from Khaled you should e-mail him directly. You can't ask a question in a random forum on the boards and expect him to be scouring every one to find anything that he might be expected to answer.

Why change the reply it doesn't hurt anything even if it's shown what? You want to be elite and not let your friends know your on windows using a win 32 app and pretend your on linux? Why else would you hide the reply, I see many people all over dalnet,efnet etc.. that pretend they are on linux but yet you pop a version reply and they using nothing but mIRC.

This is not a random forum it is the official mirc forum. Also it has been brought up a TON of times before and it has been completely ignored. It is not just an oversight why it has not been addressed. Having seen previous posts and snippets of yours i am genuinely surprised and taken aback that someone of your stature would give such a meek reply.

Additionally lpfix5 this is not about whether it is sad to hide a version reply. It is about taking a popular user request seriously. To discuss the IQ level of a user who wants to mask his reply will be changing the thread of the topic.

Yes but it's the scripting forum of the mIRC boards. I'm not sure I've seen Khaled respond to a post in here in 8 years (although to be fair I don't view every one so I can't be sure). Whether he reads any or not I don't know, but asking here means there's a good chance he's simply not going to see it. It has been posted in Feature Suggestions once or twice, at least once in the last year it seems - and typically enough it got out of hand/off-topic as clearly some people feel very strongly about it one way or the other. And frankly I think that's why you probably won't get a direct reply from Khaled on any forum of these boards - from what I've seen he generally tends to avoid confrontational threads (a wise move) which is why I suggested you're better off e-mailing him if you want an answer. Of course Khaled reads the Feature Suggestions forum, so I'm sure he's seen the suggestion before and the fact that he hasn't added the support might be his answer in itself. On the other hand it might be on a todo list.

Personally I've always assumed the reason it was unblockable was on account of the number of repackaged mIRC's you can find that are bundled with scripts that try and pass off the whole thing as their creation, however not so long ago mIRC added the .exe renaming restriction which is a less intrusive means of getting credit where it's due so who knows, maybe suggesting the feature again --either on the boards or via e-mail-- might see different results.

As far as the rest of this thread goes, there's no legal reason why you can't block the version response (EULA or copyright related) so the only reasoning someone might have for not doing it is moral. I don't see any moral reason why you shouldn't block it or even change it if you want, although on the flip-side I don't see any practical reason why you'd want to. To each their own I guess.

Is it wrong to change the version reply to report another name or version? Yes, of course it is. That would be very lame. I don't really think anytone here wants to do that. I don't want to change the reply to rIRC v7.19 RoCk, I just simply want to stop it from replying at all, and for no other reason than I don't want to reply. It is sending a message that I don't want sent. This can already be done by ignoring CTCPs, but I don't want to ignore all CTCPs, yes I do use them. We should already have this option. To each their own is exactly right. I suggested a long time ago that an ignore flag be added to ignore version requests, but it went ignored. It could be in the options dialog, select it to ignore version requests, deselect it to unignore.

~ Edit ~
This all also goes for all built-in ctcp replies... version time clientinfo finger ... whatever else there is.

The problem is that a lot of people do. In fact, (this may be an assumption) it seems to me that it's actually what the OP wants to do.

I have no problem with an ignore option as well, as my posts above state. Ignoring is fine- changing is not. If Khaled is to do anything about this issue, that's what it should be. Problem is, it's probably not the ignoring part that's the "popular" request.

You're probably right, I'm sure some do want to change it. The thing is, if it were done in a way to only just not reply, then someone could just script their own reply. So it would have to ignore/discard any incoming ctcp version requests. If the user wants block mIRC's version reply, then it's only fair that ALL version requests be ignored imo.

Update: An elegant method for stopping the version reply can be found here.

I just wanted to add that not everyone using mIRC is pretending to be on Linux
I am on Linux and am using mIRC (via Wine) with a license I purchased at a full price.

Heh. Way to necro a 9 year old thread Welcome to the forums!

I guess while we're here...


Alternately...


Alternately...

Hey humans. I'm updating this thread, because the 3rd one isn't working anymore, and I assume ditto for the others. The reason is that IRCv3 @tags are now being put at the front of the strings seen by ON PARSELINE, so they no longer match. These optional tags at the beginning of the string can be identified by being a token that begins with the '@' character. So the Regex pattern needs to change by allowing for the optional presence of this string. The 1st 2 patterns also search for 'not a colon', but that's a valid character in a @tag, so it's possible that the pattern could dump you out in the middle of a tag instead of where it should be.

In addition, I found this not working at one network where it turned out that the reply to the version check was going outbound as a CNOTICE instead using the normal NOTICE keyword. I don't know if this is still happening, so I allow for it just in case.

So if you use the first 2 methods, you should modify the first 2 by inserting the string...

(?:@[^ ]+ )?

... immediately following the ^ symbol at the beginning of these patterns.

For the 3rd outbound, that stopped working once mIRC started attaching a tag like @label=1234 in front of outbound messages. This forwards whatever tag, if any, precedes the outbound version-reply, and also works with CNOTICE


* *

The other common ctcp's that people like to use to snoop at you are with TIME and FINGER. With CTCP TIME, they find out the time your pc clock is set to, which often indicates which country you are in. With CTCP FINGER, the default reply tells them the 'name' and 'email' you've input into your alt+E window, and also gives your $idle value, which tells them how recently you've done something in your client to reset that, which can be using the editbox to send a message to to a channel or query window on that network, but it can also be executing a //command in an alias which doesn't even involve sending traffic to/from the network.

You can either halt these without sending the message first, or you can send back a fake reply first. Both of these examples let you see the incoming CTCP request and shows your reply.

This one sends back an obviously wrong time, as a random time of day sometime on the 1st day of epoch:


If you're an @op that doesn't want spammers to get an idea from your clock if you're going to be there to stop them, instead of returning a random time of day, you can just have it return the same time all the time, picking a time that makes it look like you're going to be there.

This one replaces the default finger reply


This one allows the default reply to go out without halting it, but first it sets the $idle value to a fake number. But it also users a timer to reset $idle back to where it 'should be'