Can't Get Poseballs/Furniture to Work Consistently?! HELP!!??

[Perrie Juran]

---

Qie Niangao wrote:

---

(I'd feel moderately guilty about following this tangent while the OP chided us for not solving her friend's problem, but I'm still betting that 99% of it will end up being exactly what Pussycat suggested earlier: missed permissions dialogs.)

---

You are right, we have gotten off on a tangent.

Thing is from the OP's description he does know what he is looking for, the "ok to annimate me dialogue".....but maybe not.  And she refers to him not getting "MENU(s)," which maybe we are assuming is referring to HUD's. 

It would be easier to deal with and clear up any confusion if he would post himself.

[Phil Deakins]

---

Qie Niangao wrote:

---

Pussycat Catnap wrote:

Note how the meter is NOT a division of 16 (though About Land is).

---

The meter may be doing something painfully pedantic about how a million bytes isn't a megabyte.

---

Not too long ago, I used to know how check an object's memory useage but I've forgotten how to do it now, so I can't check that what I'm about to say is correct, but I believe it is.

When a mono script limits the memory for itself, the limit is returned for it instead of 64k. So the board may be getting non-64k numbers for some of the scripts it is totalling.

There's a faint bell in my head that's telling me that, even though a script limits the amount of memory for itself, and will only use up to that set limit, 64k is neverthless set aside for it. And if that bell is real, it's you who put it there in a thread some years ago 

The bottom line is, of course, that checking an object's memory useage is pretty much meaningless if a person wants to know things like how efficient it is in terms of resources, and how it might affect a sim's or viewer's performance, etc., which is what those who do check memory useage are wanting to know - and wrongly think they are finding out.

 

ETA: I don't feel guilty about this tangent because, unless the person having the problem posts, and provides info about his system, or does the suggested experiments, the thread topic has pretty much bottomed out.

[Phil Deakins]

You're mistaken in what you said about "times past". The LSL memory functions always returned in exact bytes. In those times only 16k scripts existed, so it would have been pointless having a function to return the memory used if it only ever returned 16k.

Those LSL memory functions are useful to those who are writing the scripts. I don't know of any usefulness for users of the objects. Certainly objects like that board can't use them on other objects. All that board can do is get and total another object's rounded memory useage for each script - either 16k or 64k or a number lower than 64k if the scripter has limited a script's memory.

But, as has been said, memory useage is a non-issue for object users because it says nothing about performance.

 

[Qie Niangao]

---

Phil Deakins wrote:

There's a faint bell in my head that's telling me that, even though a script limits the amount of memory for itself, and will only use up to that set limit, 64k is neverthless set aside for it. And if that bell is real, it's you who put it there in a thread some years ago 

---

Nope, the idea that memory is "set aside" when a limit is set is not my doing. For years now I've been trying to disabuse folks of that unfortunate misunderstanding. It all started because of the "allocated" wording that I think originated with Kelly, but he soon clarified that it wasn't "allocated" in the conventional sense of "malloc" or the like. Rather, it's the script setting a kind of "quota" for itself (to those who remember the early days of timesharing).

Being too close to it, I never considered that laymen could be confused between llGetUsedMemory of the script itself and OBJECT_SCRIPT_MEMORY of llGetObjectDetails of another object; it may not be obvious why only the former can afford to be accurate. It's fine if a script wants to stop what it's doing and go off measuring its memory consumption, but quite a different thing if any ol' self-appointed measuring device can impose the same delay on every other script it encounters. The way scripts execute, it's a very expensive operation to update memory usage constantly, as is painfully evident when using llScriptProfiler.

[Phil Deakins]

I guess that that bell was a figment of my imagination then

[Perrie Juran]

---

Qie Niangao wrote:

---

Phil Deakins wrote:

There's a faint bell in my head that's telling me that, even though a script limits the amount of memory for itself, and will only use up to that set limit, 64k is neverthless set aside for it. And if that bell is real, it's you who put it there in a thread some years ago 

---

Nope, the idea that memory is "set aside" when a limit is set is not my doing. For years now I've been trying to

disabuse

folks of that unfortunate misunderstanding. It all started because of the "allocated" wording that I think originated with Kelly, but he soon clarified that it wasn't "allocated" in the conventional sense of "malloc" or the like. Rather, it's the script setting a kind of "quota" for itself (to those who remember the early days of timesharing).

Being too close to it, I never considered that laymen could be confused between llGetUsedMemory of the script itself and OBJECT_SCRIPT_MEMORY of llGetObjectDetails of another object; it may not be obvious why only the former can afford to be accurate. It's fine if a script wants to stop what it's doing and go off measuring its memory consumption, but quite a different thing if any ol' self-appointed measuring device can impose the same delay on every other script it encounters. The way scripts execute, it's a

very

expensive operation to update memory usage constantly, as is painfully evident when using llScriptProfiler.

---

You are right, the word "allocated" does confuse the layman.  Actually I'm still confused at the moment but that's OK, that tends to be my normal state of mind. 

What I do get here (or at least I think I get it) and it is what I've been getting from this Forum and other discussions for a while now what is more important is WHAT THE SCRIPT IS DOING.

I know I was corrected about this when using open channel for something I didn't need to be.  At least for me I think it's a great example of what we are talking about, what is important is what the script is doing.

Avoid channel zero (PUBLIC_CHANNEL) and set name or id where possible to avoid lag. llListen(0, "", NULL_KEY,"") can be laggy as it listens to all chat from everyone in chat range and so should be avoided.       http://wiki.secondlife.com/wiki/LlListen

There is a full explanation of that in the Wiki.

If only there was a real way to measure a script's impact.  Or maybe there is and I'm missing it.

 

[Qie Niangao]

---

Perrie Juran wrote:

If only there was a real way to measure a script's impact.  Or maybe there is and I'm missing it.

 

---

From within a script it's possible to get an accurate view of its actual memory consumption, either instantaneously or its peak usage over an interval while it's running. One can also get a pretty good estimate of the amount of processor time it's using, but that's tricky to interpret because a freshly-started script will burn a lot more CPU than the same script will after it has run for a while. (Maybe there are also artefacts of measurement, I'm not sure, but scripts just arrived in a sim really do lag the heck out of all the other scripts in the sim, so the effect is real, too.)

As has been discussed elsewhere at great length, most scripts usually lag only other scripts, not viewers and not the sim. There are exceptions. For example, back when everybody was focused on script memory, the concern was that scripts could use so much memory that all processes on the host machine would compete for finite real memory, causing the machine to page to disk, thus dramatically slowing all the sims sharing that host. I think only Lab folks ever knew how common this ever was, what if anything was done to prevent it, or if it still happens today. (I've seen claims that there is now much more physical memory per sim than there used to be, but that is usually cited by folks trying to claim that we should never bother our pretty little heads about too many scripts.)

[Perrie Juran]

---

Qie Niangao wrote:

---

Perrie Juran wrote:

If only there was a real way to measure a script's impact.  Or maybe there is and I'm missing it.

 

---

From within a script it's possible to get an accurate view of its actual memory consumption, either instantaneously or its peak usage over an interval while it's running. One can also get a pretty good estimate of the amount of processor time it's using, but that's tricky to interpret because a freshly-started script will burn a lot more CPU than the same script will after it has run for a while. (Maybe there are also artefacts of measurement, I'm not sure, but scripts just arrived in a sim really do lag the heck out of all the other scripts in the sim, so the effect is real, too.)

As has been discussed elsewhere at great length, most scripts usually lag only other scripts, not viewers and not the sim. There are exceptions. For example, back when everybody was focused on script memory, the concern was that scripts could use so much memory that all processes on the host machine would compete for finite real memory, causing the machine to page to disk, thus dramatically slowing all the sims sharing that host. I think only Lab folks ever knew how common this ever was, what if anything was done to prevent it, or if it still happens today. (I've seen claims that there is now much more physical memory per sim than there used to be, but that is usually cited by folks trying to claim that we should never bother our pretty little heads about too many scripts.)

---

Sometimes I do wish a Linden would speak or write to this topic a little more definitevly.

A lot of what we have are educated guesses as to what is really going on.  And too many tid bits scatterred in too many places.  I've lost track of all the links I've been given or have seen.

But also some information is outdated and/or is based on wrong information.

I'm greatful for people like you who take the time to try to address the subject.

But really, and I have said this before, Linden Lab is investing a lot of resources in improving performance.  I really wonder if they couldn't get a better return on investment by investing some resources and making a concerted effort in educating people about "best practices."

just my two cents

 

[animats]

I had the same problem as a new user - worked once, didn't work again.

Found the solution.

If you get the message "Allow ... to animate your avatar", and you accidentally click on "Block", the object goes on your block list and can never pop up a menu for you again. So the object appears broken.

Fix: Go to People->Blocked, which also has a list of blocked objects, and remove the necessary items from the block list.

[Morgan Rosenstar]

On 14/04/2014 at 7:44 AM, Koriani Ixchel said:

Sometimes they work fine.  No issues.

But other times, they dn't work at all. Either he never gets the "menu" to come up, or he never sees the Poseballs, or when he tries to sit on them they dno't give him the option to.  Or when he sits is the "default SIT" in game (as you do defaulting to sit on any item...).  And no matter what we do, we can't get him interacting with the furniture 'as intended' and then have to go someplace else and try again with different furniture.

Which again sometimes works, sometimes doesn't.

Sometimes the exact same furniture that worked fine one night, doesn't another night.

Its not just furniture that requires group titles (as I sometimes suspected this might have been in..).  But also furniture that doesn't. I've specifically tested this theory, too.

Its not that he has an AO on.  For a long time he had no AO because he had some freebie clothing and the base Avatar.  He only recently got his First AO, and now knows how to turn it off.  But both before and after AO - it was hit or miss in getting furniture to work.

It may come from an outdated engine or a script timing out or a message not poping up.

Would it possible to know what script engines are used in these furnitures? To check it, right-click>Edit on a furniture, then go to the Contents tab and you'll see the scripts.

[JackSinned]

Might not be a relevant issue anymore, this topic itself is a bit outdated  

OP posted this in 2014

[Morgan Rosenstar]

5 minutes ago, JackSinned said:

Might not be a relevant issue anymore, this topic itself is a bit outdated  

OP posted this in 2014

I really should stop playing zombie games, I guess.