From Second Life Wiki
Jump to navigation Jump to search

1.125 appears to be incorrect as a way to find true height. I believe 1.1057 gives a more accurate result. --Pussycat Catnap 04:25, 11 September 2009 (UTC)

IMHO the multiplication method stinks to high hell. I would like to see some raw data with different avatar configurations (tall shoes, no shoes, big heads, small heads, long chests, short chests, etc). -- Strife (talk|contribs) 19:48, 11 September 2009 (UTC)

For an accurate result (with just one av) I am using 1.4*vector and am assuming that the size is a result of the distance from the base of the foot to the hip center * 2 or something like that. I have to agree with Strife (again). This whole situation is simply 1/2 baked nonsense. And as a matter of interest why is there no Linden qualifying what the absolute truth is instead of the users having to guess (again)? -- Eddy CUBE jpg.jpgEddy (talk|contribs) 00:45, 14 September 2009 (UTC)

It's hard to get a linden correction unless it's something that causes a bit of trouble on the mailing list or jira. -- Strife (talk|contribs) 17:37, 18 September 2009 (UTC)
I believe that it must always be an estimate because we do not have a standard pose to measure by. Even real people do not measure the same every time because we are squishy! The appearance values in the open source viewers should be good for most uses, the smaller for photographers and the larger for builders. The two are about one inch different so both will be close enough for regular humanoids. Both will be useless for tinies and quads :) --Cerise Sorbet 08:33, 15 January 2010 (UTC)

It is definitely addition and not multiplication, verified against both Cool VIewer and Snowglobe corrections. These constants work well across shapes. --Cerise Sorbet 04:48, 15 January 2010 (UTC)

Thanks for doing all the leg work tracking this one down. -- Strife (talk|contribs) 22:58, 15 January 2010 (UTC)

The peculiar side-effect of using llGetAgentSize() to figure out if an avatar is in the region...

One of the reasons I dislike LSL (or, rather, the LSL library of functions...) is that almost every reasonably complex function has all sorts of side-effects, some of which very interesting, and incredibly useful — and that's why it's so easy for LL to break everything when they fix the intended functionality, while forgetting all about the side-effects...

Today I just came across the specific side-effect of llGetAgentSize(): the ability to quickly figure out if the avatar is in the region or not! 'Quickly', in this instance, means 'no need for a dataserver event'.

While the overall usability of this function is questionable (as the above discussion so well shows!), the ability to figure out if an avatar is in the region or not (without said dataserver event) is very useful!

In my use case, I have the following issue: I have a bot which I want to rez at the touch of a button. But I want the button to only make the call to rez in the bot iff it's not in the region! Thus, I need to see if the bot is online and 'nearby' (well, at least in the same region, so that it can walk towards the button, or something similar). I was attempting to do it with dataserver events (and switching states while waiting for the result, etc.) until, by sheer chance, I stumbled upon this function — which has absolutely nothing to do with checking the online status of an avatar or not! It's just... a very useful side-effect.

As such, I fear that, in the not-so-near future, LL might just remove this function, believing that nobody uses it (because the avatar height measurements are so inaccurate as to be useless), and breaking all those nice scripts that rely on it to get a fast online status...

Granted, you can accomplish the same with llName2Key...

Gwyneth Llewelyn (talk) 13:33, 7 April 2022 (PDT)

Update: no, you cannot use llName2Key — it seems to cache keys of avatars seen in the region, so it might return a valid key... Gwyneth Llewelyn (talk) 08:41, 10 April 2022 (PDT)
Late to the party, Gwyneth <3
Kidding aside, what I do with valid concerns like this, I encapsulate the "endangered" function into a user defined function, in this case integer agent_present(key agent_uuid) {}. That way, I need to change only one instance, if the Lab ever decides to break a function, and implement the workaround there centrally.
Peter Stindberg (talk) 06:01, 21 January 2023 (PDT)