Profaitchikenz Haiku

Abbey ento

Since you are resetting the script after a 180-second timeout, you could simplify it by dropping seconds (which is never initialised so you are trusting to the default value of 0), and in the timer loop, just use time -= 1; then time will decrement from 180 every second, and displaying it will show how many seconds left the player has. In the test for reaching 0 check time instead of ttime. Also, check the wiki to see how long llSetText delays a script, it might be longer than the 0.1 or 0.2 seconds most functions take.

I have a feeling, having very recently tried to use the search function in these forums for myself, that those who rarely post here struggle to work out which forum their question should go in, and attempting a search, as I found out recently, throws up a very odd assortment. My guess was this poster found a thread on animations that seemed close to what they were trying to express, tagged onto it, and so I answered it. By all means tick people off for necro-posting, but I was a usenet rat for years and watched forum after forum decline into small groups of oldbies because they kept picking on new posters who didn't follow some/all of their rules. I don't have too much of a problem with adding to the end of old threads, but then, I'm cantankerous, I even have a sneaking admiration for trolls. I was going to add something a bit more snarkier than above but I then realised, I'm seeing this sort of short-fuse behaviour in many different places, even a model railway forum, would you believe? I think this is the result of months of strain, uncertainty and pressure brought about by the current crisis beginning to surface. So I've decided that I'm going to sleep on things before voicing my opinions in too assertive a tone for the next few months. Have a nice day.

You'll need to describe what sort of AO you have, if it's client-based or worn. Usually detaching and re-attaching a worn AO fixes most problems, and reloading the notecard in a client-AO does the same. As far as I know permissions are not revoked permanently, re-logging should sort that. Have you looked in your mute-list?

Very appealing idea, but you'd have to ban mesh, possibly even sculpts, and I'll be honest, the one thing I don't ever want to go back to is system hair.

I think it was a valid experiment, and they learned a bit about the Uncanny Valley phenomenon. They might also have realised the old truth about what you have in your hand is often better than what you wish you had in your hand.

Well, I ought to say "Groundhog day" but as it's SL, "Meeroo day!"

SL is now full of things people have created or purchased that they love and cherish. These things would have to persist into whatever replacement is being hypothesised. It's no good telling them that over that hill and beyond is the promised land that is filled with wonderful replacements for everything they're going to have to leave behind. The thing that stopped me trying Sansar was mostly that I couldn't take my stuff with me, and I couldn't make my own stuff there. I can't see any commercial benefit to a major rewrite of SL that would have to focus a significant effort on simply supporting what we already have: small incremental improvements cost a lot less and could probably accomplish enough to keep people happy.

Doom has even been ported to Youtube...

They say fish don't see the water they swim in, maybe the gentleman doesn't see the clouds he moves through...

Seriously, it's challenges like this give me a reason to get out of bed each morning.

I suppose you could start indexing all the other threads in a single thread...

I miss the variety you got with people using system avatars and clothes, they were more willing to fiddle with the sliders and vary the appearance. Now, I see clones everywhere I go.

I've experienced this twice, but from the other end, I was the invisible avatar. Somebody IM-ed to ask how I had even made my name tag invisible. I rebaked, relogged, changed viewers three times, they still couldn't see me, but others who came along were able to. I have never been able to repeat this and I suspect it was an issue with the viewer of the person who reported I was invisible, but I have no idea how they ever fixed it.

I have this when I log in on a viewer using an alt that has never logged in on that client before, the cache and chat-log locations get set to default. Once you have corrected the entries in preferences and successfully logged out it should be good for the future. (crash to desktop doesn't seem to save all the details of where you last were, what you had on, ...)

You could try to break up the task into lots of little sub-tasks and use link-messages to communicate between them. You can work around the upper memory limit of 64K this way. The limits them become the maximum number of scripts you can stuff into a linkset. Speed-wise, though, it's going to be a crawler.

This depends on several things, disk access speed (people have reported sticking the cache on an SSD or Ramdisk gives best performance. Size of textures is a big factor, lots of 1024x1024's take a while to throw around the buses to and from disk/Ram/Cpu/Gpu, and then there's how many of them have to be processed. I don't know what the prioritisation or selection or order is, and watching scenes slowly un-grey themselves I can't spot any obvious order.

Something you have put on, sat on, or rezzed is trying to pose you or animate you, but the scripter did not include some of the basic checks to make sure the person to be animated has granted permissions. Sitting on an object usually grants these automatically, as does wearing, but some very old scripts still get things wrong.. It sometimes occurs when you rezz an item in world that is supposed to be worn. The script assumes it has permissions because it assumes it has been attached.

I know, but you're much better at explaining it than I am ETA, I also thought, back in that thread, we established there was no need to change the sit target when avatars piled on?

OK, so if this object is smaller than the combined bounding boxes of two avatars, it could be occluded by them and so any further clicks are meeting the avatars, not the object? Check the rendering info displays

Ah, so just as was suggested at the head of this post, you're running into a bounding box/physics problem, the avatar clicks are meeting something else other than the object containing the script. Turn on physics shapes and/or bounding boxes in the rendering info and take a good look at what's happening. ETA was going to explain on more detail but I think/hope Wulfie's beaten me to it

You're not going to like this, but I have also experienced assets taking a while to load --- On my own locally-hosted standalone. It's not bandwidth, it's not the cloud, it's simply the amount of time it takes the server to access lists of objects in the region and the amount of time your viewer takes to go through the cache and texture those it already knows about. In my case, the problem has worsened recently after I pretty much doubled the number of objects in the region. When I took some of the newer builds back to inventory, emptied trash, and cleared cache then spun around re-caching everything, the time taken to redraw the scenes reduced.

So are you saying that it won't work for the third or fourth avatar, or that it's getting complicated to implement it? ETA MollyMews has posted an example of a single-script multi-sitter in the LSL Library forum, it might be worth your playing around with that to see if it replicates or else solves whatever problem you think you have encountered.

No, I don't, I have no other way of accessing past postings than the search. However, you could try searching for "projector" or "texture", since the item in question is the texture that can be assigned to the light on the particular build tab. Try This thread

@Creative Starfall: Just to clarify what has been said by others, multi-sitting several avatars usually refers to the trick of sitting 2,3 4, (not sure what the record is, 255 - number of prims in the set?) avatars on a single prim, it involves some juggling with local positions and rotations, but it doesn't actually require any modification to the sit target. Your requirement is slightly different in that you have a multi-prim object on which you wish to seat several avatars, all apparently on the same prim. What you are going to have to do is work out where each new avatar should be seated and calculate in advance the local pos and rot for them, in effect, you are working out sit positions and rotations. But as it's a multi-prim build, you will be easiest working out these positions and rotations relative to the root prim. Avatar 1 clicks to sit and is momentarily seated at the sit-target pos and rot for the linkset. You then, in the changed event, detect a changed_link has occurred, work through the link set to see if the number of prims has increased or decreased, if increased, get the uuid of the addition, look for the first vacant set of pos and rot seats you have worked out, and move that uuid to that position. A second avatar clicks to sit, you repeat the procedure but now use the next free seating coordinates. Now comes the difficult part. An avatar previously seated gets up. Changed_link is registered, but now the number of prims has decreased, and your task is to work out which of the seated UUIDs at such and such a position is no longer there, so you can release that set of coordinates for the next sitter. So if there had been four avatars seated and number three does a runner, you have to work this out, and free up the third entry in the list of possible vectors and rotations for the seated. It's not impossible, it's not even particularly difficult to code, but you have to be quite diligent in keeping track of what's where and when it isn't there any longer. Lots of work with list-manipulation required. Sit target is a red-herring here as it's only used in the first instance to allow an avatar to actually get seated.