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.
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.
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.
