Just for the sake or argument.
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.
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:
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.
/.../ 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.
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.
