Profaitchikenz Haiku

I doubt that snippet would have helped since it isn't actually setting a sit target, just counting how many have been set in the link set, but in the particular problem it was a one-prim multi-sit issue, and (as usual) nothing to do with the script but everything to do with encroaching physics shapes. Just as fish (apparently) do not see the water in which they swim and we do not see the air in which we move, when your house is within the physics shape of a giant skybox you don't see it.

Ah ha, so it's the "-" in the key that causes conversion to cease without there being any overflow. Neat. Qie was right then about it being no coincidence the first 32 bits are a distinct chunk?

I'm curious, given an integer in our scripting system is a signed 32-bit, are you saying that an implicit truncation of everything past the 8th character of the (string) version of the key will take place? Or are you saying in your quest for speed, you find dropping the substring call improves performance? LOL., usually it's Rolig who pips me at the post (bad pun, sorry) today I bin Qie'ed @)

Indeed, but it's not easy to control several child prims. In this instance I toyed with suggesting a texture divided into two parts, one brighter than the other half, and switching it instead of using fullbright. However, given that the poster was expressing an interest in working through the children in a linkset, I followed that path. In a sculpty hotel sign I made for somebody that is a single prim but has 12 letters in two vertical columns, the only way to make it flicker through different shades of colour like a faulty neon was to make up a texture consisting of several shades of the blue and then play with the texture offsets via a script, but this was relying on the way textures get applied to the faces of sculpties made using the inworld tools.

Create a single script in the root prim You will need a global integer for how many prims are in the linkset, call this numPrims , also have a global integer called counter , and a global integer called onOff. Initialise counter to 2, onOff to 0; then numPrims = llGetNumberOfPrims(); set the timer interval to what you want, 1 second might be a good starting point. Then wait for the timer to happen Inside the timer() event you first test onOff. If it is 0 you are about to turn on a prim. check the value of counter and if it is greater than numPrims set it to 2; Turn on the child prim using llSetLinkPrimitiveParamsFast(counter, [PRIM_FULL_BRIGHT, ALL_SIDES, 1]); set OnOff to 1; else (onOff was 1 so there's already a prim glowing) turn off the child using llSetLinkPrimitiveParamsFast(counter, [PRIM_FULL_BRIGHT, ALL_SIDES, 0]); set OnOff to 0; increment the counter so that next time it will be tested and either reset to 2 or else the next child in sequence will be set bright. And that's it, the timer event chugs away working through the children as counter gets incremented from 2 to numPrims every second time. It is a 50% duty cycle. If you wanted to change this so the child glowed for longer., then inside the timer loop you would reset the timer interval to either a long value after turning the child on, or a shorter value after turning it off. Don't be afraid to copy code snippets you find in the wiki and chop them around a bit. You need to look in particular at the timer event (how to set it up) and setting primitive params, especially PRIM_FULLBRIGHT or PRIM_GLOW. Also you need to be aware of the link numbering in a linkset. The root prim is number 1, the child prims are then 2,3,4,5... so if there are five prims in a linkset the number of prims returned by the function call will be 5, and therefore the children go from 2 to 5. This can catch people out as they are used to things starting from 0 instead of 1 and ending at 1 less than the total number of notecards, textures etc that the function call returned.

Is there any reason why mesh should be worse than prims when unlinking and relinking?

Nope, got to have a new exciting name like MeWe - BooHoo - but it's the same old ---- under the hood, just re-arranged so that you think it's new and don't realise it's just harder to find what you want to see There's a line in Anathem that seems ever so true "They obsoleted Kinograms - Why? - well, I suppose to get market share"

If this is above the ground level by a significant amount then this is known behaviour, floating point numbers have a finite range of digits, the more you grab to the left of the decimal point the less you have left for the right of the decimal point.

It's amazing we're still here.... I might not be able to illustrate my final (Yes, there will be no more on this matter) investigations, but I decided it was necessary to simplify things to the basics. The OP wants to sit two avatars on a particular object. Many of us have said things like "It's not big enough" or "there's no room". So I decided to see if you could sit two people side by side on a small piano stool, both a prim and a mesh one. After all, if the simulator says you can't do it, no script on earth that runs on that simulator is going to be able to do it. So I started with a prim the size of the intended piano stool, 0.3 x 0.6 x 0.5. In the picture the meshed stool is in the middle with the prim assembly from which it was made outside. Two avatars at on it without even needed a script to give it a sit target. I used a script to make the default position to one side of the bench. Two avatars still sat on it. I made up a prim piano stool and converted it to mesh, giving it a LOW level of detail in the upload and upping the triangle counts a bit but I didn't really care about triangular-degeneration. 0.5LI and L$11 as it's just a Proof-of-misconception Two avatars could sit on it side by side even without a sit-target, I gave it one anyway. The physics shapes of the prim, the mesh stool and the prim assembly look like this. My conclusions therefore are that the OP's problem lies in the mesh object(s) they are trying to work with, since they already have proved the script they want to use works in a mega-prim. They went large, I went small, but the upshot is still the same, the object is the cause of the problem, not the script, nor the server code. In order to be able to sit one or more avatars on an object by a script, you must first be able to sit one or more avatars on the object, full-stop. It is finished - It is finished It is the mercy Phew Can we get up now? I've got splinters in my backside.

In passing, while I was reading up on sit targets yesterday I spotted an LSL function to UPDATE a sit target which apparently worked even if it was being sat upon. Once I've got out of this serbonial mess that is prim-sittability I shall look further I am still trying to grasp the changes that have occurred sometime in the past three years. It now seems you can sit on any prim if it has physics type PRIM, where previously I believed you had to actually give the prim a sit target. It also seems that you can clear the sit target in a prim but what then happens is that you now sit on the prim in the default position. To stop a prim being sittable-upon you either have to give it the scripted-sit-only prim property or you have to set physics to none. So it seems the order of sitting priority is If it has the prim property Scripted_sit_only TRUE && it has a script to sit an avatar on it, sit via script otherwise If is is a Prim and has a sit target, use the sit target If it is a prim and has no sit target or a zero sit-target, use the default sit position for a prim (which I believe might be equivalent to a cleared sit target?) If it is physics none and has a sit target non-Zero, use the sit target If it is physics none and has no sit target or a zero sit-target, no room to sit Going back to the OP's problem I am wondering therefore if parts of the build have no physics. Sitting should only be a pain in the backside if there happens to be a protuberance.

Thanks for going through the steps. No need for a Jira at least.

Yes, in fact I was never able to effectively remove a sit target from the root because it is not possible to set the root to be anything other than physics type Prim. So setting the root prim (linkset in actuality) sit target to ZERO_VECTOR is a wasted activity unless you do some mucking around to change the link set so it can have it's physics type changed. What I think I was seeing is that a prim is able to be sat upon even without a defined sit target provided it is type PRIM, Turning it to type NONE allows you to then specify a sit target of ZERO_VECTOR, but that will only persist while the physics type is NONE. Turning the physics type back to PRIM effectively restores the default sit position and overrides the sit target of ZERO_VECTOR.

I have news: I would be grateful if somebody else could repeat my testing in case my methods were slipshod, but I think there's a jira to come out of this. I don't know if I've missed some announcement, but the TLDR is you can only clear the sit target from a child prim by toggling the physics for that prim to NONE. You obviously cannot do this for the root prim. Turning the physics back to PRIM for a child prim that has previously had the sit target cleared ignores the zeroed sit target and once more permits sitting. Convex Hull works identically to None when changing the physics. Rezz three default cubes, space them apart 2 metres away. Sit on each in turn. Link the two outer ones to the middle one. Sit on each in turn. Drop a script into the two outer ones to set llSitTarget(ZERO_VECTOR, ZERO_ROTATION) Sit on each prim in turn, you still can despite the script. Edit linked parts and set the two outer prims to be physics NONE You can no longer sit on them. Turn the two child prims back to physics type PRIM. You can now sit on them. Turn off physics on the two child prims. Drop a script in each prim to clear the sit target. Prove you cannot sit on the two child prims (but you still are able to sit on the root prim). Drop a script into one child prim to give it a sit target. Sit on each prim in turn, notice you always go now to the child prim you dropped the script in. Drop a script in the root prim to give it a sit target. Try to sit on each prim. Notice the child prim that had no script dropped sits you on the root prim. Tale the child prim that you can currently sit on and change it to physics PRIM. Drop a script in to clear the link target. It can still be sat upon. Change that child prim to be physics NONE. It can no longer be sat on. Drop the script in that child prim again to make sure the sit target is cleared. Change it to Physics PRIM. It can now be sat upon. Tested on Second Life Server 2020-07-01T23:09:05.544419 and Second Life Server 2020-06-12T19:06:40.543526 with SL viewer Second Life Release 6.4.4.543157 (64bit)

The tedious way to solve your problem is to edit the house, edit linked parts, and for each part above the floor you are trying to get to, raise it by adding an amount (say 2.0 metres) to the Z axis figure. With everything above the floor now out of the way, walk up and down. (Still blocked from descending? Ctrl-Alt_T and look or if that shows you nothing, Advanced menu, show bounding boxes or show physics) Then, one by one, edit linked parts and bring each item back down by subtracting the amount you added to the Z-axis figure, until you have identified the guilty prim. A quick fix once you have seen which one is doing the dirty is to edit linked parts and in the features tab set the physics type for that prim to NONE and see if it lets you go down the stairs and also doesn't now let you fall out of the upper storey.

Ah, now I do remember seeing that discussion about scripted sit only, I must have been having a senior moment and not taken it in. So things are indeed different. Thanks for the memory-jog.

Thanks old Bean, I need all the help I can get these days. I have just had a very confusing session in the sandboxes. I created three prims, with no defined sit target in any of them, and was able to sit on each of them. I then remembered to turn off the built-in AO, but I was still able to sit on any of them, and sit on the surface, not halfway into the prim. So I linked them with them 2 metres away from each other and found I could still sit on each and any of them. Furthermore, and this is news to me, I was able to determine which side I faced by camming to one or other of the faces, and when I then clicked and sat I was facing the camera. So test 2 was to drop a script into the root to clear the sit target, like one does, and here SecondLife lived up to it's best, twice I had the script refuse to save with a message that the region was experiencing upload problems, my avatar started running in place, I was booted out, logged back in, found the script uneditable, logged out, tried again, same result, couldn't even take the objects back to inventory until I had relogged, so I went to the adjacent sandbox and started all over again. Clearing the sit target in the root prim did not affect the ability to sit on any of the three prims. Clearing the link sit targets in the two children did not affect the ability to sit. Moving the three prims together until they were adjacent did not affect the ability to sit on any of them. So the old method of forbidding a user to sit on a prim by clearing the sit target seems to no longer work. I realise, of course, I'm doing this on a TPV, so I suppose before readying the brickbats I have to (draws in a deep shuddering breath) log in with the official viewer? So, resuming on the official viewer (why does the camera controls floater have to be so massive?), I find the behaviour is reversed, when I cam to a face and click to sit, I now have my avatar with the back to the camera. So there's a difference between the viewers for a start. But it gets worse. Throwing a script into each child to explicitly clear the sit target still doesn't stop me sitting on any of them, but now when I sit I am rotated 90 degrees on the Z axis. So, it is no longer possible to explicitly prevent avatars from sitting on a prim of children by using ZERO_VECTOR,ZERO_ROTATION as the sit target? This is certainly a change, and it isn't one I was expecting. And so to the next test, what does the physics type of each child prim do to the ability to sit? Well, possibly helpfully, setting each child prim to physics NONE finally gave the "No room to sit" message. Phew, I can keep the pigeons off the windowsills again. One further test: in one of the two child prims now set to no physics, I give it the standard sit target of <0.0,0.0,0.4. ZERO_ROTATION, and I am once more able to sit on it. BUT, when I click on the root prim, or the other child prim and choose to sit, I now sit on the child prim I just added the sit target to. I can no longer sit on the root prim. I'm now rapidly lurching towards the conclusion that sit targets are broken? I know it's no help to the OP with their particular problem, but it might at least help answer their question about why a script that worked back in 2015 no longer works today : things are not the same. So, for the OP, if you can prove that in 2015 your piano with that script behaved as expected but does not do so today, you have a chance to go to SecondLife and say "Hey, y'all dun broke my thayng, y'all fiicksit, ya hear?" Sadly though, from my experiences with asking them to try and get us back the lost script run time, I fear the answer will be "We sacrified two nekos and a merroo, but the great sim god said 'nyet' "

Legendary in the UK back in the eighties and early nineties were windscreen decals with "Kevin" over the driver's seat and "Tracey" over the passenger's. /me stops and reads back. Did he just do a Yoda there?

Although you could take many of my individual words and re-arrange them to make the above sentence I have never expressed that sentiment anywhere in this post @) In 2012 I bought of the market place a 1 LI mesh table with four chairs that claimed to seat four, but like you I found each time a second sitter tried to join they either got "no room to sit..." or else appeared seated above me and rotated on the Z axis. Qie touched on this earlier in this thread. I made my own meshed version of the table and chairs and developed my own script and got it working reliably. I then moved on to a three-piece suite I had created from sculpted cushions, but this time my script failed to work at all, and no amount of bashing made any difference. I made the sofa and chairs in a different way, and got it working with about 3 out of 4 success rate. Wulfie yesterday gave me several significant pointers as to where my builds had been causing problems, I'm almost tempted to revisit them and blow the dust off. Don't confuse single-prim furniture with 1 LI furniture. It is possible to make a stool table, bench from a tube or a cube with particular prim parameters, they are 1-prim furniture items. Sculpted chairs, sofas etc are also 1-prim furniture items though with a different set of problems to handle, but meshed furniture, though 1 LI, can not really claim to be 1-prim. And now, I have to go and breathe in petrol again or I'll never be able to celebrate the end of lockdown with a trip to the seaside.

Three years of mesh. Sever changes. Lots of things. Many old scripts relied on abusing at worst or ignoring at best proper ways to do things. But mostly. Mesh. mesh mesh mesh. Oz Linden gave an excellent account last year of why when you try to rez something on a mesh surface up in a skybox you get the message "Unable to rez item due to parcel ownership..." or whatever. The physics part of the simulation can't handle mesh in the same way it can prims. Prims have easy physics shapes (apart from the tube-torii-rings). Mesh can have anything from the default best-guess when uploaded to a very precise custom-crafter physics shape, depending on the will and ability of the uploader.

To be more precise, there is not enough space left beside the sitter on the piano stool for another avatar because their physics shape is different when seated, and from what I can glean of the piano itself it is just a giant blob so again, hard to work out where to sit. The workaround to this problem is to add an extra child prim which starts out when not occupied behind and to the left of the player. When sat upon, it goes transparent and repositions itself so that the seated avatar on it is alongside the player, apparently sitting on the bench with them. When the sitter stands up the child prim glides back out to where it can be reliably mounted again. (Ooer Missus).

Correct, this is what most of us have been reiterating, in fact you could assign sit targets to various children in a link set and once happy with the result, remove the scripts. The prim retains any sit target as a prim property, like particles. Thanks for the offer of the script but as you say, it isn't a scripting error, and I have a (reasonable) working multi-sit script of my own that works so long as I make the build such that the bounding boxes or physics allow several sitters to join the party. ETA a moment of doubt, do child prims retain prim properties in the same way that unlinked prims do? Once I've finished crawling under the car and getting facefuls of petrol I'll dash inworld and have a fiddle. Unless some of you sensation seekers out there gleefully lapping up this thread care to do some experimenting?

Try this: Link a 0.2x0.2x0.2 cube to the piano stool, position it at least 1 metre to the left and behind the piano player. Give it a link sit target. Try to sit on it. If necessary move it further left, back and up until you can get a second avatar sitting on it reliably. Then begin moving it closer to where you want, until the "no room to sit" message occurs again. This will at least establish the boundary of where the conflict occurs. I also suggest you try not referring to them as "passengers" as this is leading people's minds along the route of vehicles, which have slightly different issues. You want to add sitters to your build, not passengers.

A caveat here, if you have your inventory sorted by date order, you may well have multiple items which will be scattered through the particular folder in newest to oldest order. If you drag them into a new sub-folder, their date order will not be perpetuated but instead they will be given a new date of when they went into that folder, and the order of appearance there is not predicatable. So you can end up with many copies of an item all with the same name, and now way of working out which is the most recent. I advise appending a two (or 3 if your inventory is really that large) digit number to the name so you can see at a glance which is the newest .

I'm curious to know what you are trying to achieve. Do you want to seat somebody else on the piano stool beside the player, or do you want then perched on the frame of the piano?

Many of us are certifiable