A couple practical requests..

These are old archives. They are kept for historic purposes only.
Post Reply
zero[nothing]
Posts: 2
Joined: Tue Aug 21, 2012 1:16 am

A couple practical requests..

Post by zero[nothing] » Tue Aug 21, 2012 1:44 am

Hello. I'm looking for a couple of modules to help with certain things. My idea of being an owner/admin of a network is it's my responsibility to make sure that people can't do things that would normally get them punished otherwise and people easily access and understand the offerings my network provides.


With that said, I have a few module requests.

1. ALL opers (with exceptions of netadmins of course) may not be allowed to part #opers until they set umode -o (else it sajoins them back in and sends them a message explaining the situation)

2. A module which displays the Services clients (usermode +S) in the nicklist prefixed with a ! or a . (not ircops)

3. a /setcolor module which will "color" a nickname without the funky control codes I saw when I tried doing it myself in the nicklist. This is an idea from another ircd, ircu-based "irco". It adds a usermode and displays all messages person sends with the nick in color (example: /setcolor blue turns your nick blue)

4. a /lock command which acts like shun but doesn't allow the nick to use /nick /join /part. it behaves like shun where it can be a nick or host and doesn't lose itself on a disconnect or restart.

dboyz
Posts: 68
Joined: Tue Jun 14, 2011 6:36 am

Re: A couple practical requests..

Post by dboyz » Tue Aug 21, 2012 12:18 pm

These three modules would be great to implement.

cheiron
Posts: 74
Joined: Sun May 29, 2011 6:17 pm

Re: A couple practical requests..

Post by cheiron » Tue Aug 21, 2012 1:13 pm

irco as far as i know is based from Undernet not unrealircd so it is totally different code to unreal.

the Oper one i am not too keen on the idea of that but an edit is all that would be needed to this module from one of my earlier threads...
http://forums.unrealircd.com/viewtopic. ... 4&start=15

The services clients one has been, i believed asked before and got ruled out

katsklaw
Official supporter
Posts: 1114
Joined: Sun Apr 18, 2004 5:06 pm

Re: A couple practical requests..

Post by katsklaw » Tue Aug 21, 2012 6:16 pm

1. ALL opers (with exceptions of netadmins of course) may not be allowed to part #opers until they set umode -o (else it sajoins them back in and sends them a message explaining the situation)

I would like some reason to force opers to remain in any channel. UnrealIRCd is written to make it so IRCops don't *need* to be in any channel to still stay informed. This is what SNOmasks and /*ops commands were specifically designed for. This requests seems to be taking 10 steps backwards.

2. A module which displays the Services clients (usermode +S) in the nicklist prefixed with a ! or a . (not ircops)

This has no practical or security advantage so I fail to see justifying man hours and resources to implement.

3. a /setcolor module which will "color" a nickname without the funky control codes I saw when I tried doing it myself in the nicklist. This is an idea from another ircd, ircu-based "irco". It adds a usermode and displays all messages person sends with the nick in color (example: /setcolor blue turns your nick blue)

Colorized nicknames are a direct violation to RFC1459 and will break clients. It's been asked for several times and shot down every time.

4. a /lock command which acts like shun but doesn't allow the nick to use /nick /join /part. it behaves like shun where it can be a nick or host and doesn't lose itself on a disconnect or restart.

There is a feature request on the bug tracker that will supply this feature already. The details can be seen at: http://bugs.unrealircd.org/view.php?id=4055

dboyz
Posts: 68
Joined: Tue Jun 14, 2011 6:36 am

Re: A couple practical requests..

Post by dboyz » Wed Aug 22, 2012 3:17 pm

Thanks for the detailed information. I guess the some people want the ! or . prefix because they want to be fancy.
Some users (like myself) prefers services clients having a different prefix to avoid confusion.
(for example: currently, irc clients such as mirc will group ChanServ with other protected users in a #channel)

I think there are however no significant advantage of implementing an additional prefix.

Just my opinion.

katsklaw
Official supporter
Posts: 1114
Joined: Sun Apr 18, 2004 5:06 pm

Re: A couple practical requests..

Post by katsklaw » Wed Aug 22, 2012 3:48 pm

What "confusion" are you referring to? In my 16 years as an IRCop I've never met someone that was ever confused about ChanServ or services. If you are referring to having to explain what services is, then you'd still have to do that and then also explain what the extra prefix is/does to those that already know.

Stealth
Head of Support
Posts: 2078
Joined: Tue Jun 15, 2004 8:50 pm
Location: Chino Hills, CA, US
Contact:

Re: A couple practical requests..

Post by Stealth » Thu Aug 23, 2012 2:49 am

katsklaw wrote:3. a /setcolor module which will "color" a nickname without the funky control codes I saw when I tried doing it myself in the nicklist. This is an idea from another ircd, ircu-based "irco". It adds a usermode and displays all messages person sends with the nick in color (example: /setcolor blue turns your nick blue)

Colorized nicknames are a direct violation to RFC1459 and will break clients. It's been asked for several times and shot down every time.
Additionally, most clients (such as mIRC) will refuse to color nicknames that contain control codes. The clients will instead display the code in plain text.

dboyz
Posts: 68
Joined: Tue Jun 14, 2011 6:36 am

Re: A couple practical requests..

Post by dboyz » Thu Aug 23, 2012 3:10 pm

The confusion I mentioned is minor and it might occur in new users.

A new user might think that there are two ops in a channel because of the same prefix when there are only one op, who is accompanied by ChanServ.

I have met a user who asked something similar: "How do you kick this guy out of my channel? His name is ChanServ. He is opped."

I was thinking probably by assigning services clients to a separate prefix, it can reduce the possibility of such confusion.

At the end of the day, there is no significant advantage to add an additonal prefix afterall.
I agree with katsklaw that someone has to explain what are services clients to new users.
Besides, adding another prefix can be a waste of time and resources.

katsklaw
Official supporter
Posts: 1114
Joined: Sun Apr 18, 2004 5:06 pm

Re: A couple practical requests..

Post by katsklaw » Thu Aug 23, 2012 7:15 pm

@dboyz: Technically you do have 2 ops, most services packages grant op status to ChanServ even though it's not needed. Traditionally, ChanServ isn't even supposed to be in channel in the first place.

Additionally, user education is very important and can prevent your confusion example. I recommend holding weekly or even bi-weekly training for everyone from users all the way to the top. Since no one knows everything, everyone would benefit .. even the NetAdmins! ;)

dboyz
Posts: 68
Joined: Tue Jun 14, 2011 6:36 am

Re: A couple practical requests..

Post by dboyz » Sat Oct 20, 2012 12:00 pm

You are right but what about botserv? Bots created under botserv do not come with a specific nickname (i.e. *serv) and (correct me if I am wrong) services admin are free to decide each bot's masked hosts (or is it called vHost, I cannot recall). Therefore it is rather difficult to differentiate normal clients and services (i.e.botserv) clients unless someone takes the effort to do a /WHOIS.

Just a random thought.
Again as I mention above, there is no significant advantage when adding such prefix.

Post Reply