Forums mIRC Help problem connecting to more than 180 channels

im making a bot in mirc and i need the bot to connect to a lot more than 180 channels. only problem is once it gets to about 180 mirc becomes unresponsive as well as making my computer unresponsive.

i have tried another irc client(very similar to mirc) that allowed me to connect to over 1000 channels without any problems at all(even with chat logging turned on), however this particular client doesnt support any form of scripting yet(or i haven't figured it out yet).

computer specs are:
amd turion 64 x2 1.6ghz
2GB ddr2 667 ram

so my question is, does anyone know of a way to make mirc connect to more channels?

No offense intended but you do realise mirc is a chat application right? If you want to run a bot that has to connect to hundreds of channels, you really need to look at other methods, like C, C++, Perl, python, and of course eggdrop/windrop if you insist running windows. Also what irc network allows a user to join all those channels?
However if you really insist on using mirc/windows for this folly then look at spending some money and upgrade your memory/cpu or whole system.
Best of luck

I'm doubting that 1000 channels claim. Which client is this?

mIRC is not made with humans in minds, not bots. As such, most of the focus in implementing new features is on usability, not efficiency. The drawback is that the scripting engine is SLOW, so while you can make simple bots, it's likely to hit a limit once you start using it in extreme scenarios. If you need a program that is MADE for bots, you should be looking into eggdrops, mIRC won't help you. I'm not even going to bother asking your intentions for joining thousands of channels at once...

Windrop download page. Easiest way to manage channels and still not pay for a shell provider to host your bot.

no disrespect to windrop users but try to afford an eggdrop shell if you can. The differences are truly amazing plus cygwin isnt the most stable of code emulators to run windrops.
Just my 2 cents

cygwin isn't stable?

It might not have the 20 years linux has had, but I've never actually had problems with cygwin itself, maybe just the quality of the ports. I personally cant imagine any problems with using eggdrop under cygwin. There are docs on how to compile it on eggheads.

Yes I know this but to be honest you cant compare a windrop and an eggdrop, ok there will be some that say they are one and the same, well yes to a point however for the sake of an average of 3 dollars US you get a bot you dont have to leave your home computer on. Or if you want to try the free route be my guest and go windrop. I prefer linux period so I vote eggdrop on a proper shell

I used windrops several years before being able to afford a decent shell account (free ones and $3 ones leave quite a bit to be desired). I have not found a script for eggdrops that could not be made to run on windrops with little or no problems. As for cygwin, I haven't experienced a noticable difference.

Your issue is likely related to this recent report, which means there's no way to use mIRC for your *whatever* intentions so far. Luckily for you there are plenty of alternatives - 'cause you apparently (and in contrast to the linked thread's OP) don't want to use mIRC as the chat application it's supposed to be.

You sort of missed the point.. you can run *eggdrop*.. the real eggdrop, on windows under cygwin. Stability should be equivalent assuming your *connection* is equally stable as a shell, that's the only real issue. This isn't a Windows vs. Linux thing, though-- the platform is irrelevant, eggdrop is ported to windows.

thats with using HydraIRC

the issue is not with my ram or cpu, even while connected to over 175 channels, mirc only uses about 15% cpu and no more than 30mb ram

i would use eggdrop, but for some reason, eggdrop will not connect properly to this server (irc.justin.tv, requires a password)


im looking into a php alternative, just to see how it works out

I've played around with php irc bots before and I must say that I rather advice against it if you want to use that many channels etc... it's not the fastest and most stable implementation possible in my eyes.