mIRC Home    About    Download    Register    News    Help

Print Thread
$ulevel and named levels. #254260 31/07/15 01:56 AM
Joined: Jan 2005
Posts: 188
Brax Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Jan 2005
Posts: 188
Hi,

It seems that $ulevel returns 1 (Or whatever the default level is set to) when matching level is named level and event level is *

Example:
test:Brax!*@*

ON *:TEXT:*:#: { echo Level: $ulevel }
Returns: Level: 1

ON test:TEXT:*:#: { echo Level: $ulevel }
Returns: Level: test

If userlevel is number then $ulevel returns the level properly.


echo -a $signature
Re: $ulevel and named levels. [Re: Brax] #254265 31/07/15 08:08 AM
Joined: Mar 2010
Posts: 144
Masoud Offline
Vogon poet
Offline
Vogon poet
Joined: Mar 2010
Posts: 144
Code:
/help Access levels


Nothing...
Re: $ulevel and named levels. [Re: Masoud] #254266 31/07/15 08:25 AM
Joined: Jan 2005
Posts: 188
Brax Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Jan 2005
Posts: 188
Could you please be more specific?
Which part of that help section should I pay closer attention to?


echo -a $signature
Re: $ulevel and named levels. [Re: Brax] #254267 31/07/15 09:35 AM
Joined: Apr 2004
Posts: 841
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 841
Named access levels are specific access levels. Every user also has a general access level, which is a number. Since your * trigger is not explicitly matching a specific named level, the match succeeds against the general access level, and $ulevel returns that general access level. While this may not be the behavior you expect, it is not a bug.


Saturn, QuakeNet staff
Re: $ulevel and named levels. [Re: Sat] #254269 31/07/15 11:01 AM
Joined: Jan 2005
Posts: 188
Brax Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Jan 2005
Posts: 188
While I can somewhat agree with this explanation I still have to point out the following:

If we still assume that user is:
test:Brax!*@*

Then considering that the user has this hidden general access level along with the specified named level the following should trigger as well:
ON 1:TEXT:*:#: { echo Level: $ulevel }
However this fails to trigger despite the user having this hidden general access level along with named level.

If I quote from help:
Quote:
Named Levels

You can also used named levels which work the same way as a specific level but are easier to understand and read than a number.


If according to help the named levels are supposed to work same way as numbered levels then it should be safe to assume that one can use them the same way without having to take into account that some undocumented "feature" kicks in someplace.

Quote:
User List

In the Users section you can specify a list of users and their access levels using the format: <level1,level2,...,levelN>:<useraddress>

3,5,6:nick!user@mirc.com

The first level is a general access level, which means that the user can access all levels equal to or less than 3. All the other levels are levels that an event must specifically have to allow a user to access it.


Continuing on:
Lets set user:
10:Brax!*@*

ON 1:TEXT:*:#: { echo Level: $ulevel } >> Level: 10
ON *:TEXT:*:#: { echo Level: $ulevel } >> Level: 10

If $ulevel returns the user level that was matched for the currently triggered event.
Then:
test:Brax!*@*

ON 1:TEXT:*:#: { echo Level: $ulevel } >> The user who typed something is not level 1 so it shouldnt match (with numeric levels it will match level 10 user since 1 < 10)
ON *:TEXT:*:#: { echo Level: $ulevel } >> The user who typed something is level test so it should say that $ulevel is test instead of saying that $ulevel is 1

/ulist <1
Returns all named levels (Less than 1)
Which means that 'test < 1'

---------
Maybe im wrong but considering that with numbered levels you can also use expressions like < > (less/greater than) then it sort of seems like the original intention was to keep the userlevels numbered only. But afterwards the named levels were also added and something just "broke".

Since its possible to use $level($fulladdress) in events (which will return the real levels as they are in userlist) it isnt really game breaker but still quite unexpected mess.

If current behavior is really not a bug and indeed an intended behavior then perhaps this should be documented better so there wont be any confusion.


----
As a sidenote... who knows maybe if I get some sleep I might see the logic in it and will be embarrassed about the long rant. laugh


echo -a $signature
Re: $ulevel and named levels. [Re: Brax] #254276 31/07/15 03:04 PM
Joined: Apr 2004
Posts: 841
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 841
Originally Posted By: Brax
However this fails to trigger despite the user having this hidden general access level along with named level.

Hum, if this is the case, then I misremembered and stand corrected. In that case, my only possible explanation would be that for matching * triggers, mIRC always sets the $ulevel value to the general access level of the user, which if there is none defaults to $dlevel. This behavior is then the same for users with only specific access levels, and users without any access level at all. Such behavior does somewhat make sense in that for * triggers, no matching of specific access levels needs to be performed anyway. I do now agree that this is unexpected at best.

However, one could make the argument that named access levels allow different scripts to manage different access lists at the same time. In that case, a script should never rely on $ulevel returning that script's named access level from a * trigger, since with your proposed change, $ulevel could return any one of the user's matching specific access levels. So in that sense, the current behavior isn't all that bad either, maybe.


Saturn, QuakeNet staff
Re: $ulevel and named levels. [Re: Brax] #254278 31/07/15 04:18 PM
Joined: Jul 2006
Posts: 3,588
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,588
Quote:
ON 1:TEXT:*:#: { echo Level: $ulevel }
However this fails to trigger despite the user having this hidden general access level along with named level.
I didn't try, but it should trigger when the default level is 1, I suspect you changed it for testing purpose and forgot to change it back.
Quote:
ON 1:TEXT:*:#: { echo Level: $ulevel } >> The user who typed something is not level 1 so it shouldnt match (with numeric levels it will match level 10 user since 1 < 10)
Same idea, if the default level is 1, your named access level will be able to access this event.
Quote:
ON *:TEXT:*:#: { echo Level: $ulevel } >> The user who typed something is level test so it should say that $ulevel is test instead of saying that $ulevel is 1
Again, no, because $ulevel was likely meant to return numeric value.

With named access level, there is still a numeric access level involved when triggering an event and $ulevel is there for that.
That being said, it is obviously not useful with named access level, but I think this is a lack of support.
For example a new $nlevel identifier could be added to handle this situation, which would return the named access level if any and would allow scripter to dynamically create events they want different users to access where some could be numeric access level but also some named access level.
That being said, we could easily ditch this solution away, indeed, as Sat mentioned, in a case of an event using '*' and a named access level is triggering, the numeric value of $ulevel will always be the same as $dlevel, the default level, making this information useless. The question is, would it break scripts to change $ulevel to return the named access level if any is involved, rather than its numeric value?

Considering the current behavior, a scripter can't use $ulevel to get the named access level, meaning that a scripter is currently, at best, checking $ulevel against known numeric access level.

A:A!*@*
12:B!*@*
--
on *:text:*:#:{
if ($ulevel == 12) noop
elseif ($ulevel == A) noop
}

This elseif is currently invalid, so if a script is doing that, it's wrong. If $ulevel is changed to be able to return A, well the script is still currently wrong for doing that, you can't see this as breaking backward comp, it's just the script being wrong.
By definition, changing $ulevel cannot break current valid script, only a script doing non sense could break.
I can't stress this enough because I've been reporting a lot of issues or asked for a lot of changes where this same context is involved, the change/fix would break a script only if the script was wrong/incorrect in the first place, it makes no sense to valorize those scripts rather than the ones which want to be correct.
One example? Allowing $1- to 'exist' inside the 'second' evaluation of /scid and /scon (where local variable do exist).



In others words, (this is always usually the case with backward comp, a change only break comp if the scripter is currently using a wrong a logic, but which still get the job done) this means that for a script to break if this were changed, it means the script is currently made as though $ulevel could return a named access, which we just saw is not the case.


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: $ulevel and named levels. [Re: Wims] #254280 31/07/15 09:29 PM
Joined: Jan 2005
Posts: 188
Brax Offline OP
Vogon poet
OP Offline
Vogon poet
Joined: Jan 2005
Posts: 188
Just for the sake or argument. smirk

Originally Posted By: Sat

However, one could make the argument that named access levels allow different scripts to manage different access lists at the same time. In that case, a script should never rely on $ulevel returning that script's named access level from a * trigger, since with your proposed change, $ulevel could return any one of the user's matching specific access levels. So in that sense, the current behavior isn't all that bad either, maybe.


Obviously. One should rely on $ulevel returning level that was matched for the currently triggered event. With my "proposed change" $ulevel would be returning exactly what the documentation says it will return.. If you want to see what other levels the user has then you have $level() which will return all levels that the user has (both named and numbered).

So having user: test,10,20:Brax!*@*
ON *:TEXT:*:#: { echo Ulevel: $ulevel Dlevel: $dlevel Levels: $level($fulladdress) }
Result for Brax: Ulevel: 1 Dlevel: 1 Levels: test,10,20

In this context you should rely on fact that $ulevel returns test and not 1 (nor 10 or 20)
Since according to help the first level is a general access level and all the other levels are levels that an event must specifically have to allow a user to access it.

Originally Posted By: Wims
I didn't try, but it should trigger when the default level is 1, I suspect you changed it for testing purpose and forgot to change it back.

I really did make sure that default level is 1
User is: test,10,20:Brax!*@*
ON 1:TEXT:*:#: { echo Nick: $nick Ulevel: $ulevel Dlevel: $dlevel Levels: $level($fulladdress) }
For Brax!*@* this does not trigger.
For someone not in userlist it returns: Nick: LabRat Ulevel: 1 Dlevel: 1 Levels: 1

And personally I think this is expected behavior. For Brax the general access level (first in list) is test and he also has two specific levels 10 and 20.

Although according to help it should trigger:
Quote:
The default access level is 1 for users that are not listed in the Users list. All users can access level 1 events. The higher a user's access level is, the more events that user can access.


Currently only time the $ulevel returns the named level is when you limit the level to that specific named level:

ON test:TEXT:*:#: { echo Nick: $nick Ulevel: $ulevel Dlevel: $dlevel Levels: $level($fulladdress) }
Returns: Nick: Brax Ulevel: test Dlevel: 1 Levels: test,10,20

Although I really dont see why I would even need to use $ulevel in this event at all.

Originally Posted By: Wims
/.../ because $ulevel was likely meant to return numeric value.

Like I said earlier as well I suspect that this is the case indeed. Named levels seem to be an afterthought which were added but never really fine tuned.
The userlevel system seems to be built around basic math (meaning numbers). The higher number your access is the more you can access. Introduce letters into this mix and the real "fun" starts.
Of course one could argue that you can do same with named levels.
So 'Xtra' is higher than 'Basic' (since B < X) The simple text sorting A to Z.
But this of course will make things even more complicated.

----------

In conclusion whether its a bug or feature at least it doesnt behave the way it's documented.
Quote:
You can also used named levels which work the same way as a specific level but are easier to understand and read than a number.

Clearly the named level does not behave the same way as specific level and while being easier to read it does seem to cause confusion in scripting logic.


echo -a $signature