Jenni Darkwatch

I know it should, and does under some circumstances. In the test circumstances, it doesn't... that's the problem. I'm aware of physics alignment. Spin is fine - but it just gets stuck, without ever leaving the prim it's on. At this point I am fairly sure something fishy is going on with the physics between ball and anything else. Your post gave me an idea though. I hadn't tried this with a tilted floor prim... and it triggers too, making the ball slide reaaaaaallly slow-mo down that slope. Again, not expected behavior, though funny to watch. If need be, I can record a video of the different behaviors.

I thought about this and replicated it with friends on different continents and different viewers. As I am on Linux without access to Windows that's usually the first thing I test, as Linux is essentially unsupported, has no Havok and Linux clients are going the way of the Dodo.

With the help of some friends the issue has become a little clearer - and more repeatable, though also more mysterious. Easy steps to reproduce: * Rez a cube, make it big enough to roll a ball around (I just did a 64x64 but we also confirmed this on a 10x5) * For repeatability, rez the Beach Ball from the library (it's scripted to bounce on touch which makes it easier to trigger the issue) * Touch the ball (just tap it, it'll bounce and get stuck) From this point on, the ball will act really strangely, not rolling anymore. If you run into it, it'll just skip weirdly. Definitely not expected behavior. To switch back to expected behavior: * Edit the cube (floor) and toggle its physics to "Convex Hull" and back to "Prim" * Toss the ball with your mouse (pushing it with walk/run should also work at this point) As soon as you tap it, triggering the scripted bounce, it'll get stuck again. Please note that "scripted" isn't a necessity to trigger the bug, it just makes triggering it more consistent. You can also trigger it by tossing it, or by running into it, just less consistent. The key to triggering it seems to be the "bouncing" part. From here on out it gets weird. Rez another cube (or anything else actually) and link it to the floor cube. Et voila. Problem gone for good. As soon as you link anything to the floor the issue disappears. It doesn't even matter which order you link it. The ball will roll just fine on the previously problematic cube prim.

Edit the object, set the correct group, check "Share" then click "Deed". You can only do this if you have deed rights in the group.

The basics: * Rez a box, make it big enough to roll a ball around (10x10m maybe) * Rez a sphere, make it physical (no other changes) Simple enough set-up. What I cannot for the life of me figure out: In some cases, the ball will roll just fine if you walk into it. In other cases... it slows, suddenly stops and spins in place. I see no rhyme or reason to its behavior? What am I missing? Size of the ball doesn't seem to make a difference, size of the prim doesn't seem to make a difference, neither does mesh or prim or physics shape. No scripting involved. The behavior is consistent per instance though. If I rez said ball on a surface where it'll roll fine, it'll ALWAYS roll fine. If I take the EXACT SAME prims to inventory and rez them elsewhere, the ball may or may not fail, spinning in place after rolling a short distance. I even have a stretch of road where it works fine one one segment... and fail and spin as soon as it crosses over to the next segment. Help? Please? De-mystify?

You won't find parcels any cheaper anywhere! Each parcel is only L$ 512 for 1024m²! 7 parcels, connected, so you can: * buy two (at a total cost of only L$1024) and combine them to get 2048m² * buy four (at a total cost of L$2048) and combine them to get 4096m² http://maps.secondlife.com/secondlife/Dudintsev/123/143/66 http://maps.secondlife.com/secondlife/Dudintsev/151/173/66 http://maps.secondlife.com/secondlife/Dudintsev/122/173/66 http://maps.secondlife.com/secondlife/Dudintsev/121/208/66 http://maps.secondlife.com/secondlife/Dudintsev/121/208/66 http://maps.secondlife.com/secondlife/Dudintsev/148/237/66 http://maps.secondlife.com/secondlife/Dudintsev/120/239/66 grab as many as you like. Contact me, Jenni Darkwatch, in-world if you have any questions.

Hi selling 7 parcels (all connected to each other so you can combine them), all 1024m², flat, on Dudintsev, priced at a dirt cheap L$1/m²: http://maps.secondlife.com/secondlife/Dudintsev/123/143/66 http://maps.secondlife.com/secondlife/Dudintsev/151/173/66 http://maps.secondlife.com/secondlife/Dudintsev/122/173/66 http://maps.secondlife.com/secondlife/Dudintsev/121/208/66 http://maps.secondlife.com/secondlife/Dudintsev/121/208/66 http://maps.secondlife.com/secondlife/Dudintsev/148/237/66 http://maps.secondlife.com/secondlife/Dudintsev/120/239/66 grab as many as you like. Contact me, Jenni Darkwatch, in-world if you have any questions.

If you can filter by content... create a mail filter that tosses those? If they have common words. Just make sure it ONLY triggers on those... in Sieve I know it can be done, but I am not sure if your mail provider supports those.

Seems to be an issue with the auth server? I can't log in either, not to the dashboard and not into SL.

System layer is a lot safer than appliers. Getting the UUIDs of applier textures is utterly trivial without even using a specialized viewer, as is getting ANY texture UUID for ANY texture you see in SL. The exception is system layers, because as Theresa correctly said, those get baked into one composite texture. I don't know if bake-on-mesh does the same texture combining, but I would presume it probably does. Which would again make it safer than appliers.

That is actually quite good news. That it's packaged as .deb does make sense insofar as it's likely going to install on the majority of Linux systems that way. For other systems it sucks, of course. I don't know how well deb2rpm tools work with dependencies... though personally .deb is nice, if it has a PPA I wouldn't ever have to worry about updates again either. Neat.

Practically speaking I use two loops. One that loops through the inventory and either appends to a list for llGiveInventoryList() or sends the item directly with llGiveInventory(), depending on permissions. Then I sleep 5s. That might actually be a bit excessive... still not entirely sure why I even need to sleep, but it seems to solve the issue of missing items on delivery. It's one of those problems I can't reproduce and have to trust users' reports that some deliveries are incomplete. And then I loop through the list created for llGiveInventoryList (since that's the copy items, i.e. the ones remaining in inventory, the others are already gone) and delete them by name, with llRemoveInventory(). The actual list doesn't get modified during that process. Oh and Rolig, yes I've done that mistake before ~grins~. Specifically not realizing that looping through llGetInventoryName() and then running a llRemoveInventory() against it... doesn't delete all items. LOL. That was a "duh" moment for sure. Thanks for the answers. I'm glad I didn't miss anything obvious. Goddess knows that's happened often enough before. -Jenni

Simple question and I am sure it's been asked before but I can't seem to find anything about it when searching: I have a prim with a list of inventory items, some transfer, some copy. Basically, I'll need to give the items to someone (no problem) and then delete the inventory. It occurred to me that I really don't know what the proper approach there is. Right now, in pseudocode I have: * Fetch list of inventory items * Give no-copy/transfer items individually * Give copy/no-transfer items in a folder * Delete inventory I've had reports of items not being delivered, which I attributed to the inventory delete happening too soon. I added a 5s sleep, that seems to have fixed the delivery issue. However... is there a way to know whether the inventory has been delivered? I don't even care if the person has accepted the inventory, all I want to know is if the prim has sent the items so I can delete the inventory. Thanks folks -Jenni

Hi what I need is another layer for Maitreya. I've tried finding fullperm clothing that would lay close to the skin, but none is close enough. UV map doesn't matter, though ideal would be the default body UV. Ideally if anyone knows of a way to do this, let me know. If it requires a custom rig, also let me know including the price - it doesn't have to be an exclusive mesh. Here is why: I need to be able to apply scrapes, cuts and bruises automatically, without a dialog, and be able to fade those over time via script. I know there's at least two systems out there, but neither fit all that well and both are proprietary which does me no good. Thank you kindly - Jenni Darkwatch

The ability to actually run on an average PC? A far better new user experience? A miracle?

Like others said before, its a complex issue. One reason to limit scripts on venue patrons is responsiveness of things like danceballs and/or scripted vendors. Since sims don't prioritize scripts on parcel over worn script (as far as I know anyway, please do correct me if I am wrong), walzing in with scripts that consume a ton of frame time will lag aforementioned danceballs and vendors. It's less the number of scripts, more the time the scripts consume. That being said, having lots of scripts also eats into that time, therefore less scripts = better for venues. There's other things in some venues... like listeners on local chat, as often used in collars. OpenCollar is a prime offender there. Hoe complex ones avi is should be pretty irrelevant for the venue. LL gave us the tools to just turn obscenely render heavy avis into jelly babies or impostors depending on how much our systems can handle. In other words, if you do care whether other people can see you, worry about ARC. If you don't give a damn... go nuts on what you wear. I've seen venues enforce ARC limits, but I think that's pretty silly. Sadly not all creators offer demos to check out how well-made their items are. Many, even from very well known makers, are just flat out crap.

Dual-use Debit/Credit cards as often given out by banks do seem to work btw (at least did for me, I've since switched to PayPal instead).

Or if you use KDE... create a new Window Rule: System Settings->Window Behavior->Window Rules->(Button)New...->Window Class (Application): Exact Match do-not-directly-run-secondlife-bin->(Tab)Appearance & Fixes->Ignore global shortcuts Force Yes Save, apply, done. This will prevent ALT+TAB from working while the viewer has focus, but beyond that it works perfectly. I use those rules for putting SL window-less in the background of my desktop as "wallpaper" Maybe someone else can chime in whether or not something similar exists in other window managers.

Thanks but no thanks. I prefer to review something on my own volition. If anything or anyone "nudges" me to review, I generally give a scathing negative review.

Flat 2048m² parcel supports 468 LI, ADULT rated land on Aulen (Zindra adult continent). Price is very low for a parcel on Zindra. Verify it yourself before buying :) If you'd rather rent: L$ 500/week, contact Jenni Darkwatch via IM in-world. You'll get full rights to the parcel except of course sale, but you can sub-rent it, manage parcel access lists, deed/return objects etc.pp. along with a friendly landlady that's been in SL for many years, owned land for many years and have renters since many years. Limo: http://maps.secondlife.com/secondlife/Aulen/5/168/71 If you have any questions don't hesitate to ask me. Happy New Year :) Jenni Darkwatch

I have one of the cheaper ASUS ROG laptops with an nVidia 860M. SL runs perfectly on it. An acquaintance of mine has a MSI gaming laptop which also runs SL fine. The key is pretty much the GPU. Many laptops have very cheap GPUs which will barely run SL. nVidia tends to work best, followed closely by ATI with occasional problems and with a large performance gap Intel also works, on minimum graphics usually.

Presuming you installed all needed 32bit libs: Remove the libopenal* files from the Second Life lib folder. That forces the system libraries, fixing sound. For the mic... best I could come up with was to download the latest Kokua viewer and copy the libvivox* files from there. If you grab the 64bit version, the libraries are in the lib32 folder. Otherwise they're in the lib folder.

You can split a mainland parcel any way you like. Just remember to lower your tier setting on the dashboard once you abandon the excess land.

Hi in the last few days I keep having completely strange issues. Occasional packet loss spikes to >8%, strange error messages like the one below. Based on the error messages it appears to be an error on LL's side of things. I've even gone ahead and verified that I had no packet loss to various servers/sites I own or manage all over the world. No packet loss anywhere there, not even when sending 1000 1k payload packets. Screenie of the latest weird failure (on login screen):  Anyone else seeing increased failures in SL?

Nefertiti Nefarious wrote: Wow ... she's really good. BUT: why can;'t we get mesh that flows and drapes like that instead of stiff forms? Because not many SL residents have computers that are powerful enough to handle ONE avi with flowing clothes, let alone a club full of them.