What does OBJECT_GROUP actually mean?

I get the impression that then you call llGetObjectDetails with OBJECT_GROUP, you get the group that the owner had active at the time that the object was rezed. But I have had strange experiences where I changed my avatar’s active group and this caused llSetPos in existing objects to fail to work into areas that worked before the change. Is there any documentation to explain what llGetObjectDetails is returning and what it actually means? Or has someone actually found a use for this and figured it all out?

Sorry, don't know how this got posted twice. Must have been a browser glitch, since I never make mistakes (HA!)

it doesn't work on avatars, only on actual objects.
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llGetObjectDetails

Was it necessary to start two identical threads?

Well, I don't understand how the second one got inserted so I tried to change the title of this one to "ignore me". When I did that, the other one disappeared (including one reply in it, now lost forever?), and this one reverted to the original title.

I'm not using it on avatars, I'm using it inside an object, in the root prim, using the root prim's llGetKey() as the first argument.
This is an object that I've never deeded to a group or even looked at the goup name in the build dialog. So the question is: what group will llGetObjectDetails return? It seems to return the group that the owner had active at the time she rezed the object. But I have had things stop working that acted like the object was no longer a member of the correct group, even while llGetObjectDetails was still returning the correct one. I suppose I'll have to build a simple test and try all combinations of owner active group vs parcel group.

It came back

/54/99/334629/1.html

I found a way to repeat the failure, learned a few things and still have not figured everything out. Here’s the experiment:

1) I set my group to (none), rez a copy of my critter, sit on it and fly over my neighbor’s parcel. I’m not supposed to be able to do that! My neighbor has Object Entry disabled for All Residents! She has it enabled for group, both our lots are in the same group, both my critter and I are sometimes members of that group, but I check and we are both in group (none) or blank now.
2) I realize one of my mistakes: To avoid being laggy, I fetched the critter’s group key once during default state_entry and stored it in a global. It still has the group key of our neighborhood, so my critter thinks it is in the same group and thinks it can fly there. BUT WAITAMINUTE! It works! It can in fact fly there! It is not supposed to be able to!
3) I fly back to my parcel, turn towards my neighbor’s again and jump off of a perfectly good ornithopter. It flies up to the border, thinks it can fly inside, but llSetPos() quietly fails and the critter stalls there at the border. This is the curious failure I had seen earlier. Now I know why an how to fix it. Initialize the global at on_rez time and the critter will know to avoid that parcel.
4) I jump back on, and jump off in the middle of the neighbors parcel. I expect the critter to stall, but it keeps going without me! Apparently llSetPos() checks across a parcel boundary but once inside you are home free.
5) OK, I go home, reset the critter to force it to re-load the global with the new group. I jump on and fly towards my neighbors again. This time the object and parcel groups don’t match, so the critter correctly turns away and refuses to try to go there with me on or off. BUT WAITAMINUTE! I know that if I’m on-board and it tried it could go there! I want to be able to detect this condition and give my critter more options of places it can safely go.
6) By accident, I turn towards a third parcel. My neighbor there has Create Entry and Scripts disabled for all residents and is not a member of our neighborhood group. I’ve never been able to fly there, but this time I can! It turns out that (none) or blank is a valid group, and since he didn’t uncheck any group options, his lot is now a sandbox for me.

So apparently, llSetPos() behaves differently if an object has a seated avatar on it. I’m hypothesizing that it is checking to see if any of the avatar's groups (active or not) are the same as the parcel's and allowing entry. Since there is no way (that I know of) to get a list of all the groups an avatar belongs to, I can’t take advantage of this. But by initializing my global group key in the on_rez event, at least now my critter will only go the places that it is supposed to go, and won't stall trying to go to places it cannot.

I'm coming into this thread late, but this last post prompts a couple of observations:

(1) When an object is attached to you, any restrictions that would apply to it as a separate object ought to be irrelevant. For example, I hope that my prim skirt doesn't fall off or prevent me from flying into a parcel where Object Entry is blocked. My skirt and your critter are attachments, so the rules change.

(2) Coordinates for attachments are local to the avatar they are attached to, so I suspect that if you are trying to apply global coordinates (llSetPos()) to your critter while it's attached to you, you'll have an odd response.

(3) As far as I know, there's no way that an avatar's group permissions will have any effect unless that group is active. The sole exception is that if you have estate owner privileges, you can do pretty much anything whether you are wearing a group tag or not.

I don't know where these lead you, but they may help account for some of the confusion you are seeing.