|Anonymous | Login | Signup for a new account||2021-01-15 21:11 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008286||opensim||[REGION] Script Functions||public||2018-01-26 20:39||2018-07-04 05:06|
|Platform||Operating System||Operating System Version|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0008286: [PATCH] Adds osGetAgentUserLevel()|
|Description||Add OSSL function to get the user level of the provided key. This would be useful to allow scripts to take some kind of action depending on what the level of the targeted user is.|
string osGetAgentUserLevel(string agent);
Returns user level of agent provided as a string if the user is in the region else it returns an empty string.
|Additional Information||Testing script|
key toucher = llDetectedKey(0);
string UserLevel = osGetAgentUserLevel(toucher);
if(UserLevel != "")
llWhisper(0, "Your user level is: " + UserLevel);
llWhisper(0, "Error getting user level for '" + (string)toucher + "'");
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||.NET / Windows64|
|Attached Files||0001-Implement-osGetAgentUserLevel.patch [^] (3,047 bytes) 2018-01-26 20:39 [Show Content]|
|Userlevel in the database is set as integer, it would make more sense for this function to return an integer rather than a string.|
I agree with tampa, oddly, this would be better if it returned it in the same format in the DB, can always cast to a string.
At first I thought this idea to be useless, but I have thought of a few ways that it could be very useful..
Scripts that only allow users of a certain level to access them, this would be handy.
|Also just a thought shouldn't the (string agent) be (LSL_Key ID) or similar?|
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 Hence why it should really just return the userlevel as integer, what one does with it is then up to them.|
bc its me and me does not like that :p
more confusion on HG script sharing etc, until a standard is defined ( or assumed by us )
@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.
Also this: http://opensimulator.org/wiki/Userlevel [^]
Thinking a bit more, such feature may have good issues
But also not so good ones.
Scripts should no change behavour acording to user level
So, refused for now.
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 :)
I think that having scripts adjust according to the user level of the person clicking on a prim would be a bad idea.
I agree that it should def. not return a string but the level (200) that we set in the database itself.
What if an Admin clicks and after that the script does not reset properly giving the "best things" to normal users.
|2018-01-26 20:39||mewtwo0641||New Issue|
|2018-01-26 20:39||mewtwo0641||File Added: 0001-Implement-osGetAgentUserLevel.patch|
|2018-01-26 20:39||mewtwo0641||Status||new => patch included|
|2018-03-30 11:57||tampa||Note Added: 0032616|
|2018-03-30 14:10||BillBlight||Note Added: 0032617|
|2018-03-30 14:15||BillBlight||Note Added: 0032618|
|2018-03-30 15:01||UbitUmarov||Note Added: 0032619|
|2018-03-30 15:02||tampa||Note Added: 0032620|
|2018-03-30 15:04||UbitUmarov||Note Added: 0032621|
|2018-03-30 15:09||tampa||Note Added: 0032622|
|2018-03-30 15:32||UbitUmarov||Note Added: 0032623|
|2018-03-30 18:51||mewtwo0641||Note Added: 0032624|
|2018-03-30 19:35||tampa||Note Added: 0032625|
|2018-07-04 05:06||Fly-Man-||Note Added: 0032720|
|Copyright © 2000 - 2012 MantisBT Group|