user levels are currently not defined.
We do have some implicity use ( like > 200 for admins, 255 for grid admins), but still not fully defined as standard
And so this must be delayed until a standard is defined.
(yes i did intentional used admin in place of "god")

@Ubit Most use 250 for "Grid God" even though admin rights report back 220 or <200 when requested through the viewer. The metric <200 should be a good enough standard and is likely to be the most commonly used as it is already the standard.

I did originally have it return as an integer but I got to thinking about the fall back condition and what it should return should there be some sort of error getting the value (Such as trying to get the user level of a user not in the region). With an integer return type the only option I could see was to return a negative number but I remembered that user levels can be set in the negatives to prevent them from logging in (Assuming the grid's default login level is at 0). That lead me to settling on string as an empty string could indicate that there was an error much like how llKey2Name() returns an empty string if the target agent isn't in the region.

As I understand, Ubit does not want to add this right now because there is no set standard for user levels; but if that changes and if anyone has some suggestions for error handling as integer return type I'll be happy to go back and modify it and post a new patch.

I would think something like -21471483648 since it is the overflow of 32bit integers? The db only allows 11 characters so this should not be a possible value and it hints at a problem(at least for those who know a thing or two about programming) with it being so large, negative and seemingly random. Plus a search spits out hints to it being an error/overflow value.

You are right that it would be easier to just spit out strings, but that is a bit counter-intuitive since userlevel(level) is usually a number. Maybe return empty string when it fails, thus creating a typecast script error? Then again, like you say negative numbers are used for login restrictions, so technically it could not return -1 since the user would not be able to login in the first place. Maybe it should request the min-loginlevel from robust and spit out whatever number is below for a failure? That's equally as confusing. You may be right in using a string as much as it seems implausible, the error handling would be better with a string.

In any case, since it may or may not make it in probably leave it as is for now. Sometimes the first draft is the best :)