Jenni Darkwatch

Or use a shadow-enabled viewer looks better anyway. Seriously though... be gentle with prim shadows, they do indeed often conflict in crass ways with shadow-enabled viewers.

~shrug~ I'd actually like a simpler layout myself, for times when i don't build and just chat... that is, if it was possible to switch on the fly. Having to relog? That's useless. But from the (very few) people I guided through the first steps... SL is too complicated, entirely unintuitive and definitely a pain in the ass even for long-time residents.

In my own projects I just iterate, if the call isn't happening too often. If it is a common occurence, I'd keep a list with names and recreate the list if the linkset changes.

Naja, leicht off-topic... aber im Grunde haben die Verantwortlichen in DE damit indirekt zugegeben dass die ganzen Argumente vorher voellig aus der Luft gegriffen waren. Wenn wir AKWs so dringend noetig als Brueckentechnologie benoetigen, wieso koennen dann ploetzlich mirnix dirnix mal 7 abgeschaltet werden? Da wird wohl auch ein teil des Stroms aus dem Ausland importiert, aber trotzdem... da zeigt sich eigentlich ganz gut dass Politiker alles im Auge haben, nur nicht das Wohl des Volkes. Persoenlich wette ich drauf dass, sobald sich die Wogen geglaettet haben, alles seinen alten Gang geht und die AKWs alle wieder ans Netz gehen. Weil... unfaelle kanns ja in DE gaaarnicht geben, das Endlager ist aaaabsolut sicher und so weiter und so fort.

I wish LL would finally get their heads out of their collective asses and start actually adding _working_ privacy/anti-griefer measures. What they have right now is only good enough to get script kiddies. With free accounts it's simply impossible to stop griefers from creating new accounts, regardless of open- or closed source, regardless of hardware- or IP bans. PIOF requirement (but still free play) would possibly limit it to the truly criminal griefers, but it'd probably also kill SL. In my opinion, true privacy would mean adding a few (relatively) simple features: 1. Remember the checkboxes "Limit sound to this parcel"? Add one that blocks sound from OTHER parcels. 2. Add a similar checkbox "Limit objects to this parcel" and "Do not show objects on neighboring parcels". 3. Allow people to return prims that overlap into their land. If there's so much as a hair sticking into someone elses land, it should be returnable by the parcel owner. Also, if land is set to no object entry, that should mean not even a hair of a prim should enter. That's just for starters. An overhaul of the buggy and limited permission system would be nice too, but that's non-trivial. Neither of the options listed above should be terribly hard to implement, but would effectively kill a fair amount of griefing attacks. Alas, LLs history shows that they've got no intention nor interest in protecting their residents in any way shape or form.

The script self-destructs after it's done. I've had cases where it still showed in the root prim after it ran, but that was always a case of the asset servers being slow. IMO it's a good idea to not run this in a busy sim

No need. Void Singer wrote an excellent one. Heres my copy of her code (slightly modified for my own preferences), just drop it into the root prim and follow the instructions: // Kill script, based on a script from Void Singer// All credit goes to Void Singer// and all blame for bugs to Jenni Darkwatch for messing it up. :)//// How to use:// 1. Rez (or wear) object you want to scrub// 2. Drop this script into the root prim// 3. Follow instructions :)integer gIntChn;KillScripts(){ integer vIntCnt = llGetInventoryNumber( INVENTORY_SCRIPT );// llOwnerSay((string)vIntCnt+" scripts in link "+(string)llGetLinkNumber()); string vStrInv; integer i; for(i=0;i<vIntCnt;i++){ vStrInv=llGetInventoryName( INVENTORY_SCRIPT, i); if (llGetScriptName()!=vStrInv && vStrInv!=""){ llOwnerSay("Link "+(string)llGetLinkNumber()+": Removed "+vStrInv); llRemoveInventory(vStrInv); } } llOwnerSay("Link "+(string)llGetLinkNumber()+": Had "+(string)vIntCnt+" scripts, now "+(string)(llGetInventoryNumber( INVENTORY_SCRIPT )-1)+" scripts."); llRemoveInventory( llGetScriptName() );}default{ state_entry(){ if (2 > llGetLinkNumber()){ integer vIntCnt = llGetNumberOfPrims(); while (1 < vIntCnt){ llGiveInventory( llGetLinkKey( vIntCnt-- ), llGetScriptName() ); } llOwnerSay( "Take me to Inventory and ReRez me to finish the process." ); }else{ KillScripts(); } } on_rez( integer vInt ){ if (2 > llGetLinkNumber()){ llOwnerSay( "Please select this object, then go to the Build menu and 'Set Scripts to Running in Selection' to finish removing the scripts." ); llSetScriptState( llGetScriptName(), FALSE ); llSleep( 2.0 ); KillScripts(); } }}

What OS, GPU, CPU etc.pp? Would be helpful to know.

ARC is pretty meaningless, in my not at all humble opinion. It gives an idea how GPU-intensive it is to render a specific avi, nothing more, nothing less. Perople already have a tool to make sure they get decent FPS in busy venues: Limit the number of avatars rendered. It may not look as "pretty" but it is guaranteed to get FPS up. My bigger gripe are script-heavy avis, usually people who aren't even aware that they basically lag the sim to hell. That's the same people who complain about sim crossings, teleport problems etc.pp., so in a sense they get what they deserve - IF they'd actually KNOW that they lug gobs of scripts around. Here's a free fullperm script, inspired by code from Void Singer. Drop it into a prim, attach the prim to your HUD. I have mine sized x:0.1, y:0.2, z:0.01 and attached to the bottom center of my HUD. Or pick up a free copy here: http://maps.secondlife.com/secondlife/Dura/83/245/33 It's not meant to be the perfect script, and it has a few limitations: Only the closest 16 avis get checked every 10s, and only about the top eight or so worst offenders of these 16 get shown. I made that decision so it wouldn't create additional lag in busy venues. And it has a harmless bug or two. list lTemp;key kTemp;string sTemp;string sHoverText;string sDisplayName;string sUserName;key kDisplayQuery;integer iIsActive=TRUE;// ===================================================================// Try to force-get display namestring uGetDisplayName(key kAvi){ integer i=0; do { i++; sDisplayName=llGetDisplayName(kAvi); if(sDisplayName=="???") llSleep(0.2); } while(sDisplayName=="???" && i<3); return sDisplayName;}// ===================================================================// MAINdefault { state_entry() { llOwnerSay("Area scan enabled. Scan interval: 10sec. Click green bar to disable."); llSetColor(<0.0, 1.0, 0.0>,ALL_SIDES); llSetText("Initializing...",<1.0, 1.0, 1.0>, 1.0); llSetTimerEvent(10); } no_sensor() { sHoverText="-=> SCRIPTS/MEM <=-\n"; if(llGetAttached()) { sHoverText+=uGetDisplayName(llGetOwner())+": "; sHoverText+=llList2String(llGetObjectDetails(llGetOwner(),[OBJECT_TOTAL_SCRIPT_COUNT]),0)+"/"; sHoverText+=(string)llFloor(llList2Integer(llGetObjectDetails(llGetOwner(),[OBJECT_SCRIPT_MEMORY]),0)/1024.0)+"k\n"; } llSetText(sHoverText,<1.0, 1.0, 1.0>, 1.0); } sensor(integer foo) { lTemp=[]; do { kTemp=kTemp=llDetectedKey(foo = ~-foo); lTemp+=llList2Integer(llGetObjectDetails(kTemp,[OBJECT_SCRIPT_MEMORY]),0); lTemp+=llList2Integer(llGetObjectDetails(kTemp,[OBJECT_TOTAL_SCRIPT_COUNT]),0); sDisplayName=uGetDisplayName(kTemp); sUserName=llKey2Name(kTemp); if(llSubStringIndex(sUserName," Resident")!=-1) sUserName=llGetSubString(sUserName,0,llSubStringIndex(sUserName," Resident")-1); if(sUserName!=sDisplayName) lTemp+=sDisplayName+" ("+sUserName+")"; else lTemp+=sDisplayName; } while(foo); lTemp=llListSort(lTemp,3,FALSE); sHoverText=""; if(llGetAttached()) { sHoverText+=uGetDisplayName(llGetOwner())+": "; sHoverText+=llList2String(llGetObjectDetails(llGetOwner(),[OBJECT_TOTAL_SCRIPT_COUNT]),0)+" scripts / "; sHoverText+=llGetSubString((string)(llList2Integer(llGetObjectDetails(llGetOwner(),[OBJECT_SCRIPT_MEMORY]),0)/1024.0/1024.0),0,-5)+"mb memory\n~*~\n"; } else { sHoverText+="Name: Script count / Memory use\n"; } do { sTemp=""; sTemp+=llList2String(lTemp,2)+": "; sTemp+=llList2String(lTemp,1)+" / "; sTemp+=llGetSubString((string)(llList2Float(lTemp,0)/1024.0/1024.0),0,-5)+"mb\n"; if(llStringLength(sHoverText+sTemp)<254) sHoverText+=sTemp; lTemp=llList2List(lTemp,3,255); } while(llGetListLength(lTemp)>0); llSetText(sHoverText,<1.0, 1.0, 1.0>, 1.0); } timer() { if(iIsActive) { llSensor("","",AGENT,96,PI); } else { sHoverText="-=> SCRIPTS/MEM <=-\n"; if(llGetAttached()) { sHoverText+=uGetDisplayName(llGetOwner())+": "; sHoverText+=llList2String(llGetObjectDetails(llGetOwner(),[OBJECT_TOTAL_SCRIPT_COUNT]),0)+"/"; sHoverText+=(string)llFloor(llList2Integer(llGetObjectDetails(llGetOwner(),[OBJECT_SCRIPT_MEMORY]),0)/1024.0)+"k\n"; } sHoverText+="AREA SCANNING IS OFF!"; llSetText(sHoverText,<1.0, 1.0, 1.0>, 1.0); } } touch_end(integer p){ if(llDetectedKey(0)==llGetOwner()){ if(iIsActive) { llOwnerSay("Area scan disabled."); llSetColor(<1.0, 0.0, 0.0>,ALL_SIDES); iIsActive=FALSE; } else { llOwnerSay("Area scan enabled."); llSetColor(<0.0, 1.0, 0.0>,ALL_SIDES); iIsActive=TRUE; } } } attach(key id){ if(id) { llResetScript(); } }}

I don't think agreeing on everything is necessary for friendship. There has to be enough common ground to make it work I think, but agreeing on everying is probably impossible anyway.

The guide is a great starting point, but there's an inaccuracy as near as i can tell: Lots of prims on a sim DO NOT contribute to lag if they're phantom. Textures get transferred from the asset servers, but that _should_ not lag the server, especially not with HTTP texture transfers.

That might be related to a bug I am trying to nail: When muting _any_ sound channel, FPS drops to near nothing. On the other hand, just lowering the volume to a hair doesn't do that...

I'd like to add that people who don't have Viewer 2 can also check script count, albeit not as detailed, via free scripts in-world. There are a number of free fullperm ones. Unlike the Viewer 2 script count these free scripts only give totals though.

Usually I don't care much if anyones hair has 2 or 200 prims. There's always the option to turn down the number of simultaneous avis on screen, which will greatly improve frame rate. Scripts on the other hand... I passionately despise badly written, memory- or script cycle hogging scripts. I still see people lugging around 20MB worth of scripts or more - and these same people often complain bitterly that their TPs fail, sim crossings suck etc.pp.

Depends on the security device really. As a customer, I'm always checking if there's some sneaky devices trying to get more information than I'm willing to part with (and my proxy then feeds them whatever I feel like). With store owners employing that kind of invasion of my privacy I'll never, ever do business. That kind of device is the only one I do object to. Everything else if it's not annoying or harrassing like some of the stupid greeters popping up dialogs... no chip off my shoulder.

I totally agree that dedicated griefers will always get around any ban, even hardware- or IP bans. It's more a convenience option. After all, they can even get around age-verified or PIOF requirements fairly easily. The idea is to NOT expose alt info and such to end-users, while giving current users of "alt-detecting" and "copybot-detecting" system the illusion of protection. Any better protection would require a more fundamental change that's simply never going to happen. Like, if I set my land to access only by group members, its contents shouldn't even render for anyone else. Technically feasible, practically never going to happen with LLs abysmal track record.

Running the SL client without any desktop environment might give you one or two FPS more. In your case, it's indeed a GPU issue. Depending on your CPU, memory and available PCIe slot it might be possible to upgrade successfully. A while ago I built a system for someone specifically for SL: AMD 64 X2 5200+ 2GB RAM nVidia 9600 GSO/512MB Kubuntu 10.10 Kirstens S21 build 5 gets ~30fps on it in most areas, drops to ~15fps in very busy venues, with settings on "High" and some custom tweaks. Desktop effects are disabled, of course, as are all services and components not needed to run SL. The system very rarely swaps, auto-updates on each boot etc.pp. I did not, however, run SL barebones on X, nor did I choose a low-ressource DE. Not worth it for gaining 1-2FPS more.

With the submitted media black/whitelist patch hopefully neutering all these alt-detector piles of junk I think it's now time to think about something else, too: The "ban" options we currently have are totally, utterly, ridiculously pathetic. Ban by name? Sheesh. Gimme a break, even ancient IRC did better than that. I think it's time that land renters (after all we don't really "own" anything in SL - LL owns it) get some better tools for banning people. If I ban someone, at the very least I'd like a few checkboxes: "machine ban" and "IP ban". These two, I think, should be reasonably easy to add. The idea is that I can ban, say, "Jane Doe", then check the two boxes, and without me ever seeing her IP or machine hash, have everyone banned who matches her current IP and/or hash. An additional bonus would be a checkbox "Only allow viewers from the TPV registry". I'm aware that this doesn't actually help one iota with copybotters or dedicated griefers, but it should help getting rid of idiots. And possibly provide a nice cozy false sense of security for some.

At this point in time it's a custom-built Kirstens for me. It's not anywhere near what I'd consider an ideal viewer, but it's certainly closer for me than v1.x. And it runs very well for me with shadows+projectors, almost making SL look decent. To me, stability and decent performance on my OS of choice are most important. Looks are second, tied with usability. All viewers I ever saw flunk usability, big time. Whoever designed v1 and/or v2 really missed all UI design classes, or didn't learn anything new after 1995. In the past I got burned by Emerald, which is why I won't touch Phoenix or Firestorm. Cool Viewer always has been a favorite of mine, despite an especially fugly UI/menu system. If Henri ever makes a v2 I might give it a try. The original LL viewer is always an option, too.

First off, not enough info Therefore, some guesses. Ubuntu uses open source drivers by default. If it's nVidia or ATI, the open source drivers are junk (I'm being polite). Install the closed-source drivers instead if you haven't done so already. Next possible culprit: 3D Desktop effects. If you have them, try disabling them. It gives a few FPS on mid-range hardware. As to why you don't hear much about Linux+SL... well, Linux is a fringe OS, mostly used by geeks & wannabe-geeks. It's not exactly user-friendly, and as your own experience shows it's also not easy to get (some) things running on it.

Nevermind... it now works, after I TPd to another sim... why? Heck if I know. I can reproduce the original issue, but it goes away when TPing. Seems to have to do with editing a script in a worn attachment I think? Don't know.

I've just run into something fairly odd. My script basically sets an attached objects offset with llSetPos when the object is attached. That works so far. What does not work is changing the position with llSetPos after the initial attach event, i.e. if I set a timer event like below, it SAYS the location changed, but visually that's not reflected on my screen: // <snip> attach(key id){ if(id!=NULL_KEY){ llSetPos(<0.0, 0.0, -1.5>); llSetTimerEvent(30); } } timer(){ llSetTimerEvent(0.0); llSetPos(<0.0, 0.0, 0.15>); // This doesn't show visually llOwnerSay((string)llGetLocalPos()); // Even though it sets the coords } // </snip> I can work around that if it indeed cannot be moved after the initial attachment, but... I have the nagging feeling I'm missing something (again).

No. The iPad isn't powerful enough to run a full SL client. AFAIK there is or used to be a text-only client though.

Good points #1 especially... good and sound advice. #2: Minor correction: you can sit on temp rez objects without them booting you off. They simply won't disappear as long as you sit on them. IMO, the whole prim limit thing is a bit silly. The number of prims on a sim is largely only relevant for the Havok physics engine as far as I can see. Client-side, the number of triangles is much more relevant, along with texture count/size.

You do realize that streams have zero connection to Sim performance? You could blow the sim up with a nuke, and the stream wouldn't be affected. As for the prim issue... it pretty much depends on WHAT they rez. If they rez anything that has scripts in it, it'll hit the sim because scripts require initializing. If they use prims that are NOT phantom, it'll hit the sim because the physics engine has to take them into account. If it's non-scripted phantom prims - For an art project I have at one point rezzed a few thousand temp prims (on a private sim) and it had very little impact on the sim. The visitors to the sim had more impact than the temp prims by a long shot. As with most things in SL... its not a cut-and-dry issue.