Jenni Darkwatch

Perrie Juran wrote: What I have seen is some of these script reporters return numbers that were way above what I was wearing. The other Semi-Dumb thing is that most of the time these counters are placed right at the landing points. As I understand it, the greatest impact we have on a SIM (hence causing lag), is when we arive and all our information is being added to the Simulator and sent to all the other Avatars present. In other words, too late. You've already done lagged the SIM. I've not yet seen script counts being wrong, though there's two ways one can query scripts: OBJECT_RUNNING_SCRIPT_COUNT and OBJECT_TOTAL_SCRIPT_COUNT. The total may be significantly higher than the running count. I noticed on your screenshots that you're still running LSL2 scripts (which indeed use 16k per script whether they need it or not)... if you can, recompile them to Mono, it's more sim-friendly these days (and likely uses less memory in most cases even if it displays 64k per script). There used to be a reason to have any "worn" scripts to be LSL2, but that should have been fixed a year or so ago.

If you need a way to compare GPUs... go here http://www.gpureview.com/show_cards.php On the left enter something known to run SL well... say, an Nvidia GTX460.. then set the right side GPU to whatever you're trying to buy and see how it fares. Mobile versions for laptops aren't always listed there - they're generally slower than their desktop counterparts though. Jean is right though, that GPU will at most run SL at low graphics and in busy venues it'll be a slideshow. If you're insisting on running SL on a laptop, get a cooling pad too and install temperature monitoring software. My partner uses SpeedFan for that: http://www.almico.com/speedfan.php (free)

Simple explanation: If many residents are on the sim with plenty of scripts, the scripts will starve each other for Sim time. Vendors will lag or become unresponsive and so on. Hence the limit on script numbers. It's also a metric that easy and quick to assess. Also, the more scripts one has (running or stopped is pretty irrelevant) the longer it takes to fully carry the scripts from sim to sim, which does cause Sim lag. You don't need a script counter - the viewer as a decent one built-in. Script mem use is bogus. If anyone gives you a hard time about that feel free to tell them they're moronic dorkwads. There's one other metric that's sort-of important but difficult to properly measure: How much Sim time a script consumes. Because it's such a pain in the ass to accurately detect via script, most places with script limits simply limit the number of scripts. Unfortunately it's often impossible to know before purchasing if something is scripted well or scripted badly. However: Everything moddable can be easily de-scripted with a script scrubber. So if you have hair or shoes with old ancient color/resize/retexture scripts you can make a copy if allowed and de-script the copy to be much nicer to everyone around you, most notably nicer to the sim

it receives most - but not all - keyboard events when it has focus. It does (last i checked over a year ago) not receive right-button clicks. The former I suspect is/was a bug (I never bothered to bug it). The latter makes sense, since right mouse button also is used for object context menus.

I'm not entirely sure they didn't discuss adding such limits. It's a fine line, even as it is there's still a lot of creators preferring sculpts over mesh because of the lower display weight (when rezzed as prim), especially for large landscaping objects. With textures they can and do futz a little on the client-server communication level, i.e. the client won't always request the full size texture anyway and hence the graphics engine won't display it either. I'd guess that mechanism made it an easy choice: Hamper mesh adoption even more by imposing stricter (if sensible) limits or let some bad practices like monster-sized textures slide? An example would be the obiquitous textboards. Especially the 2-letter per face ones use massive amounts of textures. If they had penalized textures, no one would make 8-faced mesh to replace the much more render-intensive (and physics-intensive) 5-faced sliced and diced box prim. SL has to live with some bad decisions that were made early in its development... I'm not sure there's going to be a good way to fix most of these.

Since that behavior is a flagged as bug, I would be wary of relying on it. The "proper" solution might be to rez two objects (one deeded to group A and the other just set to group B - not necessarily deeded) and have them communicate via direct chat (i.e. llRegionSayTo). That way only the initial handshake needs to be secured, the rest of the communication remains private. One way to secure the connection is this: Both objects have a known channel to communicate on and the same password Both objects send out a RANDOM string on rez, on the comm channel. The first rezzed one of course never gets a reply. Doesn't matter. I'll presume B got rezzed last so it's easier to follow what happens. B sends random string to A A replies with llSHA1String(randomstring + password) sent directly to B via llRegionSayTo. The entire conversation from this point on is on llRegionSayTo() B confirms that the SHA1 hash matches randomstring+password and sends A a confirmation to that effect. At this point, B can be absolutely sure that A is the right object to talk to. A sends a random string to B (basically reversing the process) B replies with llSHA1String(randomstring + password) to A A confirms that the hash matches and accepts B as partner, completing the handshake by confirming success to B At this point, A and B are absolutely guaranteed to talk to the right prim (they have each others UUID too) and not to some impostor, and the password itself got never revealed in chat. The handshake is also safe from replay attacks since it'll never be able to replicate the entire handshake without knowing the password. This process can be simplified of course, I just kept it separate to make a point. It also has one advantage: If one of the two objects has to be reset, the handshake automatically re-establishes the connection.

The official Viewer has no RLV, you'll need to use a third party viewer. RLV is not officially a part of SL.

A VPN can - but doesn't have to - encrypt the traffic going through it. If all you need/want to do is get out of Russia without people knowing what you do and where you go, a VPN is a good idea. However: Unless the chat sent from your client to the SL server is encrypted, the message can _still_ be spied upon by anyone who happens to have the means to intercept the message _after_ it leaves the VPN. To elaborate: Let's presume authorities knock on your door and find out through forensic analysis that your SL username is "Rstan". All they'd need to do is go to the forums and see what you posted. Simply put, _encryption_ should happen on your PC and everything should _stay_ encrypted until your friends decrypt it on _their_ computer. Then, presuming that your PCs hard drive is fully encrypted and preferably your friends is too, you're safe from prying eyes. Unfortunately the whole process can easily make you a suspect to your government simply by using encryption. It's possible to check whether images have embedded hidden messages, steganography isn't exactly safe by itself. On the network level it's possible to find "unusual" traffic patterns, and very easily find anyone who's using standard VPNs (be it IPsec, Tor or anything else). Even using a common port like 443 (HTTPS) doesn't help because the traffic pattern of for example SL use doesn't match normal HTTPS traffic. There's graduations with discoverability insofar as any point-to-point VPN is easy to locate: It has two defined endpoints. One of them is you. Specialty networks like TOR get around this by bouncing the traffic around a bit before sending it out, making it exponentially harder to find the true origin of any given traffic. In essence the government could not know if you were actually doing anything or if you were just a TOR node relaying data for others. For some governments this is enough to convict you, for most others it's not. You can't really effectively use SL through TOR though, it consumes too much bandwidth. This kind of stuff is part of my day job. With expert knowledge it's possible to become very hard (but not impossible!) to track, but SL is very poorly suited to that because of it's relatively high traffic requirements. Likewise unsuitable are most public forums. I could get into more detail but I think it'd just bore everyone to death. TL;DR summary: Can you get in trouble just for using any kind of encryption? If yes, you need much better tools and need to seriously rethink your approach. If merely denying the government proof of what you're doing is enough to be safe, all you need to do is dissociate your RL identity with your online identity. That just requires care and some good anonymizing services. A VPN would be sufficient in this case.

Memory use is indeed bogus as residents can't see the true memory use of any avi or object. Script count is interesting in many different ways: * Scripts have finite time to execute, meaning the more scripts run the more likely it is to cause time dilation on all scripts. * The number of scripts one lugs around affects TPs and sim crossings directly. Those scripts need to be transferred to the new sim, which takes time. Try this: Cross sims over the corners with no scripts... then do it with many scripts. Script time is somewhat in the same vein as script count. It starves other scripts for execution time. At least in theory, scripts should not lag avis. Practically they can insofar as script mem use could cause the sim to start swapping memory. To some extent this also explains why in most cases one single script is superior to having a multitude of scripts. Especially vehicles benefit from this because it makes sim crossings a lot safer.

In SL there's no true end-to-end encryption. Neither on the forums nor in SL. There _used_ to be clients with built-in chat encryption but I don't know if they're still around. I guess what I'm saying is: If you need to privately, securely chat with your friends you will need to use something other than SL. There's fully-encrypted IRC clients for example. A VPN would probably still be convenient to hide _what_ you're doing, though the mere use of a VPN can be detected as well and may very well flag you with authorities.

Torben hat das glaube ich ganz gut auf den Punkt gebracht: 1) Die Trafficzahl wird nur 1x am Tag berechnet, ergo aendert sie sich auch nur 1x am Tag (also alle 24h) 2) Avatare die sich nicht bewegen (unter anderem) werden als Bot geflaggt. "Tanzen" faellt dabei unter "nicht bewegen" da die sich soweit das die Sim sieht die Avatare nicht bewegen. Vor ewigen Zeiten als LL an der Formel arbeitete wurden da mal ein paar Hinweise fallen gelassen, so spielt anscheinend auch eine Rolle ob die Avis reden - keine Ahnung ob voice oder text da einen Unterschied macht.

If you'd like you can use the same system(s) that many RP sims use these days: When avis visit, get their script details as far as thats possible and if above a specific limit, send them a polite notice and flag them. If they keep coming back without changing, ban them. One word of caution: Script time is inaccurate when an avi first enters the sim, as the script state transfer chews up processing cycles. You'll need to at least wait a minute before getting halfway acceptable values. If the avi wears a lot of scripts, the time to settle goes up in a linear fashion as the simulator only initializes scripts at a slow rate (it's a bit more complex than that, but that's kind of the gist of it).

It's worth noting that communication _within_ SL isn't encrypted and obviously neither is this forum. If you need true end-to-end encryption you'll need to use some chat or communication method that uses private key encryption mechanisms. The trick then is to get the key safely to your friend...

Exactly. Scripts aren't downloaded or stored UNLESS you view the source code, of course. Animations ARE downloaded btw, though I forgot whether they're cached or not. Those files are anything but unreadable btw.

"Copybotting", or more accurately making a duplicate of any existing in-world object basically works like this: Anything the viewer has to render has to get sent to the viewer, obviously. This includes geometry, textures, animations and sound. Scripts never get sent to the viewer unless they're mod and can thus be edited. If someone makes a copy, all they get is what the viewer can see. With animations there's some additional problems but it's possible to grab/convert those too. Bottom line: Scripts are supposed to be safe, though there have been exploits in the past that allowed grabbing those as well. At this point in time those exploits are supposedly fixed. Think about it: What does the viewer put in those files in the cache directory...?

1) The SL browser is self-contained, you can't install any plugins into it (well at least not that easily) 2) Why would a page which is supposed to display _your_ webcam feed inworld need an "allow webcam" for people who just want to see your webcam? I suspect you're not familiar with the concept of video streaming on the Internet, nor with Media on a Prim. First, streaming your webcam requires a server component which is able to distribute the video feed to multiple clients. There's free programs that can do that, VLC is one. Second, unless you have a fair amount of upstream bandwidth you'll need to "reflect" your stream off a server with the necessary bandwidth. There's some ad-sponsored systems that allow this, UStream.TV I think does. Then there's the Media on a Prim issue... what others see on that prim _is not_ the same as what you see. If the page captures your video feed that doesn't mean others see that. That's not how the Internet works nor how Media on a Prim works. If others go to the same page, they'd only see their own webcam feed (if they were silly enough to allow capturing their webcam), not yours. A simple experiment proves this: Create a MoaP face with google.com on it. Get a friend to view the media while you go ahead and do some searching on that google page. They won't see anything you do, neither your search nor anything you type. There's pages allowing such a shared experience to a point, but that's not even close to what you want. A common setup for this kind of scenario: * Video capture/streaming client installed on your PC * Video reflector/recoder/whatever else on some server in some center elsewhere * Web page embedding the reflector (or embedding your video stream directly if you have the bandwidth) * People access that webpage and get the encoded video stream (typically h.264 if it's not meant to be realtime, others for realtime low-latency encoding which tends to up bandwidth requirements or lower resolution)

Incidentally, if anyone wants to see if things have been fixed/changed in the latest CHUI build, these links always point to the latest build I believe: Windows: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-chui/arch/CYGWIN/quicklink.html Mac: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-chui/arch/Darwin/quicklink.html Linux: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-chui/arch/Linux/quicklink.html Caveat: These builds may not always be stable

Ustream is a good choice. A word of caution about attached media: The LL viewer default is to disable attached media and only allow it from rezzed media prims. If you're interested in building a following and have places to play: There's quite a few live music venues in SL who are happy to give performers a spot to play. Often performers charge for their appearance, so new performers who'll play for tips are typically welcome with open arms and the tips are likely better. Search for "Live Music" and contact the venues that pop up... make sure they cater to singers/musicians and aren't a DJ venue - for some odd reason some also consider that "live". If you want I can also send you a NC with venues I know of.

Loesungen haengen vom eigentlichen Problem ab. Die Frage ist z.B. ob es ein DNS Problem ist oder ein Routingproblem. Ersteres kann eventuell umgangen werden indem man von Hand einen anderen DNS Dienst eintraegt. Letzteres ist fuer Endanwender praktisch kaum zu umgehen ohne weitere Kosten. Im Grunde waere es schon hilfreich einfach mal die Ausgabe von "ping www.secondlife.com" zu sehen.

I think LL presumes that everyone reads the forums or uses the Dashboard. To be honest, of the handful or so people I know in RL that use SL... I'm the only one who uses it. Even within SL, most people there find out about changes the day they hit them in the face. And you're entirely right, that is indeed mostly LLs fault. The viewer has a homepage on log in, drastic changes like these should be announced there and TPVs should mandatorily have to display an "important messages" feed. On the other hand I am not sure a discussion with all residents is terribly useful. Ten people have at least twenty opinions.

I'd be curious how much impact this has on viewer lag, i.e. how hard it is on the render engine.

FYI, I re-tested it with avis on different server releases. And yep you're right on RC it's definitely not working as intended - at least I can't imagine that's how it's intended to work. Therefore I retract my previous statement and am heading off to eat crow now. Chocolate crow though... don't want to eat an innocent bird

Agreed, the CHUI is certainly not perfect. I think it's generally a step in the right direction, but I expect (as in "expect as a paying customer") that it'll get improvements as time passes. To that end, having a viewable, public JIRA for it is a boon - IF it stays public and viewable. Personally, if I had to make the call - I'd hire Hitomi to help with the UI design.

I can't reproduce it, just tried with a few people. Maybe an artefact of server reboots? Dunno.

How about using a llSensorRepeat instead of a fixed timer? Detecting the object with the given UUID should mean it's rezzed, shouldn't it? I'd think rezzed or not should not matter since the sim knows it's there. What I don't know is if the client has some code preventing sitting on anything the client doesn't see.