Talk:LlGetObjectDetails
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 (talk|contribs) 05:46, 20 August 2009 (UTC)
Never mind. Just slightly confusing grammar (fixed). -- Eddy (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:
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;
}
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:
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;
}
--Strife (talk|contribs) 13:16, 10 September 2012 (PDT)
- Oh sorry,
groupAdminis 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)
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_RENDER_WEIGHT == 24, returns an integer. Returns -1 for avatar without attachments, a number corresponding to "Advanced>Performance Tools>Show Draw Weight for Avatars" if there are attachments, 0 for non-avatar objects. This does not totally work yet, attachment detection is delayed and sporadic. - could be a rolling average updated about once a minute.
- 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)
- Cool. Thanks for the tip. I knew there was a good reason to read viewer release notes. I'm not going to write documentation just yet, sounds too much like a moving target. -- Strife (talk|contribs) 22:20, 13 September 2013 (PDT)
More from Beta Server Office Hours/Minutes/2013-09-19
[2013/09/19 15:59] Simon Linden: FWIW OBJECT_ATTACHMENT_GEOMETRY_BYTES and OBJECT_ATTACHMENT_SURFACE_AREA are not going to work- [2013/09/19 16:00] Simon Linden: OBJECT_RENDER_WEIGHT will - but requires viewers support it to be present
- [2013/09/19 16:02] Maestro Linden: the server takes the average weights reported over time by all the viewers
[2013/09/19 16:03] Maestro Linden: the server's reported weight will eventually catch up to the stat reported by viewer, if your avatar doesn't change for a while
--ObviousAltIsObvious Resident 02:05, 22 September 2013 (PDT)
- OBJECT_RENDER_WEIGHT is happening. Maestro just documented it. I wonder when it will hit the server release notes. So far this hasn't gotten much press. -- Strife (talk|contribs) 17:37, 17 December 2013 (PST)
- It must have been released in the past as one of those generic "back end support" kinds of updates, waiting for viewer support. I don't think many viewers are providing the data to drive this yet. It got an indirect mention in 13.10.15.282406 for the 500000 cap. --ObviousAltIsObvious Resident 20:53, 17 December 2013 (PST)
- The cap of 500000 has apparently been changed silently. I have just had a return value well above 1,300,000 on an avatar I suspect of wearing a graphics crasher. That's clearly way more than 500000. --Rolig Loon 14:30, 29 July 2016 (PST)