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

[Koriani Ixchel]

Evening!  Been struggling with this for awhile now and I"m just stumped.

 

i'm a long year (and years and years) user of SL, and the problem is with a friend of mine - whom I brought to the game a couple months ago.  I'm not having any of these issues, and I never have...so Id on't know what's going on but its getting in the way of his enjoyment of being here.  And that sucks! Cuz its nice to have company! XD

 

In any case, he's finding that its very hit or miss when he tries to interact with Furntiure (with Menus or Poseball Driven Furniture).  Yes, that includes the adult furniutre - but really its any furniture you have to "click on" and then "sit" (or sit on the poseball) for animation purposes..

 

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.

 

He's got the default "linden provided" game viewer, the one that I use.  I have no idea what it is that's going on..or what he needs to fix about his Preferences or somethign maybe?? that would solve this...

 

GAH!! As you can imagine its very frustrating!!

[ObviousAltIsObvious]

there are two common problems, both involve Xpose furniture, that could be contributing.

first, Xpose balls sometimes will not appear on some systems, even if they are there. it will usually work to alt-cam on the furniture, zoom the mouse as far back as it will go, then press Esc. this is really a viewer problem, possibly because Xpose uses senitransparent pose balls. other furniture appears to escape this bug.

second, Me>Stop Animating Me has become "dangerous" around Xpose, this time the bug is on the Xpose side. Stop Animating Me also removes animation permission and Xpose does not recover well. the workaround is to have somebody else sit on that pose ball to reset the permissions, or reset the furniture if you can. if you need to use the Stop Animating Me feature, go to another region that doesn't have Xpose furniture you want to use, or use a scripted animation stopper instead.

[Senobia Xenga]

Is he making sure his AO is off?

 

Sometimes that interferes.

[Pussycat Catnap]

There's a lot of inconsistent posing systems out there right now.

I've noticed that many of the ones that ask for permission to animate you (if I didn't want to give permission, why did I sit on the thing...) won't pop up if my messages are already at the 99+ cap. Instead it just goes into the list there on that little tiny 99+ icon at the top right of the screen.

- Unfornately everything that happens in SL seems to add to that stack. IMs, group notices, and other interactions. So its usually ALWAYS capped at 99.

If its an item that spawns poseballs for you to sit on (pretty rare these days), and those poseballs are not just balls but some kind of sculpty shape... the sculpty might not be rendering fast enough, or the person's rendervolumeLOD might be so low they don't see it unless they're right up against it - and the default setting for rendervolumeLOD is that low...

I've seen one recent item that uses a cylander sculpty for poseballs rather than... prim cylanders... /shrug.

- But also I've only seen that one item in the last 3 years as a piece of furniture that even used poseballs.

 

It is also prossible this person has some animation running from something other than the AO, and its only obvious when sitting. A 'ghost animation' or even an animation in some other worn item.

Might even be wearing something that is looking to animate the sit pose but lacks an idea of what animation to put there... however is as a result over-riding other attempts to animate sit.

 

[Koriani Ixchel]

Yea, ObviousAlts. I thought of that.   Unfortunately, its not consistent across furniture brands or type. As I said, we've used a piece of furniture just fine one night and gone back a week later and he can't get anythign on it to work. 

Now I have noticed xpose is more buggy (and sometimes just plain flips out on ya lol), but we've had the same problem with TNT and most of the others.  But those have also worked sometimes too.

 

And I DID check for AO, and always ask him that every single time. "Is your AO off." And yea I can tell when it is or isn't, really easily.  So that isn't it, at least not anymore. 

 

Advisor:

Ahh I did not know that about the message and cap. I've never shown or asked him about whether he clears out his messages. I know he's so Second Life struggling with the UI and making sense of it, joining groups is somethign we've not yet covered its why I avoid the "groups only furniture" places right now.  I shall defintely check that next time.

 

I shall also check the rendering and LOD. It is entirely possible its just taking him for fricking ever to load the pose balls. I have noticed some furniture where the poseballs end up buggy themselves, stuck into furniture you can't get to etc.  But no, unfrotunately at least in the lands and sites we've been to - all teh fancier stuff still uses Poseballs or Pose Shapes (like hearts..).  So it has not been we've run into a plethora of scenes with furniture we've liked that just didnt' have poseballs.

 

And even those were still buggy.

And even him sitting on the poseballs he actually sees is still buggy.  Like it will ask me to animate my AO, but not him. And he has his off.  He sees teh poseball and he can "sit" but its the default sit.  And if there is another menu option like "Cuddle" or "Love", sometimes its greyed out he can't even pick it.

It is wierdly not-rule consistent .

 

How woudl I check for ghost animations? Just have him do it naked? He does know how to check the "wearing" tab for items I tell him to remove, like alphas or HUDs he doesn't want to see or extra armored clothing or the AO or whatever.

[Qie Niangao]

It really sounds to me as if most of this is caused by not noticing the dialog that pops up when remote-poseball scripts ask for permission to animate the avatar. As Pussycat mentioned, that dialog can get buried in a "99+" chiclet at the upper right corner of the screen, but it's also easy to just miss the dialog until something else pops up and it disappears.

If the script hasn't gotten the sitter response to that permissions dialog, it will leave the avatar in the default sit, and the menu it gives -- if any -- in response to touching the furniture may be different from what other sitters (or non-sitters) see.

I don't know that there's any way to make the viewer's behaviour any more intuitive without switching viewers altogether, and that would be asking for more and different trouble. Perhaps it will help just knowing to expect that dialog and to expect to need to trigger it again if things aren't working and he doesn't remember seeing that permissions dialog.

(Note that furniture without poseballs generally won't need that permissions dialog; that's because someone sitting directly on the furniture grants that permission without needing to be explicitly asked. Really old or primitive furniture may have poseballs linked directly to the furniture, and those don't show the dialog either.)

There may be other problems, too, but I'll bet the permissions dialog causes most of the trouble he's having.

[ETA: I meant to suggest that you watch Develop / Avatar / Animation Info while he's having trouble, to detect any "ghost animations" or other weirdness different from what you see with your own avatar -- all with AO removed, of course. I very much doubt this is related to his problem, however, so this would only help confirm that it's not.]

[Pussycat Catnap]

---

Koriani Ixchel wrote:

 

Advisor:

 

Ahh I did not know that about the message and cap. I've never shown or asked him about whether he clears out his messages. I know he's so Second Life struggling with the UI and making sense of it, joining groups is somethign we've not yet covered its why I avoid the "groups only furniture" places right now.  I shall defintely check that next time.

 

I shall also check the rendering and LOD. It is entirely possible its just taking him for fricking ever to load the pose balls. I have noticed some furniture where the poseballs end up buggy themselves, stuck into furniture you can't get to etc.  But no, unfrotunately at least in the lands and sites we've been to - all teh fancier stuff still uses Poseballs or Pose Shapes (like hearts..).  So it has not been we've run into a plethora of scenes with furniture we've liked that just didnt' have poseballs.

---

/looks around for somebody named Advisor.

They really need to let us change the font-color of our names in the forum badges...

If its furniture you're shopping for - shop elsewhere. There really shouldn't be any furniture for sale left that uses poseballs. Its been obsolete for years. If you see it its a sign the item is just going to be buggy or laggy or otherwise poorly scripted as its coming from someone who is no keeping up to date with changes in SL, and changes in what code works...

If its places you visit then you're kind of stuck as giving up a preferred hangout because they have outdated furniture is not the rest reason to move on (on the other hand, you can slowly make friends with then owner, and then badger them into updating their venue).

 

[Qie Niangao]

---

Pussycat Catnap wrote:

If its furniture you're shopping for - shop elsewhere. There really shouldn't be any furniture for sale left that uses poseballs. Its been obsolete for years. If you see it its a sign the item is just going to be buggy or laggy or otherwise poorly scripted as its coming from someone who is no keeping up to date with changes in SL, and changes in what code works...

 

---

Personally, I vastly prefer no-poseball furniture, too -- the npose engine in particular, for items I'm not scripting from scratch -- but I don't think it's accurate to say all poseball furniture is obsolete. Many creators still prefer the MLPV2 engine specifically because it uses separate poseballs.

After this thread, however, the oft-cited reason to prefer poseballs, supposed newbie-friendliness, seems specious.

(I wouldn't wish xpose on my worst enemy, but I gather some folks still use it, and AFAIK it uses poseballs, too.)

[Pussycat Catnap]

Is it nPose that's the name of what I've been thinking of?

For the last year or two I've noticed more and more furniture that I can just sit on, and a menu pops up asking me to pick a pose, and adjust position.

- When I buy this stuff myself, I edit it and set the default action to sit, and now I can just click the stuff and be happily 'in a pose' on it, and then change my pose from there.

(this new stuff also is notecard configured, which has been great as I often resize the furniture down to my own scale, and then I can just edit every 'Z' value in the notecard by the same amount so I'm not using up memory with saved adjustments.)

 

If you have to use poseballs, I actually prefer the ancient 2000-and-old method of a poseball that's always out there and linked. But then just make it transparent, and give it a default action of sit.

I didn't like the MLPV system as I had it on a number of items in 2009 and 2010 and started seeing them spike up in memory - where a single piece of furniture could be using several mb's of ram. Once I started clearing out that furniture from my land, my FPS shot up...

 

[Phil Deakins]

Balls or no balls - there are pros and cons. I wrote my no-balls system for the beds I sell but I still use balls in the seating that I sell, although I've considered how to go over to no-balls. There are no real problems using no-balls for chairs, because the first person who sits invariablt wants to sit in the middle of the chair. But sofas do have the problem that the first who sits may want to simply sit with their own AO animation and, more importantly, sit in a particular spot, which is not necessarily the spot that the first sitter gets when s/he goes straight into the sofa's animation. And then there's the second person to sit, who may also want to sit in a particular spot which is not the position of the second animation, and so on and so on.

Of course, including the option for the owner to turn the sofa's animations off is easy enough, as long as the seller also writes the system, which is probably not the case with most sellers. I'm just pointing out that there are pros and cons, and that poseballs in furniture are still valid, still used, and still bought.

[Qie Niangao]

Oh, yeah, that refreshed my memory: some of the "newbie-friendliness" of poseballs is said to be about choosing pink or blue and getting it right on the first try without having to fuss with menus nor play que es mas macho with the sofa parts.

Although nPose use seems to be growing, I can't say for sure that it's the one Pussycat is seeing. There are several no-poseball engines now that do much the same things, including at least a couple of commercial ones (AVsitter seems popular), and all of these -- as well as MLPV2 -- have seen a lot of changes in the past few years, so the lead shifts back and forth, and older creations using any of them may be pretty behind the curve.

As far as memory consumption goes, it's pretty difficult to beat nPose's approach for large numbers of animations, because it only loads pose-specific notecard data as needed instead of storing monstrous lists of the stuff the whole time. That said, Lear went to some trouble to slim MLPV2's memory use as well as the amount it reports using when LSL got the relevant functions.

[Koriani Ixchel]

OK well its all well and good to have non-poseball furniture.

 

And I'd love to hear the names of some of these non-poseball furniture vendors (especially the Adult Animation ones please!).

But the fact is, the problem is just as prevalent for my friend on the non-poseball furniture.  the POSEBALLS are not hte problem.  Somethign else is. ANd its whiggy and inconsistent and we are at a loss to try and fix it.

 

THe original problem still stands. Poseballs or not.

He can't get the furniture to work for him reliably or consistently.  He can't get menus to come up (for the non-poseball stuff too).  The furniture either just doesn't act for him, or he gets the menu to come up and then "sits" (or brings up teh menu to sit) on the animated furniture - but nothing animates him. 

No AO on. 

I do the same thing he does, and it works great for me 100% of the time.

He does it and we're talking like 60% of the time its broken..

And as I said, even on furniture he COULD use one night - literally the NEXT NIGHT we went back to the SAME place and the furniture would not work for him  This was NOT-poseball furniture.  But the "new" type.

 

Soooo... any other ideas?

Because its still the same problem buying furniture. If we don't nkow what's keeping him from being able to work it 100% of the time then how can I spend 10 or 20 bucks buying the latest and greatest tech if he can't use it 100% of the time?

 

(And yes still gotta try the suggestions from ya Pussycat..sorry yea I had no idea that wasnt' your handle officialy like some SL designation LOL)

[Perrie Juran]

---

Koriani Ixchel wrote:

OK well its all well and good to have non-poseball furniture.

 

And I'd love to hear the names of some of these non-poseball furniture vendors (especially the Adult Animation ones please!).

 

But the fact is, the problem is just as prevalent for my friend on the non-poseball furniture.  the POSEBALLS are not hte problem.  Somethign else is. ANd its whiggy and inconsistent and we are at a loss to try and fix it.

 

THe original problem still stands. Poseballs or not.

He can't get the furniture to work for him reliably or consistently.  He can't get menus to come up (for the non-poseball stuff too).  The furniture either just doesn't act for him, or he gets the menu to come up and then "sits" (or brings up teh menu to sit) on the animated furniture - but nothing animates him. 

No AO on. 

I do the same thing he does, and it works great for me 100% of the time.

He does it and we're talking like 60% of the time its broken..

And as I said, even on furniture he COULD use one night - literally the NEXT NIGHT we went back to the SAME place and the furniture would not work for him  This was NOT-poseball furniture.  But the "new" type.

 

Soooo... any other ideas?

 

Because its still the same problem buying furniture. If we don't nkow what's keeping him from being able to work it 100% of the time then how can I spend 10 or 20 bucks buying the latest and greatest tech if he can't use it 100% of the time?

 

(And yes still gotta try the suggestions from ya Pussycat..sorry yea I had no idea that wasnt' your handle officialy like some SL designation LOL)

---

This begins to sound like your friend does not have a stable internet connection and/or a low end computer.  (Also it's sounding like you are either going to public places or other peoples homes but that is a separate matter).

Everything we are talking about here is dependent on scripts and scripts are at the bottom of the food chain when we start talking about ALL the information that has to be processed for SL to work.  Assuming that the furniture is working ok, if his computer is still struggling to render textures and other object updates then it can seem to take forever for the HUD and or other things to respond.  They could even conceivably time out.

[Phil Deakins]

You've probably realised by now that none of have the answer to the problem because none of us have ever come across it before. I'm starting to wonder if your friend is just having you on. Unfortunately, you can't see if he is or isn't. If he isn't, there's one thing he can try. Get him to create a brand new alt. Tell him to use the default avatar - nothing added - no clothes or settings changed. And then let him try the animations. If the problem still occurs, then it's probably something to do with what Perie wrote in the post above this one.

 

ETA: I'm adding this after I suggested your friend creates an alt in a post below.

If he creates an alt, You could log in with it and find out if the problem occurs for you. If it doesn't, and I absolutely certain it won't, it's obviously his end of things, as Perie wrote about in a post below, or maybe even some settings that he's changed for his main avatar, but I don't think it will be that.

[Pussycat Catnap]

This is why its always best if people post for themselves rather than their "friend".

 

[Phil Deakins]

---

Qie Niangao wrote:

Oh, yeah, that refreshed my memory: some of the "newbie-friendliness" of poseballs is said to be about choosing

pink

or

blue

and getting it right on the first try without having to fuss with menus nor play

que es mas macho

with the sofa parts.

Although nPose use seems to be growing, I can't say for sure that it's the one Pussycat is seeing. There are several no-poseball engines now that do much the same things, including at least a couple of commercial ones (AVsitter seems popular), and all of these -- as well as MLPV2 -- have seen a lot of changes in the past few years, so the lead shifts back and forth, and older creations using any of them may be pretty behind the curve.

As far as memory consumption goes, it's pretty difficult to beat nPose's approach for large numbers of animations, because it only loads pose-specific notecard data as needed instead of storing monstrous lists of the stuff the whole time. That said, Lear went to some trouble to slim MLPV2's memory use

as well as the amount it reports using

when LSL got the relevant functions

.

---

I started to do that with my stuff and later I thought, to heck with it. If people are so fussy they should learn what is actually being reported, or remain ignorant and limit their choices. I suppose they imagine that they are being clever by checking on the memory but the very act of checking means that they are being exactly the opposite, because the reported amount used bears little resemblance the the actual amount used.

[Phil Deakins]

Good point, Pussycat.

Koriani: Why doesn't your friend post here in this thread? It would be so much better if he did. For one thing, he could post his system specs that are easily obtained from the viewer.

[Perrie Juran]

---

Phil Deakins wrote:

You've probably realised by now that none of have the answer to the problem because none of us have ever come across it before. I'm starting to wonder if your friend is just having you on. Unfortunately, you can't see if he is or isn't. If he isn't, there's one thing he can try. Get him to create a brand new alt. Tell him to use the default avatar - nothing added - no clothes changed. And then let him try the animations. If the problem still occurs, then it's probably something to do with what Perie wrote in the post above this one.

---

Oh, I wouldn't say that I have never seen it, just not in this extreme.

A pose ball is a pose ball is a pose ball is a pose ball after all, whether it's rezzing a hundred meters away from an Intan Dance or a centimeter away from a sex bed.  And in a crowded club I've had HUD's fail to display, animations take forever or fail to start, etc, etc.  And while Server side lag may be coming into play there, I don't think that is necesarily all of it.

[Phil Deakins]

Yes, I meant to this extreme. I frequently can't sit on a piece of furniture I'm making, that has fully functioning animations and system.. I walk a little closer and get on ok, or I try again and get on ok. It's the reported extreme of the problem that I meant. One thing that's reported is that he does actually get to sit on them sometimes but in the default sit animation. So it's not just the SL system briefly prventing the sit.

If it wasn't for the reported fact that he does sometimes sit on a no-balls object in the default sit, I'd think more strongly that he's having the OP on. Maybe he only gets the default sit with poseballs - by intentionally missing the poseballs lol. However, I do feel that it's genuine and that it's to do with what you suggested - low end of computer, etc. If he posted himself it would be much better.

[Perrie Juran]

---

Phil Deakins wrote:

Yes, I meant to this extreme. I frequently can't sit on a piece of furniture I'm making, that has fully functioning animations and system.. I walk a little closer and get on ok, or I try again and get on ok. It's the reported extreme of the problem that I meant. One thing that's reported is that he does actually get to sit on them sometimes but in the default sit animation. So it's not just the SL system briefly prventing the sit.

If it wasn't for the reported fact that he does sometimes sit on a no-balls object in the default sit, I'd think more strongly that he's having the OP on. Maybe he only gets the default sit with poseballs - by intentionally missing the poseballs lol. However, I do feel that it's genuine and that it's to do with what you suggested - low end of computer, etc. If he posted himself it would be much better.

---

If her friend wants help on optimising his SL, yes, it really would be easier to help them if they posted here, system info, speed test, ping test, etc, etc.  Going back and forth through an intermediary is difficult. 

[Pussycat Catnap]

---

Phil Deakins wrote:

I started to do that with my stuff and later I thought, to heck with it. If people are so fussy they should learn what is actually being reported, or remain ignorant and limit their choices. I suppose they imagine that they are being clever by checking on the memory but the very act of checking means that they are being exactly the opposite, because the reported amount used bears little resemblance the the actual amount used.

---

I keep seeing you make this claim, so here is my current script usage according to about land and a script checker. Which of these is off, and in what way, or both? Note how the meter is NOT a division of 16 (though About Land is).

[Perrie Juran]

---

Pussycat Catnap wrote:

---

Phil Deakins wrote:

I started to do that with my stuff and later I thought, to heck with it. If people are so fussy they should learn what is actually being reported, or remain ignorant and limit their choices. I suppose they imagine that they are being clever by checking on the memory but the very act of checking means that they are being exactly the opposite, because the reported amount used bears little resemblance the the actual amount used.

---

I keep seeing you make this claim, so here is my current script usage according to about land and a script checker. Which of these is off, and in what way, or both? Note how the meter is NOT a division of 16 (though About Land is).

---

Because what is reported is actually the amount of memory allocated, not the amount of memory used.

http://wiki.secondlife.com/wiki/Mono

If I can find the link later I'll post it here but there was some discussion about this over in SLU.  At one point in time LL talked about imposing memory limits but decided it wouldn't work.  What they did instead was throw more memory at the problem.

 

[Phil Deakins]

[Ooops. This was a reply to Pussycat - not to Perrie]

I don't know what that board is but the viewer's SCRIPT INFORMATION floater in your pic only counts in 16ks. One LSL compiled script gets 16k allocated to it, regardless of how much is needed, so the tiniest of scripts that does very little work is shown as having 16k of memory allocated to it, which is correct, but it's only actually using a tiny bit of it. The same applies to mono scripts. 64k is allocacted to each of them, and yet each may only be using a tiny amount of memory. It's not the amount of allocated memory that matters. It's how much of it is actually being used. Nevertheless, how heavily it is used is what really matters but we can't get any information about that. You can have the tiniest of scripts that hammers away non-stop, and it will be far more detrimental to performance than a huge script that just sits waiting for someone to click. Memory useage is a non-issue. Script activity is the only issue worth considering, and script size gives no indication of that.

The viewer systems that show those details about the scripts in an object don't show anything useful as far as memory useage is concerned, and neither do they give any indication about how intense the scripts are. So it's useless to check an object's memory and decide that your Slink female feet, for instance, are using 64k of memory. They may only use a few k.

Just out of interest, a new script defaults to mono, and it will show as 64k of memory in that floater even if it's just a few lines. You can see it for yourself. Get a tiny script, such one for setting some floating text. If it's not mono, change it to mono. Then put it in a cube and open that floater. You might think, "How can little floating text be using 64k of memory?", but you'd be wrong to think that, because it isn't.

ETA: For mono compiled scripts, if the person writing the script specifically allocates an amount of memory, then that number will be returned instead of the default 64k. That'll be why that board shows numbers that aren't divisible by 16. But specifying the memory required, making it less than the default 64k, makes no difference whatsoever to how much the script affects things. A script will actually use the same amount of memory for its operations whether or not a number less than 64k is specified. If the amount is not specified, then the rest of the 64k just lays dormant, affecting nothing. I think people only limit the memory because some people think that checking how much memory an object uses provides them with some useful information about how the object might affect performance, and they want their objects to show lower numbers. That's why I started doing it before I decided not to pander to that erroneous idea.

[Qie Niangao]

---

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. Maybe. Otherwise it's just buggy, because About Land has the best data available, and I've never seen it deviate (for long) from what's obtained using the available LSL functions.

A little history here. The LSL script memory functions were intended to do something useful because the script-set memory limit was to determine whether the script "fit" on script-limited parcels and avatars. Then there was great fussing about how LL shouldn't limit creativity by cheaping-out on memory (kind of missing the point that unlimited memory use will end up using infinite memory). That, combined with the messiness of actually implementing the limits on the grid ended up postponing them indefinitely... well, permanently, as far as we know.

So the result of that was that these weird functions set and report what amount to artificial memory limits. They don't actually reduce the script's memory use (except in the disastrous case where they're set too low and the script crashes). They're really more an historical curiousity than anything of value -- and, in fact, just counting scripts is as good an indicator of actual memory use as totalling up the numbers reported by these functions. Maybe better, inasmuch as that doesn't suggest such false precision.

(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.)

[Pussycat Catnap]

http://wiki.secondlife.com/wiki/LlGetUsedMemory

- Implies that it actually returns the correct value for mono scripts.

 

I rezzed a prim, added a script, and put this into it:

default{    state_entry()    {        llSay(0, "Hello, Avatar!");    }    touch_start(integer total_number)    {        llSay(0, "Touched.");        integer used_memory = llGetUsedMemory();llOwnerSay((string)used_memory + " bytes of memory currently used.");    }}

 

And got back:

Touched.
[18:42] Mech Prim: 3876 bytes of memory currently used.

 

So I changed the script for this:

default{    state_entry()    {        llSay(0, "Hello, Avatar!");    }    touch_start(integer total_number)    {        llSay(0, "Touched.");        integer used_memory = llGetUsedMemory();llOwnerSay((string)used_memory + " bytes of memory currently used.");integer free_memory = llGetFreeMemory();llOwnerSay((string)free_memory + " bytes of free memory available for allocation.");    }}

 

And got back:

 

Hello, Avatar!
[18:44] Mech Prim: Touched.
[18:44] Mech Prim: 4388 bytes of memory currently used.
[18:44] Mech Prim: 61148 bytes of free memory available for allocation.

 

It seems to me as if the issue you folks are complaining about was at some point in time fixed. I do know that in years past, these numbers were always in 16kb or 64kb chunks - but that seems to no longer be true. At least for a mono script. I forgot to change the script to LSO and compare.

 Ok... just logged back in and flipped the script's mono checkbox off, then saved it again, and got this back:

Touched.
[18:49] Mech Prim: 16384 bytes of memory currently used.
[18:49] Mech Prim: 15876 bytes of free memory available for allocation.

So LSO still has the issue you folks note for the currently used, and shows how it caps at 16, but shows a small reduction for the avail function.