Note: The mainteinance of the scripting examples is discontinued since I no longer have an interest to continue doing so. The pages will remain here, for now, but that might not be the case in the future. You are free to download all the material on these pages and set a up mirror, or even continue the maintenance of the material by enhancing the examples yourself.
All the material in these examples are for the mIRC version 6.03. It is very likely that some or most of these examples won't work in future versions.
Unfortunately channels in networks that have no channel service of any kind can become opless. This is one of the most annoying situations that can happen for a channel. It is even more annoying if the channel is +m or otherwise non-functional because of the modes. The solution for small channels is to make everyone leave and then rejoin. After the channel has become empty, the first one to join gets channel operator status and thus the channel can be restored to normal operational status. The problem is that it is often nearly impossible to make everyone part at the same time. Even if you got everyone else to leave, one user might have an idling client that won't be active within the next few days.
There are three ways to exit a channel: quit, part, or get kicked. What this script has to do is to make events for these situations, check if you are the last one on the channel without channel operator status, and then rejoin. Note that because the internal lists are not yet updated, you will actually have to check if there are two users on the channel when the quit happens. These two users are you and the one that is leaving. Naturally right after the event you will be the only one left, which is why when the count is two, you rejoin. You might also wonder the need to check for kicks and I agree that it's not a very likely scenario. It happens when there is an operator on the channel and you as non-operator and the operator decides to kick himself/herself out. It is also good idea to check if you are leaving the channel on purpose since that could possibly lead into endless loops.
Since this script is used to gain channel operator status, you shouldn't do that on all channels. It would simply generate unwanted trouble for yourself and others. You should set a list of channels to %hopchannels variable. These should be channels where you are recognized as a channel operator. The on LOAD event is merely an example and it serves no other purpose apart from setting the variable.
on *:LOAD: set %hopchannels #space,#music,#beginner
on *:QUIT: {
var %x = 1
while ( %x <= $comchan($nick,0) ) {
var %chan = $comchan($nick,%x)
if ( ($istok(%hopchannels,%chan,44)) && ($nick(%chan,0) <= 2) && ($me !isop %chan) ) {
echo -s Hopping %chan to regain ops
hop -c %chan
}
inc %x
}
linesep -s
}
on !*:PART:%hopchannels: {
if ( ($nick($chan,0) <= 2) && ($me !isop $chan) ) {
echo -se Hopping $chan to regain ops
hop -c $chan
}
}
on *:KICK:%hopchannels: {
if ( ($nick($chan,0) <= 2) && ($me !isop $chan) && ($knick != $me) ) {
echo -se Hopping $chan to regain ops
hop -c $chan
}
}I have been thinking whether it is a good idea to distribute information on how to do this. I have come into the conclusion that there are legal uses. Although it's often bad channel management, channels do become opless and the people need to be able regain the channel operator status without having to monitor the channel for the long period when then users leave. Practically all the networks already implement channel delay or timestamp protocols which should make sure that this script can't be used to get channel operator status during net-split. Neverthless I know that this piece of script can be used for abuse (although I sincerely wish otherwise). If you have a strong opinion about distributing this kind of information, please contact me and present your arguments. I will remove this if my conclusion is not based on reality