Difference between revisions of "Talk:LlGetObjectDetails"

From Second Life Wiki
Jump to navigation Jump to search
Line 63: Line 63:


::I completely forgot about the move permission! It's a very nice solution though for objects that are '''effectively''' group-owned (which may be fine for some people), now if only we had a direct access function to an object's own group UUID… <br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 03:36, 12 September 2012 (PDT)
::I completely forgot about the move permission! It's a very nice solution though for objects that are '''effectively''' group-owned (which may be fine for some people), now if only we had a direct access function to an object's own group UUID… <br/>-- '''[[User:Haravikk_Mistral|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]])</small></sup> 03:36, 12 September 2012 (PDT)
== new constants Sep. 2013 ==
These aren't totally implemented on the servers yet, dropping this in talk because they compile. They showed up in the maint viewer [http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.6.6.280939 3.6.6.280939] notes.
*OBJECT_ATTACHMENT_GEOMETRY_BYTES == 25, returns an integer. Probably corresponds to viewer's RenderAutoMuteByteLimit. Currently always returns -1 for an avatar in the region, 0 for a non-avatar, the usual nothing if the key doesn't resolve.
*OBJECT_ATTACHMENT_SURFACE_AREA == 26, returns a (good question! Right now it's an integer on BlueSteel and LeTigre, float on Server and Magnum). Probably corresponds to viewer's RenderAutoMuteSurfaceAreaLimit. Currently always returns -1 (or -1.0) for an avatar in the region, 0 for a non-avatar, the usual nothing if the key doesn't resolve.
--[[User:ObviousAltIsObvious Resident|ObviousAltIsObvious Resident]] 15:28, 13 September 2013 (PDT)

Revision as of 15:28, 13 September 2013

Caveats state - "An empty list is also returned if the key given was an item in inventory (object or agent)." How exactly can you have an agent in inventory? -- Eddy CUBE jpg.jpgEddy (talk|contribs) 05:46, 20 August 2009 (UTC)

Never mind. Just slightly confusing grammar (fixed). -- Eddy CUBE jpg.jpgEddy (talk|contribs) 05:50, 20 August 2009 (UTC)

Script time: seconds per what?

What, exactly, is the value returned by OBJECT_SCRIPT_TIME? "The total amount of average script CPU time used by the object or agent, in seconds"; but over what period of time is that measured? Per frame? Per second? Surely not the entire lifetime of the script? —The preceding unsigned comment was added on 06:38, 9 October 2011 by Pete Olihenge

I think it is likely time used in the last minute but I could be wrong. It may be the same value as "the average script time per frame for the last 30 minutes for all scripts on the object" Viewerhelp:Top_Colliders_and_Top_Scripts -- Strife (talk|contribs) 11:03, 11 October 2011 (PDT)
It would be nice to pin this down to something specific, but I guess it can only be used as a comparator for now. Thanks. Pete Olihenge 11:41, 11 October 2011 (PDT)
Wot? Maestro put it all right on the OBJECT_SCRIPT_TIME page. It works just like top scripts. Half hour per-frame avg, or per-frame avg since region entry, whichever's shorter. --Incoherendt Randt 13:29, 12 October 2011 (PDT)
Oops! Yeah, I never looked at that. I guess that's as specific as it gets. Thanks, Incoherendt. :) Pete Olihenge 15:47, 12 October 2011 (PDT)

Deeded to Group

I was thinking of adding the following useful snippet somewhere to detect when an object is deeded to group, specifically for determining if an avatar is an object's effective owner, like so: <lsl>integer isOwner(key id, integer groupAdmin) {

   integer result = FALSE;
   {
       key owner = llGetOwner();
       if (id == owner) result = TRUE;
       else { // If object is group owned, avatar need only belong to same group
           integer sameGroup = llSameGroup(id);
           if (groupAdmin) result = sameGroup;
           else {
               key group = (key)((string)llGetObjectDetails(llGetKey(), [OBJECT_GROUP]));
               if (groupAdmin || (group == owner)) result = sameGroup;
           }
       }
   }
   return result;

}</lsl>

I'm trying to decide if this makes sense to add to this article as an example, or if it's better added as a library/user-page function?
-- Haravikk (talk|contribs) 05:20, 10 September 2012 (PDT)

I would put it on llSameGroup or on the group category page. I'm also a bit confused as to how to best use groupAdmin, more comments please? I might suggest a small change: <lsl>integer isOwner(key id, integer groupAdmin) {

   integer result = FALSE;
   {
       key owner = llGetOwner();
       if (id == owner) result = TRUE;
       else { // If object is group owned, avatar need only belong to same group
           integer sameGroup = llSameGroup(id);
           if (groupAdmin) result = sameGroup;
           else {
               key group = (key)((string)llGetObjectDetails(llGetKey(), [OBJECT_GROUP]));
               if (group == owner) result = sameGroup;
           }
       }
   }
   return result;

}</lsl> --Strife (talk|contribs) 13:16, 10 September 2012 (PDT)

Oh sorry, groupAdmin is intended to let members of the object's group all count as owners, so setting it to true means that anyone with same group is an owner, regardless of whether the object is deeded or not. Oh, and thanks for the fix, I shuffled some stuff about a bit before posting since I forgot about LSL's love for evaluating stuff it doesn't need to! I'm thinking that this page, llSameGroup() and llGetOwner() could all use hints for dealing with group deeding, so I might make a page for this code and just link to it instead, or do you think enough people will look to same group first?
-- Haravikk (talk|contribs) 13:30, 10 September 2012 (PDT)
I see your point, llGetOwner makes more sense, with a link on llSameGroup to llGetOwner. A copy of the function also in the Owner category. -- Strife (talk|contribs) 13:40, 10 September 2012 (PDT)
IIRC you can use llGetObjectPermMask to determine extended categories... the move permission should only appear for group when shared (which is required for deeding)... I used this trick to get around deeding for objects that should optionally enable group access, but didn't respond well to deeding (such as things using llOwnerSay, and the money event). AFAIK comparing owner key to group key is the only reliable method of determining actual deeding. That gives you a possibility of up to 3+ access levels [owner | owner + group (with or without limits) | Group]. This means that group behavior can be determined automactically by simply checking the share box or deeding, and no other needed interaction from the original owner
-- Void (talk|contribs) 21:12, 11 September 2012 (PDT)
I completely forgot about the move permission! It's a very nice solution though for objects that are effectively group-owned (which may be fine for some people), now if only we had a direct access function to an object's own group UUID…
-- Haravikk (talk|contribs) 03:36, 12 September 2012 (PDT)

new constants Sep. 2013

These aren't totally implemented on the servers yet, dropping this in talk because they compile. They showed up in the maint viewer 3.6.6.280939 notes.

  • OBJECT_ATTACHMENT_GEOMETRY_BYTES == 25, returns an integer. Probably corresponds to viewer's RenderAutoMuteByteLimit. Currently always returns -1 for an avatar in the region, 0 for a non-avatar, the usual nothing if the key doesn't resolve.
  • OBJECT_ATTACHMENT_SURFACE_AREA == 26, returns a (good question! Right now it's an integer on BlueSteel and LeTigre, float on Server and Magnum). Probably corresponds to viewer's RenderAutoMuteSurfaceAreaLimit. Currently always returns -1 (or -1.0) for an avatar in the region, 0 for a non-avatar, the usual nothing if the key doesn't resolve.

--ObviousAltIsObvious Resident 15:28, 13 September 2013 (PDT)