for the first time posting here, i did a search and found no one else had posted anything having this:

a server that has HOP doesnt have UOP, and the other way.
so why shouldn't "ishop" handle UOPs aswell?

right now i have to do a pnick on the nick to find its umodes and then see if its a +u user or not.

but just as isop and isvoice and ishop itself are usefull, it would be a much better thing to have a isuop or atleast letting ishop handle the +u users.

what do you guys think?

You can also use mode symbols in the $nick identifier.

if ($nick($chan,$nick,h)) is the same as
if ($nick($chan,$nick,%)) is the same as
if ( $nick ishop $chan )

If your server is using a different symbol like *, you can replace % with *.

- Raccoon

There's no reason a server couldn't be set up to have UOp and HOp.

Even if they couldn't it would be completely confusing if ishop worked with uops aswell since they usually have completely different access levels. So any code made to work with hops and the common access given to hops would then trigger for uops which the scripter most likely never intended, causing the code to break.

I also don't see the need for an isuop operator, otherwise why not support any other half-assed usertype that IRCd developers decide they want to throw at people? Using $nick() is a much more adaptable method than the is* operators.

I scripted a small IRC server in mIRC once. All user modes where determined by a setting. This said, you could have virtualy unlimited amouts of user modes, with any smybols you fancy. If you realy need to preform this type of check, you could always use $left($nick().pnick,1). (Keep in mind thats not complete sayntex.)

my problem is not using the script, its a feature request.
i could use 101 ways to do it, but the point is as ishop is included, so it would be a uniform approach to have isuop, or at least let the operator handle both.

and about being any problem with having hop or uop at the same time, well there is no problem, BUT, practically no ircd has them both.