[spinning object; right-click "Buy" then "Cancel"; Object stops spinning]

An addition to Darkies explanation: Omega spins do stop as long as the object is selected. Once it's not selected, it continues spinning. If it does not... congrats, you found a bug in whichever viewer you're using.

[SOPA, PIPA & ACTA - Let's Raise Awareness throughout SL!]

Two small corrections:

1. ACTA is by no means worldwide. The European Union countries didn't sign it, along with some fairly important countries.

2. These laws would only affect the US. Everyone else would just switch to uncensored DNS servers if need be (and probably a lot of Americans will do, too).

Other than that I'd agree, SOPA and consorts are worth opposing.

[Qarl's prim alignment tool for the Official Viewer?]

There's one problem with a lot of the things LL added: They're often inferiorand sometimes quite buggier  to what TPVs have. Not to pick on you specifically, just taking the list you provided as an example:

Avatar Physics: LLs implementation is dependent on viewer performance. Settings rarely look the same on different viewers.
Shared Windlight: Useless, as it doesn't support custom settings. Worse, .wl settings can't even be provided in-game.
Multi-attachments and double-click TPs they did right. Jay.
In-viewer radar: Again, LLs radar is significantly inferior. It's the bare minimum. No (chat/avi distance) range indicators, nothing.

That's exactly the problem. LL has to do it "their way". If a TPV would create the ultimate feature that _every_ customer would want, LL would not add it. Not even if every single customer would petition for it. They'd add some inferior bit of sortof-similar code and just smooth it over. It's how LL operates. Customers are at best dirt under their fingernails. At worst, a bannable nuisance.

Here's an old example for what a lot of customers wanted. A good many customers felt that it's no ones business what viewer people use and what IP address people come from (yes, the RedZone fiasco). TPVs quickly implemented media filters and other protective measures. What did LL do? Nothing worth mentioning, and a lot of sweeping things under the rug until we, the idiot customers, shut up and moved on.

[Having an Object "llDie" when it is away from a Main Build that Rezed it]

Oke, I can't quite make out the code you're using, but you seem to have the right idea. You're probably better off using a timer though. Also, as the wiki points out: Use a negative channel, preferably a large negative channel.

There are a few ways around the problem of having the same build nearby. If the main object rezzes the child objects, you can pass a random number to it, and use that one to communicate. You only need one channel for communication - objects cannot hear themselves anyway, they can only hear other objects.

Another way, if only "owner" is relevant, is to have a statement in the listen event like this:

listen(integer iChan, string sName, key kID, string sMessage) {    if(llGetOwnerKey(kID) == llGetOwner()) {        // This part will only execute if both objects have the same owner    }}

 

[Quick question about texture cache]

SL uses index files to know what file(s) it has already cached.

The cache contains of three subsections:

1) Sound files: WAV audio, 16bits/sec, 44.1kHz) in the root directory of the cache, simply renamed from .wav to .dsf. These sound files are always loaded fully, there's no partial loading going on.

2) Texture files: Stored in the texturecache subdirectory. JPEG2000 format, multiples of 2 in x/y size, ending renamed from .jp2 to .texture. These textures are loaded in fragments, the client queries them in chunks. Unfortunately the cache index sometimes thinks it has the full texture when it really doesn't. In that case you have a texture that never loads.

3) Geometry files: I'm a bit hazy on these, has been a while since I took them apart. They're stored as .slc in the object cache directory.

Caching helps things load faster. A lot faster, not just a few milliseconds faster. It's a shame that SLs texture caching (including TPVs) is so horribly broken. Caching isn't rocket science. Web proxys do it. Operating systems do it. Databases do it. Just SL can't get that pile of dung LL claims is a cache to work right. When LL announced HTTP texture fetch I had high hopes it'd allow using a web proxy. Except LL in their infinitesimal wisdom borked it so that no unmodified proxy will cache SL textures properly, thus negating just about any benefit HTTP texture fetching _could_ have had.

<steps off soapbox>

[mega snow fall]

Also, to increase density and still keep particle count low, create a single texture that has more than one snowflake... i.e. create a 1024x1024 texture and splatter a few (dozen) snowflakes randomly onto it. Then set the particle size to the max 4x4m and you're set to have a fairly impressive snowstorm with relatively few particles.

There's one disadvantage to that approach: People TPing in will first see grey goo. Usually not for long though.

[Prims bigger than 10 meters generate lag as the megaprims?]

If it'd generate lag, we'd all be lagging all over the place. Megaprims have been just about everywhere for years. I never noticed a difference with or without them on any sim.

[Help needed urgently!]

Click on HELP -> ABOUT SECOND LIFE... in the window that appears, click "COPY TO CLIPBOARD" (on the bottom), then paste the contents here. I tend to agree though, either your graphics card does not support shadows, your driver is totally out of date, or you use a viewer that doesn't support shadows to begin with. That "About Second Life" window will answer most of these questions.

[llSetRegionPos]

Btw, the function does not seem to exist in todays' rolled-out RC BlueSteel 12.01.06.247303. A script with that function in it won't compile.

[Impact of SSD drive?]

Been there done that on different OSes. For me, it made a big difference. Maybe for you it makes none. Hell if I know, or care.

[Impact of SSD drive?]

Try running the cache from a RAM disk (or even from an SSD) and form your own opinion.

[small mesh object vanishes when camera is close]

NearClip (thanks for the term, Chosen) is a fact of 3D rendering. However, the value/distance has most definitely changed. It's now further out than it used to be.

[Detecting what's under the crosshair in mouselook?]

At the moment it does not seem to, no. I have a suspicion that it works once or twice per sim, but that the server never replenishes the pool for avis to use the call. See the section under RC_CAST_TIME_EXCEEDED in the llCastRay description in the LSL wiki for how it's supposed to work. Except that it doesn't. There's even a month-old JIRA on the issue: https://jira.secondlife.com/browse/SCR-243

[small mesh object vanishes when camera is close]

It's a relatively new change... I don't know exactly when that changed, but it was somewhere between the release of v2 and now. Not longer than a year ago.

[Detecting what's under the crosshair in mouselook?]

The formula is a leftover from a previous experiment.  As are the brackets. Too bad that they broke llCastRay in attachments... I suppose the only workaround would be rezzing a prim that does the llCastRay and report it back to the attachment. Which of course... won't work in no-rez areas.

Oh well. Time to wait for LL to fix this.

[Qarl's prim alignment tool for the Official Viewer?]

Agreed, they have added some things. Just not very many, compared to the numerous features that people have asked for. Some of which seem trivial to add, some of which probably aren't.

[Q Lag monitors, memory use and mono scripts]

It would be great to get better/improved tools for scripters and land owners to determine what exactly is going on in terms of performance. Not just with script use, but e.g. also with avatar use. For example, you cannot currently get any download weights for avis, while you can get them for all objects easily.

The addition of scripted abilities to get _some_ information is, IMO, a good step in the right direction. That there are limitations and quirks would not be so bad if they were easy to understand.

[Q Lag monitors, memory use and mono scripts]

Nope they do not pick up on that.

[Impact of SSD drive?]

Depends on the OS... what are you using? Windows? Mac? Linux? And what version?

[Detecting what's under the crosshair in mouselook?]

What's the accepted way to detect (by an attachment) what someone is looking at? Right now I use llCastRay, but that fails more often than it succeeds. On my home sim it fails 100% of the time in the last few days, even though the sim has a few ms spare time.

I tried llSensor, but that doesn't seem to follow mouselook, just the general direction the avi points at. The utterly last thing I want to do is rez a tracer.

Edited to add the specific code fragment:

list lHits=llCastRay(llGetCameraPos(),llGetCameraPos()+(<iScanRange,0,0>*llGetRootRotation()),
                           [RC_MAX_HITS,        iMaxRayHits,
                            RC_DETECT_PHANTOM,  TRUE,
                            RC_DATA_FLAGS,      RC_GET_ROOT_KEY,
                            RC_REJECT_TYPES,    RC_REJECT_LAND]);
integer iStatus=llList2Integer(lHits,llGetListLength(lHits)-1);
if(iStatus==RCERR_SIM_PERF_LOW)
    llOwnerSay("Could not detect object, the sim is too busy. Try again later.");
else if(iStatus==RCERR_CAST_TIME_EXCEEDED)
    llOwnerSay("Ray cast failed, cast time exceeded. Try again in a moment.");
else if(iStatus==RCERR_UNKNOWN)
    llOwnerSay("Unknown error during ray cast. This should be reported to LL.");
else {
    // Rarely gets here.
} 

 

[Deferred Rendering and 'shiny' change upcoming in next release]

Thanks for that fix, much appreciated.

[Blender dropping COLLADA support]

The proper solution would be to have a simple mesh editor in the SL client. As well as a simple avatar posing tool. Nothing too complex, just to get the basics back where they belong: Into the hands of the average SL user.

[Impact of SSD drive?]

If you can do so and have the space... create a RAM disk, copy the cache to the RAM drive before launching SL and off the RAM drive when done. If you're on Linux by any chance, look into rsync for doing the copyback. It's faster.

Like previous posters have said: Consumer SSDs still have issues with slowing down on fragmentation, and SLs cache is not very efficient anyway.

[Qarl's prim alignment tool for the Official Viewer?]

I loved the alignment tool... but considering LLs historic refusal to add anything a TPV has developed... I'm not holding my breath for its appearance in the official viewer. Sad, really.

[......and you perfer using a third-party viewers becauce?]

I'm not on TPVs anymore. Emerald used to appeal because it had useful features. After the team outed themselves as a bunch of criminals, I switched to Cool VL Viewer briefly, then Kirstens. Nowadays I'm on LLs viewer. TPVs offer options LL stubbornly refuses to add. What their customers want is rather not what LL cares about. That's one possible reason to use them. The other is that some TPVs run better for some people.

[rant]

Unfortunately, LL and the TPV non-community show exactly how open source development can go horribly wrong. Fixes or even useful features from TPVs very rarely get implemented into the official viewer, regardless of how much sense they make. Everyone forked their own crap and jealously guards it against "competition". Divide and conquer? Not really. More like "we roxors, u suxors" ego trips.

[/rant]