Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hello]

Hi,

I understand that anope will automatically hide commands that are not available to user. However, when services op, let's say /ns help, all the available commands, mixed between user and csop are shown.

There is no problem actually but I find it will be neat if:
regular command shown through /ns help
csop command shown through /ns ohelp

Btw, I couldn't find any flood protection from services config or I miss it somewhere? Does that mean all flood protection will be provided by ircd only?

When not opered up, I flood the services in the test box, I didn't get "kill" or anything, could it be the ip exempted from throttle in ircd?

Thanks

 

[katsklaw]

csop's see all commands available, including user commands. It's assumed that a csop knows the difference between user commands and oper commands and thus doesn't need a separate command. This is an area where you as the netadmin should educate your staff. On the tech side of things, implementing this feature would be far far more work than benefit. That means restructuring the help subsystem from the ground up, which isn't a tiny task for either branch. It's far easier and beneficial for all parties for you to simply do your job and educate your IRCops.

Anope's flood control is in the ignore list found in OperServ. As far as flooding goes, the ircd will and should be the front line for text over IRC. Most ircd's do this with sendQ/recvQ and is configured in your Y:Lines or class blocks. Once sendQ or more commonly recvQ is filled, the ircd will and should kill the user.

Hope that helps.

[hello]

Thanks for the explanation.

Is there a way to re-arrange the help menu listing? For example, I prefer in /cs help, AOP, SOP, QOP are listed together and some other arrangements that I personally feel that will be easier to find.

Btw, I just switched to new anope. There quite a significant change. Need some time to get used to

[katsklaw]

In 1.8:

QOP is not a core XOP level in 1.8 (VOP,HOP,AOP,SOP, founder), it would be added by a module.

The Help menu is kinda weird the way it works. Part is in the core lang files for language support, the other part is is added via the associate module. you could try arranging the order the module is listed in the *CoreModules sections in the order you wish them to appear but I'm not sure that will do anything. 3rd party modules are added later and usually delayed so if it's possible to rearrange the order, it's still not completely controllable.

In 1.9:

Someone else would have to answer.

[hello]

Guess I will be waiting for an answer

I switched to 1.9.6. So many news here and there. Syntax changed a bit, commands changed, no more password for chanserv, xop and levels loaded together etc. I like most of the changes and it so many features. And also because of that, I find the information is overwhelming. Maybe I am getting old lol.

I personally prefer either level or xop (the old way), organized help menu, kinda like category (aop,sop,qop) or even better separated user and oper.

Oh maybe next version can make it possible to autologin to operserv, similar to autologin to chanserv. See, now have to login to nickserv, then oper, then operserv, I know simple script can automate those but why not built in

Btw, fingerprint is kool just too bad need to wait till unreal 3.3?

[LEthaLity]

There is no requirement to login to operserv, that's an optional password, without it you will get your services oper/admin levels when identifying with nickserv.

Changing the help wouldn't be that easy as everything is modularized, and commands and their help are added separately in their relevant configs, then listed alphabetically, a possible workaround may be to create a module that just spits out a deprecation message and refers a user to the new commands/methods, like Unreal does with /akill. Best I can think of at 5am :p