mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#223435 24/07/10 01:52 PM
Joined: Nov 2008
Posts: 3
V
Self-satisified door
OP Offline
Self-satisified door
V
Joined: Nov 2008
Posts: 3
Where i can get free channel protecting bots for my new channel

Vickygautam #223437 24/07/10 02:10 PM
Joined: Nov 2009
Posts: 81
V
Babel fish
Offline
Babel fish
V
Joined: Nov 2009
Posts: 81
hawkee.com
mircscripts.org

Voglea #224486 12/08/10 01:11 AM
Joined: Aug 2010
Posts: 19
M
Pikka bird
Offline
Pikka bird
M
Joined: Aug 2010
Posts: 19
You can also get eggdrop is more Protect...


~Manit~
Manit #224502 12/08/10 09:06 AM
Joined: Feb 2003
Posts: 3,432
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
Originally Posted By: Manit
You can also get eggdrop is more Protect...

More protection yes, but free no, not if you don't have your own *nix computer running.. smile

But you can try windrop and see if thats what u looking for..


if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
sparta #224505 12/08/10 11:35 AM
Joined: Jan 2009
Posts: 116
Vogon poet
Offline
Vogon poet
Joined: Jan 2009
Posts: 116
Eggdrop is also, in my opinion, a bit... crap. It probably could be good, but it seems that most people fail to properly configure them, turning them into more of an annoyance than help ;_)

I should probably eventually release my MSL bot framework, although it's not really über-newbie-friendly..


http://zowb.net

/server -m irc.p2p-network.net -j #zomgwtfbbq
(ssl on port 6697 and 7000)
Knoeki #224512 12/08/10 01:15 PM
Joined: Nov 2006
Posts: 1,559
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
For a single channel it should be sufficient, but for bots on a *large* scale, a notable downside of mIRC/MSL is it's single-theadedness.
Imho truly "reliable" protection requires a dedicated system in any way (be it nix or win), and if the IRC network provides services and modes (like UnrealIRCs +f), they're among the most stable "free channel protecting bots" you can get.

Horstl #224520 12/08/10 06:15 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
What does "single-threadedness" have to do with anything? The bottleneck is NOT your CPU, it's the connection.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #224521 12/08/10 06:19 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
That statement implies you know what the bot does.

A bot that reads from a file would benefit quite a lot from multithreading, as would one that does something with COM objects.

hixxy #224533 12/08/10 10:29 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
That statement implies that you have no idea how multithreading can improve performance. A badly designed single-threaded program is going to be slower than a badly designed multi-threaded one, sure, but no robust bot designed for high traffic would "read from a file" at every request-- it would cache in memory, index lookups, or implement a whole host of other performance optimizations before wasting time implementing multi-threaded code.

Making a blanket statement that mIRC is bad because it is single-threaded is really uninformed. Multithreaded applications don't magically perform better, it depends very heavily on the use case, and performance does not increase throughout the application (it's usually limited to a very small portion of the runtime). Most of the time, the conclusion can only be drawn by actual benchmarks. That said, given the bottleneck of a TCP connection, the relatively low amount of data flowing through an IRC socket (on the order of ~100kb/s maximum), and the other things you can do to make a script run faster (caching, indexing, DLLs), I really doubt many scripts are really in need of multi-threading.

It should also be pointed out that eggdrops aren't multi-threaded as far as I know, so claiming that eggdrops are better because "mIRC is single-threaded" is inherently bogus. In fact, Tcl, the scripting language that eggdrop uses, is known for recommending scripters use the single-threaded event loop rather than threads, whenever possible.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #224554 13/08/10 01:29 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Even with caching, a cache is only suitable until the file changes, at which point it would need to be re-cached. If a file is constantly changing then there is little benefit to caching.

Just as a badly designed multi-threaded program would run more efficiently than a badly designed single-threaded program, a well designed multi-threaded program would run more efficiently than a well designed single-threaded program (especially with dual, tri, quad, hexacore computers being the standard these days). It stands to reason that a bot that can perform two tasks at once will perform faster than a bot that can perform only one task at a time, no matter how well coded the single task one is.

Imagine a trivia bot running in a large channel that has !commands for top 10 leaderboards and whatnot. Now assume that the cache of this leaderboard is not up to date and the bot's stats file needs to be reprocessed. Let's assume it has stats for 10,000 players and takes a while to process. Whilst somebody is asking for the top 10, another player wants a hint for the current round. The player who wants the hint would have to wait until the bot has done processing the file before they get their hint, at which point the player might run out of time for that round. That's just one example.

As for your second and third paragraphs, I don't think they were meant for me as I never said mIRC was bad nor did I mention eggdrops :P

hixxy #224572 14/08/10 02:21 AM
Joined: Jan 2009
Posts: 116
Vogon poet
Offline
Vogon poet
Joined: Jan 2009
Posts: 116
There's mThreads.dll, which allows you to achieve threading with mIRC. I can't vow for it's stability though, as I never used it.

My bot is mIRC based. It's in 51 channels across 8 networks, it runs on a 434MHz celeron with 384MB of RAM, and it works damn near flawless other than the CPU being a slight issue with larger scripts.


http://zowb.net

/server -m irc.p2p-network.net -j #zomgwtfbbq
(ssl on port 6697 and 7000)
hixxy #224581 14/08/10 07:14 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Knoeki's reply basically summarizes my point.

Yes, a well designed multi-threaded app will be more efficient than a single threaded app. That's not the question. The question is whether that efficiency is necessary. Most of the time it's not. If you want to show that it is, benchmark it-- theory doesn't really help.

Your example has a few problems. First, this is not how you implement caching. If a cache was "out of date" (hard to happen, since you would cache on-write and on-read), you still wouldn't reprocess the full "file", you would just invalidate the cache and cache on the next read. We agreed that we'd be talking about "well designed" systems here-- therefore, you would never process the full "file" -- again, there's a good chance you're even using an indexed database here . In fact, 10,000 records is handled extremely easily with MySQL or SQLite; so easily that a dataset of this size is really considered "small". These databases can handle queries over millions of records in a few milliseconds.

More importantly, there are algorithms to keep track of the "top 10" users in real time with O(1) complexity. If we were specifically talking about your scenario of accessing the top 10, this would be as simple as updating the list of 10 users whenever a round ended (offloading the "heavy" data processing after a round and therefore not delaying requests to answer). It would be nothing more than /msg %nick %trivia.top10, and updating %trivia.top10 with 10 nicknames after the round.

But even if this was any arbitrary query over a dataset (which you could still optimize for in the same manner as above), and even if you decided to badly design your system to reparse the index *during* a round (which you wouldn't do), we're still talking about an unlikely situation. It's easier to avoid this than to add the multithreading complexity in handling all that locking. Writing mutlithreaded code is really hard, it adds a lot of weird edge cases and a whole set of new problems. For instance, let's say you had that multithreaded code and 2 people asked for the top 10 list at once? You'd have to make sure you put a mutex around your file reprocessing, otherwise you'd end up corrupting your cache. Do you really need to add all that complexity instead of just updating your top 10 cache between rounds?

Like I said, multithreaded code is not useless, but it should be taken on a case by case basis and should really be the last resort. And at the level of a scripting language, you rarely need the last resort.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #224649 15/08/10 07:52 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
How can you benchmark it? The benefit of multithreading is the ability to do more than one thing at a time is it not? Like the ability to update a progress bar in a dialog whilst in the middle of a while loop? Like the ability to be able to carry on using mIRC whilst it is in the middle of a huge $findfile() command?

The benefits of multi threading are so plainly obvious that I'm not sure benchmarks are actually necessary.

hixxy #224650 15/08/10 08:00 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
How? By timing the duration of an operation. Multi-threading has nothing to do with the ability to time code. Time still exists in a multi-threaded world.

Plainly obvious? Again, it sounds like you have little experience writing actual multi-threaded code. Slapping on a bunch of threads does not necessarily yield a significantly faster application. It depends heavily on *how* you use the threads, and *why*. The implementation might make it faster by 20%, or it might just make it faster by 1%, or maybe 0.005%. The latter two being insignificant values and probably not worth the effort, by the way. Heck, it might even be slower. Therefore, yes, benchmarks are necessary.

Frankly, anytime anyone says "benchmarks aren't necessary to prove X is faster than Y", there's something wrong with their argument. It would be similar to the fallacy of saying: "quicksort is obviously better than bubblesort because it's O(nlogn), I don't need to prove it with benchmarks".


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #224651 15/08/10 08:07 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
You're right, I have never written multithreaded code and am speaking as a user, not a programmer. I think the not locking up part is more important than the speed benefits. Being able to still browse the menus, options dialogs etc, whilst mIRC is performing a loop/findfile/other blocking command is very useful.

hixxy #224652 15/08/10 08:21 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
mThreads.dll, if it works correctly, should be able to do this. There are also some COM hacks to be able to run in a "thread" (similar to the "sleep" script floating around). You can also offload work to a separate process, depending on what you're doing. But I don't really think this has to do with the scripting engine anymore. The UI could perhaps be running in a separate thread from the script layer, that's a valid concern regarding overall UI responsiveness, but the script layer itself should still be single-threaded. The UI should not really have anything to do with the performance of a (dedicated) bot.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #224654 15/08/10 08:58 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
I still think that parts of the script engine should run in separate threads. mIRC being able to process events whilst it is running a lengthy while loop/$findfile command would be infinitely useful.

As I said though, I'm not a programmer (have dabbled but never went into anything as in-depth as threading) so I'm not sure how difficult this would be to implement or whether it's "safe" to do so.

hixxy #224656 15/08/10 09:37 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It's not safe at all. It incurs a huge burden on the scripter. When you lose synchronous deterministic behaviour you gain the complexity of having to manually synchronize everything yourself. The beauty of mIRC is its simplicity.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #224662 15/08/10 10:50 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
I'm talking about mIRC doing this automatically and behind the scenes, not giving the scripter the ability to create and manipulate threads :P

Vickygautam #225229 28/08/10 09:01 PM
Joined: Jul 2006
Posts: 242
H
Fjord artisan
Offline
Fjord artisan
H
Joined: Jul 2006
Posts: 242
Seems to be lots of requests for this sort of thing. We used Pbot, and it sorted our server. http://mirc.net/projects.php?go=1218035463



Newbie
Page 1 of 2 1 2

Link Copied to Clipboard