Forums Feature Suggestions Ignore Feature

Would it be possible to have an ignore flag implemented that would remove the user's nick from our client's nicklist (from all channels). Even though they are there, they wouldn't be seen. Ignoring to this degree may seem extreme, but some people exist you may just would rather believe didn't. This feature would take care of that nicely.

I am not a coder, nor do I script within mIRC. If this could be implemented that would be great. Cheers.

ay, I agree 110% and feel this feature would benifit everyone.

It would also be nice if one could /dline (delete lines) of text from a channel, so when you ignore someone you can erase their past aswell. This would be especially useful for people who flood or say nasty things. /clear is not a valid option.

I say we should have complete control over all windows, not just custom windows.

- Raccoon

id love the ability to add delete and even change nicks in nicklist along with being able to change the prefixs used to apply to nicks in channels and windows as well. id love to be able to add small icons inplace of prefixes, id love to be able to make in my mirc (not globally just locally) that when i whois ppl from say argentina , im able to add alil argentina flag, and so on and so fourth, there are thousands of things that could be used by adding this ability, even the ability to add your own smileis that u can see just locally not globally. i dont care if ppl see my : ) as a or whatnot i just wanna be able to see it myself. i know its not really a good example but really just being able to replace certain text with images would make things alot nicer to theme. having complete control over the nicklist would be another, id like to also be able to adjust its hieght not just wits width. id like to be able to add small buttons below it for use in quick shortcuts, yes i know u can create your own /alias stuff but dammit i bought a mouse to clickity click with LoL. Anyhow thats all my 2 cents. change please? LoL

People, from what I can tell, there's only so damn much you can do with the window types that mIRC uses. Correct me if I'm wrong, but doing such things would require a complete re-write of the back end and force unnecessary text processing on EVERY line, all so you can have a smiley of some sorts.

It's completely and utterly pointless for IRC clients to do this, it's not AOL chat.

This is like asking Microsoft to implement smiley faces into telnet.......

As for ignoring people entirely? Just ban them from the channel if you don't want them around? What does it matter that their nick is in your nicklist, some type of love affair with this person gone wrong?

The fact is, whether or not you see it in the nicklist doesn't necessarily mean that person isn't there, and that person is now wasting extra cpu cycles on your computer because mIRC has to actually make an extra statement for if that person's hostname shows up to remove them.

The data that the person has is still coming through your client anyway. I suggest using the /silence function that some servers implement.

Raccoon: Though I agree with you for conformity's sake to make all windows behave similarly, where would this benefit? Not to shoot the idea down, but this would mean that now all window processing is now done outside of the compiler and in runtime script code (slow). I would personally prefer channel windows, status windows, and query windows, pretty much main functions of mIRC, to operate as quickly as possible.

i made other suggestions besides smileys i think u should read alil better, and mirc ALREADY checkes everything with on TEXT events. now what would need to be added to modify that extra work u think mirc is doing?? now i might agree with u that mirc windows displays may need a complete rewrite. but then again, how is it custom windows created in mirc are able to use images in them? i think ppl like u just like to comment about something without thinking them thru coherently. yes mirc is text based chat program, im not asking that i want to add smiles to my text, im asking for basically mirc to be able to support images in text not just smiles read the whole post next time. im also asking it be possible in the nicklist to be modifyable. why everytime someone suggests something that is completely in the scope of possibility do u ppl act so narrow minded as to think its not what u want, hell ive seen several things added i dont want and wont use but i have to live with that dont i?

First:

Checking with on text events and completely re-displaying how text is displayed into images is completely different. ON TEXT is looking for a matching event, but you're talking something completely different.

Now, where are we going with this pictures in text thing? You mean replace LOL with a cutesy little image that says "LOL!" AOL-like? Eh, yeaaaaaaaaaaaaaaah. Okay. So then it comes to the point where people start begging "OH OH NOW THAT MIRC SUPPORTS PICTURES IN TEXT, I WANT TO BE ABLE TO SEND THAT PICTURE TO OTHER PEOPLE!". Then we'll get back into this same debate with such people trying to explain to them that fundamentally this would NEVER work outside of a DCC. Of course, these are the same people who have no idea what the concept of how to use DCC anyways.

Not to burst your bubble, but there should be a level of uniformity between IRC clients and servers. If the server doesn't support pictures going through it, then the IRC client really doesn't need to display pictures in text.

Find me any other Windows-based IRC client that handles the text this way and get back to me on it.

kvirc, klient,and several other irc clients support this format infact go to the kvirc website and veiw screen shots, there got back to ya, touchee. i think u better AGAIN read what i said and understand what GLOBALLY and LOCALLY mean. and yes all it needs is to be done thru ON TEXT and just at most add image support identifiers for replacement. i doubt highly any window rewrite would even be needed, as with dll i can obtain icons in the nicklist already so really your trying to shoot me down for what reason? ive killed all ur arguements let it go, u lost this one.

So you can do it with a DLL, why complain over forcing this feature into mIRC?

This is why Khaled added DLL support, folks. So less and less time has to be spent requesting completely useless(i.e. non-functional based) features to the client.

I say take advantage of it.

i said in the nicklist, not in the chat windows, again your not reading. and i gave uses that id like to use it for, so what if u wouldnt use it for anything, your completely free NOT to use an option that mirc supports( or could support) im sure there are several useless functions u dont use already added into mirc. so why deprive others of it because u dont like it? Ya know back before mirc became multi server several ppl argued they wouldnt use it, now if it were to be taken away alot would complain. you just have no vision.

Actually, there is not a function in mIRC's scripting that I don't believe I've ever not used, except COM objects and DDE....simply because at this point in time I never bothered about using them.

Who argued multi-server would be a useless function? I didn't meet anyone on IRC ever that didn't want a multi-server feature to mIRC, this coming especially someone like myself who makes VERY HEAVY use of it. There are a few things I'd like to add, example, on *:text:<text>:<channel>:<network>:{ }, but otherwise it works very well.....with the exception of a bit of cpu usage concerns that I made in the bug reports section.

Again, this is a completely aesthetic option to mIRC that you're requesting, i.e. using icons and images to represent text, and it's really not a functional feature, so I say stick with the DLL support. That's why it exists.

If you're talking about speed, the text sent to these windows are already processed through On TEXT and other channel events. All I'm asking is to UNLOCK the commands /aline and /dline et al, which presently refuse to work in #channel windows. Enabling these on-demand commands should have zero effect on the speed that text and events are written to it.

- Raccoon

Actually Raccoon, to specify, my comments about using extra cpu time to process lines was in reference to the comments about wanting to use smilies and images in the text.

Aline and Dline could be useful, but then again text scrolls by so quickly in the window, that you'd end up having to check for the line # on every time

Unless of course you are specifically meaning just the nicklist...

Eh, it might have some use

check hoe many options have been added to mirc just for the sake of asthetic appeal, IE background images and ability to change backgrounds and icon images, removing toolbars and other things like that. now your telling someone who would like to see this type of stuff enhanced and added more to asking unreasonable requests? i dont think thats the case, and i dont think u or anyone else has any right to say its not acceptable to ask this stuff. im not asking to any irc protocal changes, just even more scripting ability to be able to enhance the over all appearance to mirc, im sorry u feel thats not something that mirc should be able to have is more scripting support for advanced themes and such, and along with implementing what im asking it would also cover other ppls request for the ability to see smiles, so its killing 2 birds with one stone? how is this a bad thing?

actually i agree with demon on this. "theres only so much a window can do" actually mirc has barely touched what a window can do. even picwins are very limited in alot of aspects. if someone were to make a list of all the things that arent a MUST in mIRC that list would grow in heaps and bounds by every version. in fact what do you really need? a way to connect to a network a window to display text in and an edit box to send it. it works but what kind of experience would the user get from it? as for the nicklist it wouldnt take alot of processor power to do. i have a dll that does it quite nicely. having more control over the nicklist built in would be a great improvement. as for emoticons i can take it or leave it. the point here is none of it would be sent to the server. all the server gets is the plain text form mirc translates it (if the option is enabled). this will indeed take more process power to do but not ridiculously so. for those of you who join mp3 channels and others where text is flying by at 1000 lines per second well you may wish to disable this option.

point is new features is the idea of progress. we could all be using windows 1.0 still as well but we dont.

With all do respect, Demon, I would never want to see full flexibility of the appearance of mIRC with a runtime compiled script. Such things become ridiculous and would probably end up a complete and ungodly mess for the simple reason that it was NOT coded for this beforehand.

Just take a look at why mIRC doesn't support unicode and probably won't. Ask the guys at Cerulean Studios about this......

I seriously doubt it's more than just a 'simple request' to do it internally. If your DLLs provide the functionality, then that's cool, but I doubt it could be done internally with 'ease'.

A lot of the options added for the sake of appeal were added prior to DLL support. This was one of the reasons for DLL support I would imagine, at least, one of the many reasons.

There should generally be no need to request many more features for mIRC in terms of aesthetic appeal that cannot be done with some form of DLL now.

Now with that said, just to clear something up, i would imagine there couldn't be a dline -l or aline -l to a channel window, otherwise it would break mIRC's nicklist handling. I would imagine it doesn't keep an internal buffer of users in a channel aside from reading from the nicklist? Who knows, but that's how I would do it....since normally you shouldn't change that anyway?

<b>As for ignoring people entirely? Just ban them from the channel if you don't want them around? What does it matter that their nick is in your nicklist, some type of love affair with this person gone wrong?</b>

Okay, this thread has gooten way off topic. If I do not have ban privileges (i.e. I am not an op), I want to COMPLETELY ignore someone's existence there is nothing that I can do. Ignoreing there presecnce on my nicklist would accomplish this. I don't care if they were in channel or not. Because they are there bothers me, or anyone else with the same concern. There is nothing we can do because we are not op'd on the channel(s) they are on. The only thing we'd be able to do is to ignore them scompletely (and this includes nicklist).

Please include this in the next release. I would *GREATLY* appreciate this addition to mIRC. Thank You!

ok since uve addressed this in a 2 part deal ill try to cover it all in one place. now uve stated that it is your beleif that the reason mirc doesnt support stuff is because it wasnt coded for it beforehand, and uve used the example of unicode support, well im sorry to shoot your idea down yet again on that but, khaled himself stated he will infact be adding this to mirc via UTF-8, im not making this up it is a fact khaled himself stated it will be added at some point in the near future. now with that said, whats to stop khaled from adding anything else? answer is nothing. now lets try to cover your second post.

DLL support, ok yes u may have a point asthetic changes where mostly aded to mirc before dll support, ok then how many times has khaled changed dialogs look and appearance since dll support? ive noticed it 3 times in the recent past. and just in 6.1 versions .txt hes added undated jpg support(Asthetics). so again the dll idea isnt really true, infact isnt almost all of the additions and fixes to mirc in someway related to mirc appearance or operation, and really as mirc was back in version 3 it had all the functionality and visual appearance it really need just to be a chat client? yet its still developed, ironic isnt it. ill leave u with this, if mirc does not grow as a client then it will surely die, so additions and suggestions from its users should be something it atleast tries to implement, this is the best way i can think of to make the best of both worlds , where users want emoticons and others dont, its then turned scriptable and even highly configurable, basically what mirc has always aimed to be. again how am i wrong?

The problem with removing a nick from the nicklist because you don't want to see it is a mute one imho. Don't look at him. If you /ignore a user, for all reasons and purposes, the user no longer exists to you. I don't see an additional benefit in removing his nick from the list.

That said, the nicklist displays the nicks that are in the channel. To not make it display all of them defeats the entire purpose of having one to begin with.

I also believe (personal opinion !!! ) that if you don't even wanna see a user's nick being the the channel, then
a] apparantly you are the one having issues, not the user in question
b] you don't care if the user is there, but apparantly you care enough about the user to make sure whether he is in the channel or not.

Just stop thinking about the user, don't pay attention to the nicklist.

Find a new channel to hang out in if certain people are that annoying

D3m0n:

User consensus taken from a multitude of IRC channels and networks is this. mIRC should not display smileys by default for any reason. It shouldn't even have support for them. Otherwise everyone's going to move to another client

Adding internal JPG support is one of those 'makes sense' functions considering BMP in raw format is just so huge. JPG is the absolute standard in image compression on the internet. This isn't an aesthetic appeal, this is just one of those "it makes sense to have it" ideas.

Now if people started begging for splay to support ogg vorbis or AAC or any other format, I'd complain about that, too mp3 makes sense for functionality again for the same reason jpg > bmp.

OGG Vorbis is already supported, it just requires that you've installed the correct add-in for media player.

I support his/her suggestion. The client shouldn't judge your reasons for doing such a thing (not wanting to even see a nickname in any way), so (s)he thought it would be nice if it just offered the option. Which you, who doesn't support it, would choose to NOT USE IT if it's added.

Again, I say: you can't argue about the personal usefullness/value of this and that suggestions. It varies. You're not entitled to say which usage of any feature is wrong when it's exactly what a person wants and suggests.
Personal opinions about smilies, for example, don't count at the end. Principally since it would obviously be an OPTIONAL thing. No one would quit mIRC because of an OPTIONAL thing.
As for the ignore suggestion, "Why would you use this, some type of love affair?", damn, that's simply rude. Again, you show no respect at all.

If you managed to discuss POLITELY why should anything be added, rather than diminishing the suggestion with PEJORATIVE usage examples, then I'd say please go ahead. But you're not doing so.
Khaled already filters the suggestions himself. It's simple as that. Please stop trying to do this job. You'd fail with such rudeness, anyway.

Adding the ability to remove a person from the nicklist would then have to move on to remove that person from /who responses, remove that person for the IAL, remove the person from /names, etc.

What about /whois?

Then everything on IRC is based on ADDRESSES (I'm not sure if the starter of this topic is aware of that or not at this point), so you'd then have to filter out addresses. There is no perfect address filter unless this person is on a completely static host with a single ident. Once the IP changes, or the nick changes, or the ident changes, this person is back on your radar. *OR* you end up blocking other people off of the map *@*.catonv01.md.comcast.net would block the ENTIRE Catonsville, Maryland area.

All because a person has some beef with a person and doesn't see them on the nicklist? If this person caused so much trouble somewhere, you shouldn't have a problem contacting an operator of the channel to deal with the person accordingly.

That is unless it's a channel where it really doesn't matter who you are because it's run by a large group of operators?


Here's my suggestion: IT'S ONLY IRC! Get over it.

ok adding of jpg support was not added for asthetics?
please read the dictionary definition of asthetics and then find out exactly what a jpg is. actually nm ill simplify it all for u. asthetics is in a nutshell visually apealing to the eye, now a .jpg is an image file NOT A TEXT FILE. hence it was added for asthetics, and even beyond that, a bpm is also an IMAGE FILE. you actually should read your post and see how little sense u actually make? i dont care about your general concenses poll youve done, look at the slew of new irc clients that do support all this im suggesting?. and tell me that these other clients just added it just because. there is obviously a call or need or even demand for it, search the forums here and u can see how many times just the emoticons support has been asked for, there is a call for it and your simpley speaking out of your own opinion, which you are intitled to, but dont go tossing in saying youve researched it and there absolutly is not need for it and its useless, just because you and 5 of your buddies dont want it doesnt mean someone else doesnt. thats just plain being ignorant.infact im just done debating this with you. khaled can infact make his own judgement without the help or support of you and yur 5 buddies poll u done. ppl that stand in the way of progress usually get run over.

BMP support can be functional for picture windows, though picture windows haven't really been used in very many scripts, though I'm sure that they were put there at some point to be some sort of 'whiteboard' feature, maybe, maybe not. They can also be used as splash screens.

Since BMP support was already there, given the general size of a BMP and how well it can be compressed to a JPG (which is practically the internet standard) with little noticeable reduction in quality, generally speaking it made a whole lot of sense to use JPGs. The support for BMP (like many other functions that are superceded) is left there as to not break as much in terms of older scripts.

Btw, what new IRC clients support smileys?

Klient nor HydraIRC support them. Those are fairly new, and have a long way to go, and are far more 'updated' than mIRC in terms of how it works.

Please, point some out to me.

All what? All you said have anything to do with the suggested feature. It's only /ignore with the ability of not SEEING the nick in the NICKLIST. This doesn't mean mIRC would ignore it in the IAL, or that it should not /whois it. I don't get how could you think of these arguments, since /ignore doesn't do anything like that anyway. All these situations would stay the same. What about the pointless addresses argument? The user will deal with the format (s)he uses, just like we currently do. Now I repeat, all what? All nothing. It's a damn minor change which you could just not use, like I don't use a lot of things already.

About judging reasons for using this feature? I'd say get over it, it's only being suggested. No one here must explain why would it be used, and you're not entitled to judge its usage this way you're doing.

Well it is possible that someone may have an offensive or rude nickname. If you have children around you, You may not want them to see it. Also you personally might be offended by it. If there is no operator present, You would have to leave. An answer to this would be to have the nick removed from the list. Just because someone would want this, Doesn't mean they "are the one with issues", at all.

I would suggest using /cline to set the offending nickname the same color as your listbox, as a temporary workaround.

Also, if you could apply mIRC's full library of window listbox manipulating commands, to a channel window, it could be very useful to scripters. I am scripter and I know I would find uses for it.

Why are you banging on about smilies so much. They were only mentioned as one possible use of image support. Yet you have singled it out. There are indeed other clients that support emoticons - And the point is that there existence shoots down your arguement of technical barriers.

mIRC isn't just your IRC client. Lot's of people have requested this, And It would not affect you if it was added, As no doubt it would be disabled by default.

What clients?

(General Reply): Can we talk about the /ignore feature?

* Raccoon gnaws on your mouse if you think about replying.

check the rest of my posts and find the small list i gave, and really i said from the begining smilies was another example, not THE example i gave, im done debating it with you as i can see that u can not read. and your right raccoon lets getback on the original topic of adding the abikity to control mirc nicklist more. yes i agree it should be added.

And then what if someone mentioned that guys nick? The ignore feature would have to be expanded to automatically filter out all lines that contain the nick. And suddenly you're listening in on half a conversation. And the same with other bad words you define, mIRC would have to filter those out too. The chatwindow would become a mess, with you only getting half the text spoken. You would no longer be able to actually chat, because it's flatout stupid to try to interact with other people when you only see half the text spoken. Kinda defeats the entire purpose.

PS: this was not the original subject of the thread, agreed.

PPS: the proposal of using /ignore as some kind of bad word filter sucks. This for the following reasons:
* The average child will be a lot better with computers than the average parent (remember - WE may know what we are doing, 99% of the mIRC users does not)
* What about different languages? Some bad words in one language are perfectly normal words in another.
* What about words with a double meaning? Suppose you filter out a word like 'dick'. What of the child who wants to talk to his friend called Dick? What about the word bitch, if a child is having an online discussion about a female dog?
* I also feel it is not mIRC's task to "protect" children against the big bad world. I think in cases like this, some official parties are becoming way too overprotective.

The only solution is: if you don't want your kids exposed to bad words, then keep them locked in their room. Besides, they'll pick up moree bad stuff in schools than on IRC. You may be able to control your what your kids do at home, but you cannot control who they talk to outside your house, and you cannot control what the kids they talk to do at their homes.

When you allow kids on a medium such as mIRC, you must expect hem to be exposed to some bad stuff.

The whole point of ignoring someone is to only get half of the conversation. This much is inevitable no matter what you use the /ignore feature for. You /ignore someone, part of the conversation goes bye-bye.

PS. Many people censor conversation to prevent it from reaching their own eyes. Let the kids immerse themselves in a deluge of sluge.

The only related suggests I see in this thread are those I and the original poster made: The ability to /ignore someone and erase their past via /dline and /aline commands in both the nicklist and text portions of a channel.

This is already possible today with mIRC's current logic and would have zero impact on mIRC's general performance if it were allowed. As far as I can tell, /dline and /aline were simply locked from being used in channel windows a long time ago, for what reason I do not know. I can only gander that $nick($chan,...) gathers its data from the nicklist and removing names would effect that function... so /dline was prohibited from being used in a channel's nicklist and susequently its text portion too.

All I ask is for this lock to be removed.

- Raccoon

It shouldn't even have support for them. Otherwise everyone's going to move to another client

I wouldn't change to another programme if mIRC started to support smileys. What I 'might' do is turn the feature off at times. I do note that smileys do not lag any other programme that supports them so I fail to see why mIRC would be disadvantaged. At any rate computers are so powerful now that any difference would be very hard to spot.

Your whole assertion about people's preferences is completely wrong.