Profaitchikenz Haiku

Oh well, in that case - We're doomed!

The object worn on the shoulder needs to keep track of the objects it has rezzed: when an object is rezzed it announces it's key on a channel that the shoulder item listens to. The shoulder item keeps a list of the object key and object name. When a new object of that name is to be rezzed, the shoulder item looks to see if it already has an object of that type in the list. If so, it uses the stored key with llRegionSayTo() to tell the first object to derezz. The first object can then either call llDie() when it gets a "your time is up" message, or it can check with the owner if it should obey or persist. If it is told to persist it can then stop listening on the channel so that it won't get further messages to die. The shoulder object will have to remove from the list it keeps any instances that have been told to die. Complicated but mostly by the amount of book-keeping that is needed

Your saying they aren't a thing doesn't make it so in exactly the same way that my saying it's a thing spurs you on to disagreeing with me. Different people in SL have different desires. Saying it's always been like that and there's no hope is just Frazer saying "We're Doomed, Doomed!". In that case, why are statistics built into the viewer in the first place? They have a meaning and a purpose. To some extent, I agree with you, measuring too much of the wrong thing can degrade performance. Measuring enough of the right thing, on the other hand, can help t maintain or improve it.

There is some comfort to be taken from that, it's going to be around for as long as they can keep it paying out, but I agree with you, it gives me a sinking feeling about how much effort will be directed to fixing things that aren't really right but don't necessarily increase revenue.

Animesh hair? Internal organs for mesh bodies to complement the brains I see rezzing before the heads? (Note to others, colour me tongue-in-cheek)

I have no problem with the increase in Premium fees last year, it's important for a company to ensure it is on a sound financial footing if it is to continue. I don't have a problem with the experiments such a Sansar, it's important that a company looks at new direction from time to time. I am glad that things like BoM have been added to SL. Where I am struggling to see how the OP's suggestions could be embraced by us, the great un-herdable kittehs of teh SLife, is with the sustainability and maintainability of the essential hardware and software. I went to a server group meeting a couple of weeks ago because my parcel's region had come to a halt with the "unable to create object that has caused problems in this region" issue, which occurs when (amongst other things) the physics memory usage for the region creeps up over 900 Mb. I hadn't seen this for a long time but my landlord said it's quite common across their estate. It takes several hours until live support can address the problem, depending obviously on when it is noticed by users. I went to the meeting to ask if it would be possible to add the monitoring of this parameter to whatever regular region monitoring is done, in the hope that as the memory use approached a warning level, to either invoke the grid-poking-bot or some other mechanism to address the problem. The answer I got was "It's hard". Whilst there the issue of TP-crashes was also mooted and another of the Lindens present mentioned that they too had had a couple of those instances very recently and therefore they might have to take a look at it. I asked about the monitoring that a now-departed Linden had mentioned was going to be put in place to allow things like TP-crashes to be logged, but it seemed there hadn't been a lot of progress (that we could be told about) in the months/year or so since the idea was first mentioned. I left the meeting realising that well-meaning as the Lindens there were, it was out of their power to do much about the long-standing problems, the older explanations of "how meeroos come about" had now been replaced by "It's hard". There will still be attention paid to very specific Jira bugs, but the general operation was just going along on what I feel is a wing and a prayer. I'm not going to throw my toys or spit the dummy, I shan't storm out of SL for one of the other places, I shan't cancel my premium subscription (yet), but I have no real hope that things are going to get better any time soon, based on what I heard then and at previous meetings, nothing significant has changed since the transfer to a different platform. If there is anything that we as concerned uses could or should be doing to assist SecondLife, it should be making it very clear to Linden Lab that they really should be fixing the broken parts before rushing off into yet another glorious addition such as EEP. Fix the TP-failures, fix the vehicle-region-crossing problems, monitor the regions to catch problems before they halt the region, have a 2-hour response team to address stopped regions, give all regions adequate script performance... If they have the resources to overhaul the web page then they ought to have the resources to try and make sure that the inworld-performance lives up to the expectations the new web page will engender.

This to me sums up the problem: it's creaking. Things that I have been complaining about at Server User Group meetings are now getting worse, not better, and the answers from the Lindens there to my and others inquiries tends to be "It's Hard". I am seeing very erratic behaviour now for scripted moving items that will one week be perfectly-behaved, and the next week will be failing to start or end a movement. If it were always problematic I would accept that it's something in my code that could be improved, but it's random. One week good, one week diabolical. Yesterday I experienced TP-crash-to-desktop half a dozen times. What do we say to new users? "Get used to it" ? So what are we going to trumpet to encourage new users in? Looks good but works erraticly? Don't try TP-ing around on odd-numbered days of the week with a U in the name? If the textures go fuzzy buy a new PC? Sorry for those who agree with the OP, but I see a case of the Emperor's Clothes here.

By default qavimator sticks the files in the "data" folder in the "Program Files" directory entry or wherever you installed it. Having saved it as an AVM file, you then click on the files menu and choose "export for secondlife" to create a BVH. That also by default joins the AVM file in the program files data directory.

I can't help feeling acreage alone is meaningless, surely the content is a meaningful meaningful measure of the world? Anybody with a mind to replicate some film I vaguely remember sleeping through years ago about a race to get a mile of secondhand cars across a desert to a sales lot could just put up a million pinhead islands and demand they have the prize.

I've heard that before, somewhere...

Of all the blights of my life, the GDPR tops the list. Let them breach it so wide no little Dutch boy could stem the torrent,

I'd like inventory folders. It would make it so much easier to organise stuff such as versions of different animations for different states.. It could be implemented in a non-breaking way by having an optional 3rd argument to the inventory functions, if present, it i the name of a folder. If absent, work on the top-level (existing).

"Don't quote me on this..." (At least half the politicians since any form of media existed)

This is what I think is so sad about the rush to "higher quality" in Secondlife. There you are, enjoying yourself and loving your world, and all of a sudden somebody tells you how awful part of it looks, and once you've seen it and accepted their point of view, you can't go back. The magic spell has been broken. It's like being at the theatre watching a magic show and having somebody in the audience constantly babbling on about how the trick is being done.

/me sticks his hand up "Ooh! I know this I know this! Please, I know this!"

/me agrees 110%

I just realised it's not the Z-component you have to to clamp, it's the other tow. It's rotating around the Z axis to follow the the towing object, and then about the X and Y to correct for the height differences, they're the ones that possibly need to be constrained within limits. Also, reading what Quistessa's just posted, I think it's this "shortest angle between the two positions" that's generating the tumbling. ETA Ignore some of what I said above

I'd be tempted to fiddle around with the Z-component of new_rot and limit it to be within Pi/4 radians either side of the vertical position, possibly even less, so that first of all you'll be stopping it tilting too much, secondly, should you actually want the trailer to eventually fall over (assuming the towing vehicle has capsized) it would do so in several stages, sot of simulating inertia? It's a fudge, I know ETA The tumbling behaviour is quite bizarre, it's almost as if it has several choices of the shortest distance and is flipping between them?

Or 3:00 AM eternal?

According to the wiki truncation occurs at 1023 characters. Also in the wiki caveats are some warnings about non-ascii charcters. From recollection these confirmation emails contain a link to be clicked which is often extremely long , I also am not sure you could open such a link in the SL browser to click on it and trigger the validation process, although obviously it could be opened in the external browser, but would the response be satisfactory for Gmail's verification stage, as the details of the responder might not match up with those expected of the object? Can I provide you with a link to http://wiki.secondlife.com/wiki/LSL_Portal a useful resource for this sort of thing.

Not even after you've received an email from the prim and added it to your list of saved addresses? I suppose the acid test first of all is if you can compose an email directly to your prim rather than have the prim send to you and you reply to it. If the answer to that is no, then I can't see automatic forwarding working either. I'll see if I still have my test harness and have a play later when I get inworld.

Edit the green grass, and use the "hollow" spinner on the "Object" tab, but you will then have to make up yet another prim to go directly beneath it otherwise i the water is no-physics you will fll through it and then through the hollow you have just made in the grass. You might end up having to juggle positions around to get the pool dead-centre with the grass

If what you mean is "how can I sink into the blue water, at the moment I just stand on top of it" ? SAVE A COPY to your inventory Edit the object. Select "edit linked parts" All the pool will be highlighted. Make sure that the water is not the yellow-edged part of the build but is in blue (*) Click on the water. Make sure the highlighted selection border is now only around the water Switch to the "features" tab Click in the field "Physics shape type" and change it to "Physics shape None" (*) If the pool has been built with the water as the root prim you will not be able to set it to none in the physic shape, you will have to unlink and relink with the surrounding tiles as the root prim. To do this: SAVE A COPY if you haven't already done so Edit the pool Click on the "unlink" button (the blue highlights should now all turn yellow) Click on the surround of the pool once to turn off the highlighting around it Click on it again to turn the highlighting around the edge back on Click on the "Link" button. The water now should be highlighted in blue and the tiles highlighted in yellow. You can now go back and carry out the steeps to change the prim physics type to None for the water.

Just a thought here, if I've followed the posts correctly, this is more a case of imitation/copying rather than theft? Personally I'd just take it as a case of imitation is a form of flattery. If it really does matter to you, I'd suggest altering the profile post to say that so-and-so is copying you word-for-word and not mention theft.

I think so, both on fewer lines of code, fewer potential spots for bugs, and faster execution. To increment, you would, after having got the number of prims, 1) create a second variable (index) initialised to 1 2) in the while loop test, increment index and then test for it still being less than or equal to the maximum. So that's two extra statements and a more complicated test Whilst the optimizer might condense that into more compact bytecode it would still have to allocate two variables where Molly's solution only needs one. Forgetting the optimiser, (which would be just as efficient at oprimizing programmer errors as it would good code) every extra statement you add to a piece of code increases the chances of errors due to programmer misunderstanding, typing errors, forgetfullness, whatever.