Forums Feature Suggestions Single Channel Window

Before I explain this feature suggestion I would first like to explain its purpose. I have read many posts on these forums regarding mIRC bots and such.

Now I know that mIRC wasn't designed or intended to be a bot platform which can rival the veteran eggdrops or other bot-only IRC programs but even those anti-mIRC bot eggdrop/TCL bible thumping people have to agree that in all aspects a properly scripted mIRC bot can not be identified apart from an eggdrop or similar. One comparison that has stuck in my mind, which I personally disagree with, is trying to use a kitchen sink (mIRC) as a refrigerator (bot-only IRC program).

It can do all the same things and IMO it is much easier to do some things with it. Some of these kitchen sink bot services have been running for upwards of 3 years and have done fine from what I gather, we have been running for many months - nearly a year and everything is going great. mIRC may not be as fast depending on proc speed/ram or scripting techniques but it can do it all. Aside from all this there are only a few limitations of mIRC, most of which can be solved by rethinking the way of doing what it is you are trying to do... except one.

Since the popularity of this choice of bot is increasing according to a few articles I have recently read on top of hosting a large service of my own, the occurrence of the "Error creating Window" message has become or will soon become a significant problem for my kind. I have seen the post here regarding the "Error creating window" and I have also read posts about separate versions (bot/stripped down versions) of mIRC. I don't think that creating another flavor of mIRC would be in the best interests of our beloved developer(s) or those that script mIRC.

I would be ecstatic about a solution to the "error creating window" problem. Programming wise I understand that this is not something that mIRC or ANY other Windows application can get around because the 200 window limit as described to me and experienced by myself and others is by all means a limitation of the Windows operating system (at least 2k advanced server and XP pro which my group has personally tested on). So back to the topic of this thread... would it be possible for all of our easy operators (ison, isop, isvoice etc.) and identifiers ($comchan, $nick(#chan,N,ohvr), etc.) to still function normally if there was an feature similar to that of the single query message window that would compound all channels for that server connection into one single channel window or no channel window at all?

Maybe if there had to be a window for some of the operators and identifiers to work that the single channel window could almost work ... maybe listing the nicknames in it would have to be a little different and might as well just not be shown at all so that there could be a sort of single channel window protocol for the nicklist. I also read a post here regarding the maximum string length which I also think to be rather important even though I have managed to work around that limit in many ways. This feature would help my service and great services like ours prove to others that on top of being the most popular client, mIRC's scripting language and features are fantastically robust enough to be client/bot, which is something it's becoming increasingly popular for.

err...so u want what exactly?

mIRC to display all msgs from all channels your bot is on into 1 window?
Whats wrong with echo'ing all lines to an @ window and halting the on text events for those channels?

If i'm wrong please inform me in LESS words

I'm sorry, I thought I stated several times that the issue was "error creating window". This is caused by having too many windows open, which wouldn't be solved by echoing all the crap to any one window. It is the fact that all those windows are open that causes that error due to Windows' 200 window limit ...which I also mentioned in the post.

ah, so basically you need your bot to be on more channels than mirc supports?

I don't know of any reasons that the max amount of windows that can be opened can't be raised.
I assume if all channels msgs to 1 window was implimented, it would be like /dqwindow. but unfortunatly i can't see this being added due to the fact that the average user wouldn't use it, but thats not for me to judge.
Would be a good feature for bots none-the-less.

There is no limit of channels that mIRC supports so I'm not really sure where you are getting that from. Please read my post before replying again. The 200 window limit is an OPERATING SYSTEM limitation (again... win2k and xp pro). I simply would like to see a feature for mIRC that would allow it to function the same script wise without having to have a single channel window open for each and ever channel because running 10+ bots on one mIRC (or seperate mIRC's for some people) causes this error creating window message if the bots are on around 20 channels (or more on an unlocked server). Since I can't exactly find out why there is this limitation of Windows or ask MicroSoft to fix it, if there is a solution, I posted here in attempts to see if something could be done on the mIRC end to get around this limitation of Windows.

in that case:

my god, use an eggdrop. mIRC isn't designed for bots so therefore use something that is designed for it.

If ur gonna run 10+ bots u should expect this kinda thing.

I understood where u were coming from cuz i run an mIRC bot, but for gods sake, having that many bots on 1 mIRC is just stupid.

lol sheesh .. why don't ya leave the guy alone .. if he
wants to use mIRC for bots so what .. he's just making
a small feature suggestion, not asking for re-development.

"small feature suggestion": I agree that, if someone is trying to write (in this case a bot) in a program that would exceed the operating system limitations, then using that program to do the srcipting in is inappropriate.

mIRC scripting is supposed to enhance the IRC experience (i.e. help the hapless chatter), not become a "be-all-and-end-all" launch platform for the killer app.

In this case, the author has chosen an inappropriate platform for the project. A custom "eggdrop", Java or C++ program that can log the IRC stream (thus not opening any windows for each channel) would be the best way to go. The author can then write any "windows" into the program to view logs (or part of the stream) on demand.

The only reason this might not work is if the author wants to view all 200+ windows simultaeneously.

Given that mIRC is designed for the human chatter, taking all the channel streams and mashing them into one ( reminds me of "Ghostbusters" - don't cross the streams! ), is counter productive and (I believe) against the original concept of mIRC (I did make an earlier post about gold-plating - is it in or out of the scope of the project).

The original author (DeeperID) did note the issue of being able to distinguish between the streams within the window, this would have to be achieved by having a network and channel ID prepended to the nick identifier. Deeper ID says "It can do all the same things and IMO it is much easier to do some things with it." In this case, it cannot do all the same things, and this particular task is not "easier".

The bottom line is, if DeeperID has a specific task, then it woudl be best to find the appropriate tool to do the task.

The line just under the bottom line is that this is a feature suggestion, let's take it on its merits. However, what may appear to be a small suggestion may require some large re-development effort!

Cheers,

DK

I feel like I may be repeating myself but yes I realize that mIRC was designed to be a client and not a bot platform but other than this window amount limitation I am very pleased at what it can do in this arena. The feature suggestion about a single channel window was only made because I believe that some of the operators rely on the channel window object to evaluate statements and return values for some identifiers - I could care less if there is a channel window open as I rarely ever need to see it at all.

and for Danthemandoo: mIRC runs VERY well as a bot and I would like to continue using it as a bot since we host more than 600 channels. Currently we have 40 bots and there has been countless hours of work done on scripts we have used and on our home grown scripts. There is little time to start developing on a completely new platform for us when there are many feature requests that we must fill as well. I appreciate you taking the time to post and give me some insight into your thoughts but if you can't spend the time to carefully read my *really long* post then please refrain from spending the time to make posts that imho seem a little half assed. This is my mIRC feature request and I purposely created the post long enough to describe my feelings on it and why I think it should be a feature because aside from being able to support more than 200 channels per computer there isn't much that I have seen and eggdrop can do over a mIRC bot. Unfortunately every eggdrop advocate is either to enraged to show me something an eggdrop can do over a mIRC bot or lacks the desire to do so. I don't blame anyone for not showing me the error of my ways but if you are going to make a statement about an eggdrop vs a mIRC bot for the love of god back it up with some actual information and specifics instead of just saying they are better for the job because they are specifically made for the job. Also, please don't post links to eggdrop sites as I have undoubtably browsed them before, state your own specifics and information if you choose to do so.

Our boxes don't need to be rebooted (except for windows update.. big deal) and in our case mIRC doesn't crash. Our mIRC install/scripts are stable and secure despite everyone's idea about mIRC. In some cases it will get stuck in a loop from a script change not thought out well, which is promptly cured by fixing the script... but just like everything that is in development (yes omg eggdrops/tcl scripts!) I am positive there are problems like that.

Ultimately, if it were desired I could see having a different type of mIRC license for those who use mIRC as a bot platform for a service. Since after all, in our situation, many people are using our mIRC indirectly. That would just be another perk to supporting mIRC bot services with a feature here and there (again only if it is programatically sane). I'm not asking anyone to go out of their way for this group of mIRC users, I'm only asking if a feature like this could be added in the future .

It's possible to echo all lines said in pm's to an @ window and you could make the script close the window afterwards (this is possible but I dont remember how), this way you will have only the serverwindow and the channels opened. That's already better than let htose opened too. Next you could (but this is less user-friendly) make your bot not respond to /msg's, but to /notice's only. This way you wouldn't have to reecho those commands to a window.
Probably you thought about this before, I'm just hoping I can help you with this ;p.

Thanks for the suggestion :tongue: unfortunately, that won't help very much except to supress about 10-12 windows total. The bulk of the windows are channel windows .

whats this 200 window limit?

i just wrote this

and it made all 400 of them , am i missing something?

It must be something to do with the channel windows.. I'm guessing at this point. I have read about this 200 window limit in a couple really vague articles and it has been verified by another mIRC bot service we are friendly with as well. After joining around 200 channels on one box the "Error creating window" error pops up and no other channels can be joined. Needless to say the bots don't even know they are on those channels that they get that error when trying to join, so no events trigger for those channels... even though they are on those channels. I have tried out the snip of script you have there and I too was able to open up all 400 of those windows. I even went so far as to add l10 to open up a side list box as well (even though we have ours disabled). What are your system specs and operating system, service packs etc?

We have gotten this error when multiserving many bots AND back when they were all on seperate instances of mIRC so to me that seems to be something OS related. Most of our boxes are 2kAS or 2k server and one xp pro box. We tried xp pro to see if maybe it was an issue with 2k but turned out to display the same results.

im using a 2ks sp4, but after reading you saying it was channel windows, i uopped the count from 400 on @ windows, and it craped out between 400 and 500, at different numbers depending on what other windows i had open, I Noticed it went down 2 for each channel window i had open, so working on that logic, i can see clearly where a 200 channel window limit is appearing from.

As a stopgap to your problem, could you run multiple instances of mirc, the second one passing (i cant remeber how its done but theres a functionality to do it) all its events to the first one, the first one then just handles them.
like all the main mirc ON events call alaises to do the work, and the events being sent in from the other mirc can call the same alais, as if its a local event triggering, ok the events might need some coding correctiions, like not using $nick or $chan etc but rather passed values from the alias call...... hmmm more i write the more complexe it starts looking.

Well this error comes up regardless of how many instances of mIRC are running on the box. If we have 10 instances of mIRC each running a single bot that is on 20ish channels we will see this error on all of them at some point when they attempt to join a channel. We have mutiserved 5 to 12 bots on single instances of mIRC to reduce their foot print and to ultimately reduce the amount of windows thinking that maybe the main mIRC window takes up a window slot as well. Ultimately if we made them all socket bots this wouldn't happen of course but it seems that is almost like reinventing the wheel... and a considerable amount of script would need to be changed/updated/totally reworked to accomidate for such a drastic modification.

It isn't the processing the events that is the problem here - its simply having that many channel windows open. It seems from your test that channel windows are taking up a roughly 2 slots. How those are measured I'm not really sure I really hope that there can be something done to remedy it in the future .

"/debug @Single_Window_for_everything"

so basically, you are being lazy and expecting Khaled to make a feature that pretty much only you will ever use.

Use mIRC for a bot platform if u want, but you can't expect Khaled to go writing modifications just because you are using his program incorrectly (I.E. as a bot rather than what it actually is, an irc client).

Or just buy more computers

Why the hell do you continually bash me during this one post? This is a request... a suggestion. I never "expected" anyone to do anything. If you do not have anything productive to bring to this thread I invite you to spread your negativity and ill posts towards me elsewhere. Everyone else that has posted is very able to provide something productive so why can't you?

Again this was ONLY a request... I don't see where I have been lazy here, would you want to make a socket bot and convert 6,000 lines of script to support a socket bot?? Does not wanting to spend months and months of 24/7 time on something that tedious make me lazy? IT WAS ONLY A SUGGESTION.

How does this cause channel windows to not open or need to be opened?

also on me:*:join:#:{ window -h # } - hide it?

Danthemandoo:



Personally i'm sick of reading this, mIRC may be an IRC client but it has many features that make it more than just an IRC client.
mIRC's simple scripting language and built in support for connecting to IRC make it a good (maybe not as good as an eggdrop, but still good) choice as a bot platform.

Sephiroth:



I doubt hiding the windows would make a difference, worth a try though I guess.

DeeperID:

Have you considered using sockets for this?

oh yeah I didnt really think too hard about it, of course its not going to help, since its something to do with the underlying OS rather than mirc.

I suppose that is worth a shot. I'll give it a try and see how it goes. If so you will make quite a few people happy .

Tidy_Trax: Thanks for the support . We have considered creating a socket bot but there would be very very much to rework as these are already fully functional and in use. One of my staff has played around with a very simple socket bot template and has been able to recreate a IAL similiar identifier but that is as far as it has gone, it seems to me and to him that it would be a great deal of work. Many of the operators that we use ie. isop, ison, isvoice etc would have to be converted along with a substitute for $address and many other identifiers that we have used around the scripts frequently. However, at the same time we would like to continue to use a platform that we are fimiliar with so short of getting a feature into mIRC that resembles the topic of this thread we may have to consider that down the road . Thanks again.

I tested this theory out on this machine using DaveC's little snip to create 400ish windows I was not able to open more windows by hiding some to create others. I first created around 385 windows when I got the "error creating window" then I closed all of those, hid my channel windows then tried to create 400 again and it still stopped at 385. Closing (minimizing to tray) msn messenger allowed about 4 or 5 more windows to be created reitterating that it is an operating system issue (just incase there was still doubt). Back to the drawing board I guess

-[Edit]- After playing around with this more I found something I thought interesting... I verified it 4 times and it is quite odd. When creating these windows with -ne I was only able to open up 355 windows (used $window(0) to get amount) but if I used -dne to create the windows I was able to create 389 During this test I had 3 channel windows open. When I put those channel windows on desktop I was able to open 392 @ windows -dne. I would assume that opening up a desktop window would take up more of whatever it is we are dealing with ... I know this thread has kinda turned into a bug reporting category rather than a feature suggestion but I was wondering if anyone can verify this?