mIRC Home    About    Download    Register    News    Help

Print Thread
isexcempt - isinvite #172937 18/03/07 11:33 AM
Joined: Jul 2005
Posts: 51
P
poormillionaire Offline OP
Babel fish
OP Offline
Babel fish
P
Joined: Jul 2005
Posts: 51
$iel(#channel,N)
$iil(#channel,N)

Those 2 had been added upon my request.. but I'd like to have isexcempt and isinvite too, like isban

Code:
  if (nick isexcempt #chan) { bla bla }


This could also be done by a script, but why not built-in? smile


chadchoud @ DALnet
Re: isexcempt - isinvite [Re: poormillionaire] #172971 18/03/07 09:29 PM
Joined: Apr 2003
Posts: 342
M
MeStinkBAD Offline
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
how about isowner and iscreator too? What about isoper? Well I know why isoper would be a challange... but the other two would be nice...

you do relealize that your gonna need to get all three lists before isban, isinv, isexc will work of course. That means sending three mode commands.

/mode <chan> +b
/mode <chan> +e
/mode <chan> +I

These can be done at anytime (even outside the channel). Though mIRC can't keep track of changes unless in the channel.

Originally Posted By: poormillionaire
$iel(#channel,N)
$iil(#channel,N)

Those 2 had been added upon my request.. but I'd like to have isexcempt and isinvite too, like isban

Code:
  if (nick isexcempt #chan) { bla bla }


This could also be done by a script, but why not built-in? smile


Beware of MeStinkBAD! He knows more than he actually does!
Re: isexcempt - isinvite [Re: MeStinkBAD] #172988 19/03/07 02:20 AM
Joined: Oct 2004
Posts: 8,327
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,327
Originally Posted By: MeStinkBAD
how about isowner and iscreator too? What about isoper? Well I know why isoper would be a challange... but the other two would be nice...


The problem with those (any probably the reason they aren't added [yet]) is that not all networks use the same symbols and modes for each of those modes. On some, an owner may be ~, while on others, an owner may by &. Ops, halfops, and voices are the same on all networks afaik, so it's easy to determine if someone is an op or halfop or voice. The others aren't as easily handled.

I do see a possible solution that mIRC could possible allow, however. It could be that something like isowner could be made to require that you tell the script what character is used for owner on the network(s) the script is being used on:

if ($nick isowner(~) $chan) { }
if ($nick $isowner(~) $chan) { }

... Something like that. I gave 2 examples because any commands with ()'s generally have $ in front of the command, so the second line would follow that standard. But the isop doesn't use $, so the first one follows that standard. In either case, that may be a possible way to handle it, though probably not the "nicest" method.


Edit: Btw, you can use a scripted method...

Code:
alias isadmin {
  if ($3 isin $nick($1,$2).pnick) { return $true }
}


Use:
if $isadmin(#chan,nick,admin_mode) { do this }
if $isadmin(#Invision,Riamus,!) { echo -a Riamus is an admin }

That may not be the nicest way to handle those modes, but it would work as long as you stay on networks that use the mode you use in your script.

Note that this identifier only works properly if the network(s) it's used on won't allow nicks that use those modes. I tried on 2 networks and neither allowed me to change to a nick that used !,&,~ even if the network didn't have those modes. I didn't try other networks, so you'd want to check multiple networks to make sure they don't allow nicks to have those characters in them.

Anyhow, you could use that same identifier for all modes (change it to $ismode or something) because you're entering the mode to look for. Or, you can duplicate it for different modes so that you can easily see what you're checking for ($isadmin, $isowner, etc).

And, yes, you could do this without an identifier as well. I did this for those who might like such a thing.

Without an identifier, you'd just do:
if (! isin $nick(#chan,$nick).pnick) { do this }

That may be a preferable method for people.

Last edited by Riamus2; 19/03/07 02:36 AM.

Invision Support
#Invision on irc.irchighway.net
Re: isexcempt - isinvite [Re: Riamus2] #172989 19/03/07 03:52 AM
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
FYI: I have been on networks that do allow the ~ character.

Do to a major disagreement between myself and a channel op, who was/is friends with an IRCop on that network, I'm currently unable to connect to that network, so I'm unable to state if the ~ character is still allowed, but I know it was.

Re: isexcempt - isinvite [Re: RusselB] #173009 19/03/07 02:30 PM
Joined: Mar 2006
Posts: 393
T
The_JD Offline
Fjord artisan
Offline
Fjord artisan
T
Joined: Mar 2006
Posts: 393
I'm not sure how it is implemented.
But I thought the "isowner" operator was implemented.

I tried it on UnrealIRCd (via irc.urchat.net, which uses ~ as owner symbol) - Returned false.

However, When I tried it on IRCXPRO (crypthome.net, which uses . as owner symbol) - Returned true

My guess is that the ISOWNER checks for the "."
I thought it would get the info from 005 (I think) for the "q" channel mode. I guess not.

Should this be reported as a bug? I'd say no, But if you think so, Report it (after checking it dosnt yet exist)


[02:16] * Titanic has quit IRC (Excess Flood)
Re: isexcempt - isinvite [Re: poormillionaire] #173019 19/03/07 06:12 PM
Joined: Jul 2005
Posts: 51
P
poormillionaire Offline OP
Babel fish
OP Offline
Babel fish
P
Joined: Jul 2005
Posts: 51
Thanks.


chadchoud @ DALnet
Re: isexcempt - isinvite [Re: The_JD] #173030 19/03/07 09:58 PM
Joined: Aug 2004
Posts: 7,252
R
RusselB Offline
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
isowner was implemented in version 5.61 for IRCX servers
Quote:
23/09/99 - mIRC v5.61

Fixes/Additions:
2.Improved support for IRCX servers:

Added property $nick().owner, isowner if comparison, and "q"
property to $nick(#,N,aohvrq,aohvrq) where "q" is for owners.

Added on OWNER/DEOWNER events, work the same as on OP/DEOP,
and $mode().owner/deowner properties.


There is more in that same section that is somewhat related. Click here for the full versions.txt file which is where that quote came from.

Re: isexcempt - isinvite [Re: RusselB] #173145 21/03/07 07:31 AM
Joined: Jul 2003
Posts: 655
Om3n Offline
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
This is kind of offtopic (like most of the other posts), but... most servers specify a PREFIX= during connect (cant think of the raw off my head right now) such as PREFIX=(aohv)!@%+, for the most part mirc should be able to use logic to determin which is which, however if a network has an owner prefx/mode and not an admin prefix/mode (for example) it would still not know if the prefix/mode specified was for admins or owners.

Although i suppose it could work on the assumption that the prefix proceding the operator prefix is an admin prefix, and anything that may preceed that is for owners.

Seems feasable, since mirc knows o and v are always the same, it would know anything beterrn them is for halfop and anything preceding is admin and owner respectively


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Re: isexcempt - isinvite [Re: Om3n] #173258 22/03/07 04:25 PM
Joined: Mar 2006
Posts: 393
T
The_JD Offline
Fjord artisan
Offline
Fjord artisan
T
Joined: Mar 2006
Posts: 393
It would seem more logical to use the PREFIX token (of raw 005) to find which "visual" mode (+%@&~) would match (vhoaq) by counting the charachters.

q = owner
a = protect
h = halfop
o = chanop
v = voice

Using this guide would seem more 'compatible' - but obviously they would only work when set in PREFIX (some servers use these as channel modes).

This would also allow the OWNER events currently in mIRC to work with UnrealIRCd etc.

IRCX usage has majorly declined since the closing of MSN Chat (R.I.P.) worldwide.
Microsoft was the founder of IRCX and no longer appear to use the protocol, so we end up with "mIRC Scripted" IRCX (Like) Servers (Not recommended) and a couple decent clones.
Back to topic: Now that IRCX is almost obselete, Not many people see a "." for owner status in mIRC, It would seem much smarter to use the "q" rather than the "."


[02:16] * Titanic has quit IRC (Excess Flood)
Re: isexcempt - isinvite [Re: The_JD] #173276 22/03/07 09:10 PM
Joined: Oct 2004
Posts: 8,327
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,327
I'm not sure if all network software sends out prefixes when connecting, and even if they do, it could be difficult to determing which mode is which level. For example, if there are 4 modes in the RAW output, you can assume that 2 are op and voice. But what are the other 2? How can you be absolutely sure that the first is admin and the second it halfop? Maybe it's owner and admin, or owner and halfop, or owner and protected, etc. If a network doesn't use the common prefixes (q=owner,a=protected,etc), then you can't even go by that method.

mIRC could set it so that it uses the most common prefix for isowner, isadmin, isprotected, etc. That could still become a problem for people using networks that don't use the common prefixes. There isn't a perfect way to handle it unless we get all networks to stick to the same prefixes (one or both of the methods) whether they use the modes or not.


Invision Support
#Invision on irc.irchighway.net
Re: isexcempt - isinvite [Re: The_JD] #173304 23/03/07 10:19 AM
Joined: Jul 2003
Posts: 655
Om3n Offline
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
Quote:
3.14 PREFIX

o PREFIX=[(modes)prefixes]

The PREFIX parameter specifies a list of channel status flags (the
"modes" section) that clients may have on channels, followed by a
mapping to the equivalent channel status flags ("prefixes"), which
are used in NAMES and WHO replies. There is a one to one mapping
between each mode and prefix.

The order of the modes is from that which gives most privileges on
the channel, to that which gives the least.

[Example: (ab)&* maps the channel mode 'a' to the channel status
flag '&', and channel mode 'b' to the channel status flag '*'.]

[Example: PREFIX=(ohv)@%+ maps channel mode 'o' to status '@', 'h'
to status '%', and 'v' to status +.

The default value for PREFIX is "PREFIX=(ov)@+", which corresponds to
RFC 1459 [5]. It SHOULD NOT be specified if the server provides only
these modes. If a server provides ANY additional status flags, it
MUST also provide (ov)@+ (assuming they are applicable to the
server). The PREFIX parameter may be advertised with a null value
specifier; this indicates that no prefixes are supported by the IRC
server.

Note that PREFIX does NOT specify whether or not the server sends
multiple prefix characters for a user in NAMES replies.


I think its feasable enough for mirc to use this to determine the modes if there was better standard to them, it could do it now but there would be some circumstances when things might not be accurate. For example, some people have mentioned a=protected, however in my experience a is usually for channel admin.

The_JD, i dont believe is matters if the flag or the symbol is used.

It might not be a perfect solution, but its better than nothing.

Anyway.


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Re: isexcempt - isinvite [Re: Om3n] #173312 23/03/07 01:15 PM
Joined: Oct 2004
Posts: 8,327
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,327
However, as in my example, if a network doesn't use the expected prefixes, how do you know if 2 of the 4 are owner/admin or owner/protected or whatever? You can set it up to work with the major networks, but that can cause confusion over why it's not working on network X.


Invision Support
#Invision on irc.irchighway.net