Profaitchikenz Haiku

Looking at that, yes, it looks much better for working out where to place an avatar, particularly when there are standing or bending over poses. I'm guessing that you would use something like height - torso-length to determine where the fundament of the avatar is, but as you have alluded to, the thickness of the thighs would be the main determining factor as to how high or low the avatar is to go?

/me refers you to the history lesson that Beau Brummel learned the hard way after using the F-word on a regal personage.

Just had a play inworld to confirm that llGetAGentSize and llGetObjectDetails(avatar, [OBJECT_SCALE[]) return the same value for an avatar. So the OP's request can be simplified to changed(integer change) { if( change & CHANGED_LINK) { key avatar = llAvatarOnSitTarget(); if( avatar != NULL_KEY) { list details = llGetObjectDetails(avatar, [OBJECT_LINK_NUMBER, OBJECT_SCALE,PRIM_POS_LOCAL]); integer avNum = llList2Integer(details, 0); vector size = llList2Vector(details,1); vector where = llList2Vector(details,2); where.z += size.z * 0.5 + size.z * 0.1 + 0.08; llSetLinkPrimitiveParamsFast(avNum, [PRIM_POS_LOCAL, where]); } else // the avatar has left the building } } A quick note to the OP, I have multiplied by 0.5 and 0.1 instead of dividing by 2 and 10, since division is always slower than multiplication because of the way computers do arithmetic.

I had a play inworld and I can see how it simplifies getting the link number of an avatar on a sit target. It doesn't aid in the other method of avatars sitting on objects with no sit target but that's already about as efficient a method as I can make it. Reading through the snippet the OP first started working from I see that the formula is only for an avatar standing, not seated, but then reading through the other constants that llGetObjectDetails can take I was interested to see that Hover_height is available, and that had made me wonder if that would be a better offset to apply to an avatar that is going to sit on an object but appear to be standing on it? So something like half the avatar's height plus a magic fraction plus the hover height?

After sacrificing a Bronie and a Meeroo I was granted a vision by the gods but as far as I understand it, the script requesting this information has to be within the child prim in question, so I can't see how it would work from within the root of a link set. It would be interesting if it could be stuck inside an AO to allow the AO to override it's own sits to allow the scripted sat-upon thingy to do it's stuff. ETA Ok, it makes sense for me now, having got the avatar key, passing that into getObjectDetails with Object_link_number gives us the child index. I see a need for me to simplify some of the multi-sit scripts I've been tormenting some people with for months now, thanks indeed for the pointing-out.

I just went a-looking for that on the LSL portal but was joyless. Neither the constants page nor a search got me anything. I'll try a magic number approach in the hope I can learn something new today, thanks for the heads-up.

That is sort of handy if you want to work out whether the object in question has ever had a sit pos defined and the script then removed, leaving behind just a prim-property (as opposed to zeroing the sit-pos), I suppose, provided you can determine from the returned avatar local position if it is in the default no-sit target position or not. That's easy when you have a bare-bones prim but a lot harder when it's a complex link set. In the case of a multi-sitter scripted object, it's of virtually no value at all, because as you say it's not giving any sequential or positional information. Going back to the OP's question though, I remember a set of magic numbers that allowed you to apply an offset based on the avatar's height, but when I last looked at it, it was unable to take into account extended feet such as Slink, or other bento feet, which lifted the avatar even more than the shoe heel and platform height method. The method I see used more and more is to allow each sitter to adjust themselves via a menu, which of course requires using the second method of getting the link number and avatar local position for applying a subsequent offset.

There are two ways to detect somebody seated on an object, the OP has used the one that is most common, llAvatarOnSitTarget(), but it is also possible to sit on a prim that has no defined sit target. In that case a different method is needed to work out if somebody is sitting in an object. The second method has one distinct advantage over the first, it will return the key of the seated avatar. It is confusing that in order to actually work with a seated avatar, the second method must be used since the first method only gives you a key and then requires additional details. To demonstrate, rezz three default cubes. Put this script inside the first: // test avatar on sit target and highest link number key owner; default { state_entry() { owner = llGetOwner(); llOwnerSay((string) llGetNumberOfPrims()); } changed(integer change) { if( change & CHANGED_LINK) { integer prims = llGetNumberOfPrims(); key avatar = llAvatarOnSitTarget(); string name = "none"; if( avatar != NULL_KEY) name = llKey2Name(avatar); llOwnerSay("Prims " + (string) prims + " seated " + name); if( prims > 1) { key topPrim = llGetLinkKey(prims); vector size = llGetAgentSize(topPrim); vector where = llList2Vector(llGetLinkPrimitiveParams(prims, [PRIM_POS_LOCAL]), 0); if( size != ZERO_VECTOR) llOwnerSay("Seated " + llKey2Name(topPrim) + " at " + (string) where ); } } } } It will give this output when sat on and then stood up from [15:44] testSit: Prims 2 seated none [15:44] testSit: Seated Profaitchikenz Haiku at <0.34000, -0.08179, 0.87997> [15:44] testSit: Prims 1 seated none Notice that llAvatarOnSitTarget() has returned NULL_KEY for both changed events, but checking the highest child number's key is a reliable way of finding out who is sitting, and then allows getting other useful information such as their relative position to the root. put this script inside the second: // test avatar on sit target and highest link number key owner; default { state_entry() { owner = llGetOwner(); llSitTarget(<0.0, 0.0, 0.4>, ZERO_ROTATION); llOwnerSay((string) llGetNumberOfPrims()); } changed(integer change) { if( change & CHANGED_LINK) { integer prims = llGetNumberOfPrims(); key avatar = llAvatarOnSitTarget(); string name = "none"; if( avatar != NULL_KEY) name = llKey2Name(avatar); llOwnerSay("Prims " + (string) prims + " seated " + name); if( prims > 1) { key topPrim = llGetLinkKey(prims); vector size = llGetAgentSize(topPrim); vector where = llList2Vector(llGetLinkPrimitiveParams(prims, [PRIM_POS_LOCAL]), 0); if( size != ZERO_VECTOR) llOwnerSay("Seated " + llKey2Name(topPrim) + " at " + (string) where ); } } } } It will give the following output: [15:51] testSitTarget: Prims 2 seated Profaitchikenz Haiku [15:51] testSitTarget: Seated Profaitchikenz Haiku at <0.00000, 0.00000, 0.75000> [15:51] testSitTarget: Prims 1 seated none It now gets the name of the seated avatar from the result of llAvatarOnSitTarget(), and returns a different local position which has zero offset in the X and Y, as specified in the sit target vector, Finally, in the third prim, put the second script but amend target line to read llSitTarget(ZERO_VECTOR, ZERO_ROTATION); The output is now [15:56] testZEROSitTarget: Prims 2 seated none [15:56] testZEROSitTarget: Seated Profaitchikenz Haiku at <0.34000, 0.05109, 0.87997> [15:56] testZEROSitTarget: Prims 1 seated none Notice that it is now behaving identically to the default prim with no sit target defined. The main reason for using llAvatarOnSitTarget is to get the avatar key to then request permissions to animate etc. However, the most useful information is obtained by querying the highest child prims to test for an avatar in the link set. I am tempted to say that llAvatarOnSitTarget is redundant, since you can still perform all the permission checks using the key obtained by the second method. I am sure somebody will step up and explain why llAvatarOnSitTarget() is still vitally important

The syntax error on the first line is because there needs to be a quantity following PRIM_POS_LOCAL but I cannot see the purpose of this line, for now comment it out. ( Actually, if it were changed to get instead of set and the comma removed after PRIM_POS_LOCAL it would then return something you will be needing to use, the position of the last child prim). If no avatar is sitting on the target, size will be ZERO_VECTOR, so have an if( size != ZERO_VECTOR ) test in there. if size is non-zero, then set agentLinknum to llGetNumberOfPrims(); Having caluclated the adjustment for height, you need to get the avatar's actual local position and then add the offset to that, then use this figure in the set primitive params, so after your float avup, insert vector whereAreThey = llList2Vector( llGetLinkPrimitiveParams(agentLinknum, [PRIM_POS_LOCAL]), 0); whereAreThey += avup; // then use WhereAreThey as the value for PRIM_POS_LOCAL]

If you want to try making it yourself, once the avatar has sat on the sit target, get their position using llGetLinkPrimitiveParams(2, [PRIM_POS_LOCAL, PRIM_ROT_LOCAL]) and then alter the position or rotation , then apply the changes using llSetLinkPrimitiveParamsFast(2, [PRIM_POS_LOCAL, new value, PRIM_ROT_LOCAL, new_value]); People here will be glad to give you help if you get stuck with it. Look through the LSL Portal for help on llAvatarOnSitTarget, and the two other functions I referred to. If you just want somebody else to do it for you then there is an inworld employment sub-forum.

Make sure that the option to allow object entry for the parcel is unchecked for the first thing.

Are you using a VPN? If so, try changing the location it purports to be connecting you from.

I am wondering if this is the significant area: what I think I see is that with a completely empty cache, there is less hesitancy as everything stream in across the network, but with everything cached there seems to be some sluggishness, maybe checking the validity of the textures, maybe checking dates, I can'tr tell, but what I am seeing with the freezing only seems to happen once I have a region cached.

If they're in the cache this shouldn't be an issue., but I have a feeling that what gets sent along the network is enough details about all the textures on the faces for the client to work out if it has it or if it needs to ask for it. It's not easy to work out if the internet is choked or not as a simple speed test only examines your router to ISP link, there are quite a few other bottlenecks between there and the Amazon servers. There are some other threads in other sub-forums that are touching on this and I am now starting to wonder if the number of network requests has somehow increased, because in general the textures on places stay the same, so once they're in cache you shouldn't be needed half the amount of bandwidth to show them.

I'm just trying to get a sense of perspective on this, I don't want to set people off on sharpening the stakes and lighting the torches before climbing the hill to the lofty developer's Frankencastles. The misbehaviour isn't totally predictable. The misbehaviour is specific to certain regions. The regions have a lot of mesh buildings but few avatars The regions in question are fully cached (or should be by now) so the network component is simply the list of what is where and with how much festooned on the surfaces. With all black-box testing, the results nearly always raise more questions than they answer, or at least cause a lot of FUD.

Ok, no signs of freezing in CoolVlViewer in the places where I saw it with the other two viewers. However, the freezing in the places where it had been most observable was less today. Make of that what you will. ETA Correction, just came to a halt for several Second in FS when moving across a room. I noticed that in that period the CPU usage yo-yo-ed wildly from 100% to 0% three times, the drops to 0% were of far shorter duration than the 100% periods.

I have been doing some testing and have the following early results: The latest LL viewer and latest Firestorm both show the CPU spiking. Catzip and Kirstens, which haven't been updated for a while, do not show the CPU maxing out, but instead they show a lot of disk spiking when turning around. They don't freeze up though. Currently I am hypothesising that the two recent viewers I am trying are holding a lot more in RAM and using the CPU a lot more, the two earlier viewers are not using so much RAM and are accessing the cache more? I'd better try with Henri's viewer next.

I have just been playing around with the Linden Viewer but instead of the Windows Task manager I had the Resource Monitor open. In a region with only one other avatar I was experiencing short periods of freezing, even to the point of getting "SecondLife is not Responding" up on the window title bar. This mostly occurred when I was editing, moving around, changing camera focus to look more closely at the build, but there were some instances that seemed totally unconnected to what I was doing. I spotted that the CPU was at 100% in resource monitor during these spells, but was not showing any changes in the task manager process monitor. There were no obvious spikes in network traffic or memory usage or disk usage that aligned with the CPU spikes . Not doing anything for five minutes (and the other avatar in the region wasn't evidently doing much) showed a steady state in all the four areas being monitored. Even a third avatar arriving didn't cause any spiking (but both the other avatars were well outside my draw-distance). I short, I think this is a rendering issue, and it's not a Firestorm one but is going to apply to all viewers. The CPU still gets a lot of tasks before the GPU is given jobs to do and I think this is what is causing the freezing. For my next trick I will try turning off ALM and seeing of that changes the behaviour. ETA Standing up and taking a copy of the object I had been editing back to inventory caused 40-seconds maximim CPU activity that sent the resource monitor window white for half the period, and I wasn't able to click back into the Viewer until the end of that 40-second freeze. Watching the resource monitor for a while longer, doing nothing, there was yet another 40-second freeze period. Resource Monitor clearly indicated it was SecondLife Viewer that wasn't responding. I hadn't done anything, the question is, had either of the other two avatars present being doing anything, and if they had, should they have been able to impact my viewer even when they were well outside draw-distance?

To be fair I wouldn't just point a finger at Firestorm, I experienced this very behaviour last night on the Linden viewer, including being unable to run the cursor to and fro in the box where I was trying to chat in local, cam in and out smoothly, or click on things. It was limited to one particular place, though, TP-ing away cured it. During the problems I was checking Windows task monitor but there was absolutely no sign of any CPU or memory issues, so that ruled out things like Microsoft Security Essentials trying to save me from myself. After it was over I checked the size of the cache and saw no signs that it was bloated. That particular region has never given me such problems in the past.

The more you tell people not to do something, the more they're going to want to try I agree totally about memory being a chimera, but there are times when somebody arriving in a region with tons of scripted attachments slogged it to a standstill for a second or several. (This might have been fixed last year when they changed the "configuration" though.) In general I would say to people that the more compact they can make their scripts, the better, and the less time the script requires to do stuff, the better. As such: Any comparative metric is better than none at all. Even if it's wrong, it still makes people try to think about the problem instead of just push it under the carpet or blame it on the breedables.

If it's not possible to get a cable for the router connection and it's also not possible to move the PC or router closer together, there is a third option which I have managed to make work for a few months while I was in lodgings working away from home. Get a plug-in WiFi extender, these just go into a wall socket and have one or two little antennas on them. Get it recognised by the router and position it as close to the PC as possible (usually the WiFi antenna on a Tower or desktop PC will be around the back), and it should give you a more robust wireless link.

Whatever has happened to the script is fairly recent, as I rent from Ravenglass and a few weeks ago when tier was increased I got a refund just before the new level kicked in. My parcel is on a region of mainland on the main server channel, in case you want to hammer nails into some poor RC's coffin. FWIW I agree totally with Rolig's assessment that this script is far too complicated, debugging it and sorting out where the problem lies could take longer than actually starting out from scratch.

It's a shame the build floater values are in Euler form in that case. I would find it easier to understand the way the three components varied with rotation if those values were the ones displayed. I made a rotation visualiser some time ago with hovertext showing the Euler degrees and quaternian radian values, but it was a bit clumsy to alter in order to watch those transitions. As you say, there is a gimbal effect where X and/or Z values snap through 180 degrees with the variations in the Y axis. That is why I tend to view Y as the governing one of the three.

No! Surely not! Seriously though I remember ages ago reading that rotations attempt to find the shortest path, but from my own experiences moving the Y-axis will often also alter the other two axis values. The order in which you alter the three axes can be significant. As an experiment, try rezzing an object that has values already in the three fields, then rezz a prim, and set the same values into the X and Z fields, then alter the Y value appropriately, and it frequently changes the X and Z values as a result. I am starting to think that you need to be a witch to cope with SL rotations. (Not looking at Tessa, mind you, I was thinking more of Grandma Bates).

Parcel Owners can get more information on all scripted objects in their parcel from the "about land" tab by clicking the "script info" button. This gives the name and location and owner of all scripted objects in the parcel. The way to this info differs from viewer to viewer but in general with the later generation viewers you get the place profile floater from the little i button in the top location field, and then scroll the parcel bar down to see the "about Land" button. Also have a look at some of the TPVs which offer Area Search as another way to locate things in a region.