Please Disable Ad-Block To View This Website.

If you block ads, this site can not survive!

Ads are very minimal for registered users. If you don't have an account please register now!

 Full Scripts
 MTS Themes
 File Queue
 Download mIRC
 Top Downloads
 Submit Form

Site Search

Link to us!

Home | Comments:
Average Rating:   9.4   /putmode v1.2 by myggan
Snippet to compress (squeeze together) and queue modes, can handle *any* modestring passed to it.

Submitted Review Author's Updates

There is no review for this file yet.
February 6th, 2006:
* Added an -s switch, to work better with IRCd's who uses 'strict mode enforcement'

* Added a -tN switch, which sets the delay interval for the modesetting

* Fixed alot of bugs


  Mode:    Create New Post

dr_EamerFeb 4, 2006 2:21PM
Rating:     8You're checking if the user is on the channel and has op or halfop status which isn't always necessary. Some servers allow mode changing from outside the channel or without ops (usually for ircops).

Even if we consider the checks valid and necessary, you're checking it in the putmode alias even though they are executed 1.2 (or custom set) seconds later. During this 1.2 seconds the user may as well have lost his op/halfop status (although you do check the case of him being kicked or parting the channel).

FiberOPticsFeb 4, 2006 3:00PM
Heh, is it really worth removing this check just because "some" servers allow for that (and only for IRCOPs)?

I think the benefit of removing the check is far lower than the benefit of keeping it, especially considering that 99% of the people who will use this snippet aren't IRCOPs on a server that does allow something like that.

I guess he could add a switch, which IRCOPs can specify so that the check is skipped, but it just sounds stupid to take into account little exceptions like this.

Text edited by author on Feb 4, 2006 @ 3:06PM

mygganFeb 4, 2006 4:07PM
I check if you are (half)opped in both /putmode and /putmode.exec (the timed one), but only the first one will produce an error message.

W-UnitJun 15, 2006 6:37PM
I agree. It shouldn't depend on this; the user should do their own checks before inputting them if they need to.

MicEikenJun 5, 2006 4:20PM
I owns!
I use it for my tag voice/op

Text edited by author on Jun 5, 2006 @ 4:20PM

jayteaFeb 9, 2006 8:45PM
Rating:     9the fact that you updated this snippet tells me that you either improved or corrected something. good job

poiuy_qwertFeb 9, 2006 11:45PM

mygganFeb 10, 2006 10:22AM
Check the "Author's Updates" ;)

mafixJan 31, 2006 4:23AM
Now you're going to kill me for sure, but you really like re-making Wiebie's ideas :)

Edit: This is -not- criticism. It's a good script. Perfect for bots connected as clients to prevent excess flood.

Text edited by author on Jan 31, 2006 @ 4:29AM

mygganJan 31, 2006 11:10AM
I knew this comment would come :P

However, wiebe's pushmode does not support multiple modes nor long modestrings. These are the primary reasons why I dislike his script and thus, making putmode.
Not to badmouth pushmode, but my snippet is simply a lot less code for more functionality :)

myndziJan 31, 2006 6:02PM
More flexibility, yes... more functionality? Not so sure.

Anyway, to respond to the grandparent; one could also say wiebe likes copying eggdrop, if you want to be a jerk about it.

myggan: What would be nice to see is a minimum and/or maximum delay switch that will specify how long a mode can wait before it must be sent.

mygganJan 31, 2006 6:14PM
Yes, maybe flexibility is a more appropriate word, but he got my point anyway.

Not quite following your suggestion, could you explain a little more in detail?

myndziJan 31, 2006 7:45PM
putmode -x30 modes - wait at MOST 30 seconds (maximum) before sending modes
putmode -n30 modes - wait at LEAST 30 seconds (minimum) before sending modes

Millisecond versions would be useful too.

-n acts as a delay; -x allows you to specify how much 'buffer time' the mode command has. Modes that have been in the queue for longer than the minimum and less than the maximum are considered for a potential mode line. A mode line is sent when it uses an entire MODE command (modes == $modespl), or when its length approaches 510 bytes (minus source = about 450 would be a reasonable constant). If a mode has been in the queue for the maximum time, send it and any other modes you can include NOW.

Making sense? It's rather more complicated, I'll agree.

It should also be noted that some IRCds (I'm pretty sure not all) only count parametered modes towards the modes per line. Dalnet is the handiest example, and it's a new change; you can send 15 modes in a line, so long as only 6 or less of them take parameters.

mygganFeb 1, 2006 10:25AM
I see your point, however I think the current version has a switch to set the actual delay, that is pretty sufficient in my opinion. Maybe if I get the time and energy I could implement your idea, but not as it looks now.

And I know about the fact that you can send parameterless modes as long as the parameter count is <= $modespl, but I didn't know the limit. I suppose the limit is in a 005 token? This snippet does not check it for a limit (it can send +mintooovvv for example).

myndziFeb 1, 2006 2:50PM
There is no limit. Except the length of the line; though most servers that allow you to do this also do 'strict' mode enforcement, so it's not liekly to get too long.

As far as it already havinga switch for the delay, yeah, but the more useful one is the max duration, not the min duration...

mygganFeb 2, 2006 1:11AM
I'll see what I can do.

toe_cutterJan 30, 2006 3:59PM
A bit overkill id say ;) but gj anyway, there is a need for something like this imo.

mygganJan 30, 2006 5:16PM
overkill in what way?

toe_cutterJan 31, 2006 2:49PM
overkill as in a lot of code. tho i havent gone through it all, im asking myself if hashes is really necessary to achieve the desired "effect".

mygganJan 31, 2006 4:35PM - Go compare ;)

No, seriously. The code isn't long at all for this particular purpose. Every inch of the code serves a specific purpose.
And why not use hash tables? It's the fastest way of storing data, and yes, you need to store data.

mygganJan 31, 2006 1:06AM
Until I can update, a newer version can be found here.

It contains two vital bugfixes and one minor as well as two useful switches.

Text edited by author on Jan 31, 2006 @ 1:07AM

JigsyJan 30, 2006 5:33PM
Rating:     10Love it, Good work! :)

suikodenJan 30, 2006 8:18AM
Rating:     10good snippet, definetley very useful. nice idea

Ghost2Jan 29, 2006 11:41PM
Rating:     10I like it! Reminds me of an eggdrop's put/flushmode

Create New Post

You must be logged in to post messages.