Rick Nightingale

Yes, that's one of the things I've noticed too.

...and the MAC address most certainly is private, since it is supposedly known only on your local subnetwork and is not, indeed cannot, be transmitted past your router by normal network protocols. However, it can be read by software and is reported back to LL by the viewer so they can use it as a metric to identify your PC. Something I consider an invasion of privacy, but one we have no choice but to accept if we want to play in their sandpit. It's also a pointless way to try to ban someone if that someone knows what they are doing, but fortunately most idiots don't.

Hmm... is it related to that then? Note though that the sitter's viewer was not minimised while all of the above happened. It did not have focus though; something that is probably far more common than being minimised. That's a pretty content-breaking bug if an experience script acts on an avatar while their viewer is minimised. Being zapped to <0,0,0> isn't nice, lol.

Does anyone else remember Cheeky Tiramisu? That's going back a decade maybe. A full region with a cafe (that above named) set in a wooded, undulating landscaping with walks around it and some rocky coastal walks. There was a Japanese style communal bath ( and a good number of cherry blossom trees, so I guess the owner was Japanese) and an underground, hidden cave system with another hangout spot in it. The entrance to that was through a waterfall on the coast; I had been loitering around the region for six months before I discovered it by accident. It was one of the first places I enjoyed just chilling out in SL. Not many people visited, most of the time I was alone but occasionally another one or two would be there. Sometimes we even said hello while sat at the cafe, lol. Then one day I went there, or rather didn't because the region had gone. I was sad. Even the few screenshots I recall taking of it seem to have vanished from my PC. I would love to have a region where I could create a place for people, like that.

I thought this was a one-off glitch at first, but it's now happened four times. Simple setup: An avatar (in this case my default test alt #2) that has already accepted the experience, is simply sat on an object by my script using llSitOnLink(). Mostly it works as expected. But then sometimes, this will happen: I see the test alt sat where they should be. The test alt (in their viewer instance) sees itself stuck at <0,0,0>, but playing the sit animation. This exact thing (with different seats - doesn't seem to matter where) has happened several times. This time I did more though, realising that there is a problem. My view: Test alt's view: There is no RLV involved at this stage, or anything other than the llSitOnLink() and subsequent pickup by the AVsit script on the seat. It happens with other seats too, not just this one (my pillar of souls). The alt cannot stand (there is no "stand" button), but can cam away and double-click TP back on my land. Having just taken the above pictures and TP'd the alt back, I recaptued the alt on the same seat; the same thing happened again. I moved the alt to another seat without unseating first (completely different linkset) and the alt moved to that seat in my viewer, but in the alt's viewer stayed sat on the pillar of souls (even though it was at <0,0,0> when it should have been there, as if it was a step behind things) but playing the animation for the new seat (and spinning around at a distance from the pillar of souls - it rotates). My view: Test alt's view: At all times, both viewer instances were on-screen; not minimised because I know that causes them to not notice animation updates and the like. They were both 'live'. Interestingly (maybe) is that if I give the alt access to the capture/seating menu to sit themselves, which is how I've done most of the testing up to now, the above doesn't seem to ever happen and everything goes according to plan. Thre is no difference in who causes the sit as far as the script with the llSitOnLink() command is concerned - all that gets is a message with the avatar key in regardless of which avatar is running the menu. The only difference is that it is done on the alt's own viewer, not my viewer. And now, having brought in another alt for testing at the same time, everything is working as expected again even with me moving them around. Yet again, something that sometimes happens, and sometimes doesn't. Clearly... there are issues. If anyone has any ideas, or has seen similar... please comment. If I can find a repro I'll start a Jira. Edit: This is all in addition to the fact that I've had the seats telling me the alt was sat on them, in fact on two at the same time... when the alt wasn't even logged in.

Agreed, @Marianne Little. It's one of the reasons I'll often mesh a part that could otherwise be a prim. Those sharp corners, compared to a little edge bevelling with hardened normals are a giveaway of prims vs. mesh. That said I see a lot of mesh that looks like it is prims, with the sharp corners; seems like a waste of mesh to me. I often wonder if some that was made with one of those converters. Having a 'bevel my edges' setting would be great. My other pet hate is trying to get prims to line up close enough not to have a flickery gap when looking at just the right (wrong) angle, yet also not overlap and get texture flicker. Sometimes you just can't bed them into each other and need edge-to-edge 'seamlessness'. Can't be done... especially at high location values (silly 32-bit SL). I want to be able to weld my (bevelled) prims together

One of the killers for me with prims is the way the physics cost jumps through the roof when they switch to mesh accounting (by putting a normal map on there), with hollows and twists etc., if they need 'proper' physics. Like my portals or even a simple arch that you want to walk through. I've no idea if the physics cost is justified compared to anything else, but I know I could make a mesh piece with the same shape and acceptable physics for a fraction of the cost, in most cases. While you can approximate the physics for a lower overall cost using linked, hidden prims, that isn't really on if you plan on changing shapes. Did I mention like my portals? So yeah... give us nicer prim LI please!

I'm using prims here to do a cute portal-opening effect by ramping the hollow in them. One of the few uses of planer mapping I've found - the inside of the hollow that is.

Absolutely. I tend to get them for free anyway... by linking them to some mesh that has a high download cost but low server cost. I hate to think what my dungeon would be if I didn't do that! Most of it is prim built despite that I could easily mesh it all, simply for the above reason of saving LI. I have ten large mesh objects, 15LI each on download cost. That's 150 LI. Linked to them are 213 prims. Total LI is 165, so those 213 prims that comprise most of the build only cost me 15 LI. You learn to do things like that when you live on a slice of Homestead

I don't think MALified has been mentioned - not checked everything but my wife has a couple of outfits from there and everything I saw in a quick peruse of the MP had mod perms: https://marketplace.secondlife.com/stores/96737 http://maps.secondlife.com/secondlife/Horizons Elara/104/52/30 Edit: Just got told their NC says everything is Copy/Mod perms except demos.

This is what my framerate looks like, limited to 60fps by the viewer (not vsync), when it starts to judder. The number at the top corner of the screen still insists it's 60+fps, rarely dipping below 60.

@Jackson Redstar that sounds the missing object bug, rather than my stuck LOD bug. Yes, it's a pain. I've had a large part of my build do that and not come back until a relog. Sometimes the stuff doesn't even show up in wireframe.

What happens when your AI friend decides it doesn't like you and leaves you for someone else? Or just rage quits? If they base the AI on typical SL behaviour... those are real possibilities! "I demand a refund! My AIF called me a jerk and blocked me!"

@animats yes, that missing item bug is a pain and I've been seeing it too, all over the place. The stuck Lowest LOD bug is worse for me though. It happens all the time on my land. I hardly get to move around without something showing it and there's no 'cure' that lasts longer than it takes to turn around. @Beq Janushas seen it here, and confirmed it doesn't happen in LL's viewer.

Fortunately, being in the UK, that's one potential certain breach of security and privacy that we don't get. Unless one is a BT internet user... which is one reason why I'm not.

One of the bot control software can integrate with MQTT, Corrade I think. MQTT is a protocol for passing messages/instructions to IoT devices. So, my bot/avatar could tell my electric blanket in my RL bed to turn on. I guess that could work backwards too... just needs a skill for Alexa. There probably already is an MQTT skill (in fact, I would fall off my chair if there isn't) so it's just a case or linking an MQTT hub to the Corrade API*. As it is, I ask Alexa to do it, or just load a local web page on my PC because it's all programmed in-house here. Alexa is just a convenient 'guest' on a very locked-down VLAN on my network. *or something like that. Despite having the house automated a lot like that, I've never actually bothered with an MQTT server.

@Henri Beauchamp I finally got around to trying Cool VL, and can confirm it does not have this stuck low LOD issue or the delayed drawing of objects when I turn around. Nor does Black Dragon from a ten minute test (although that gave me motion sickness with the swaying effect when I move my camera, lol). Seems these issues are Firestorm-only. Although... Cool VL refused to show two of my three animesh bunnies until I relogged. Possibly the missing mesh bug... or just a random glitch. Or shy bunnies.

I was told some years ago, here on this very forum, that my avatar looked like David Beckham. That certainly wasn't intended; I can't stand football and barely knew who he was. It wasn't until afterwards that I realised that was probably why the Redgrave skin was called 'David'. I had no idea!

My Jira has just been closed as "working as expected" and I was pointed to the slam bit page. Well... yes and no having done further reading. I think this is a case of "as expected" meaning "it's a bit broken, but we aren't going to fix that so it's now as expected" This, which I admit I didn't read before, is linked from the slam bit page: https://jira.secondlife.com/browse/SVC-8223 It seems that objects given to another avatar, are not considered to be given to that avatar until that avatar rezzes the item. Until it is rezzed, changes made to the permissions while in inventory (which seems to include being inside a rezzed box) are applied as if they are being made by the now previous owner. So, my alt changing permissions on a really full perm item given to them while in a box sets next-owner permissions that apply to that alt as if I had changed them before handing it over. If that's really as was intended, I'm a two-headed donkey. Heee-haawwww!

I'm quite happy to see the 'slow' shutdown return rather than having to guess when it's safe to restart. As always I prefer to know what is really happening. If it could be made genuinely faster, great, but it is what it is right now. I've still not had a freeze (or inventory loss) since the final fix was implemented - good work Beq!

Ahh... the plot thickens. I was, at the time, also testing ejecting agents using llTeleportAgentHome()* using that same alt. However, I am 99% certain that the alt was never sat on the object in question when I kicked it out. I did once sit it on another, unrelated object to check that it would TP home if seated but most of the time the alt was standing at its landing point on the radar (while I was stood next to the object in question) and I was just watching its dot vanish when I kicked it. Edit: what was happening, frequently, was the seated alt was being unsat by the [AV]sit code, as it does, as I modified and re-saved the other scripts in the object. Followed by me resitting them with llSitOnLink(). *rather than parcel eject because I'm on an island, to avoid the issue: "llEjectFromLand boots to nearest parcel edge - and fails when nearest edge is sim edge without bordering sim"

If it happens again Qie, I'll try to leave it there and give you a shout to come and have a look if you want. Let you edit it and chuck a script in even.

I wasn't going to say anything, but the picture reminded me of something done by those irritating AI things that art sites are being flooded with. My brain even automatically counted the fingers when I first opened the post, before I read anything.

Well, I did take it into inventory but it seems re-rezzing it resets the targets. It has happend before... it will happen again Yes, lots of llSitOnLink(), plus the ability to just click-to-sit although that has now been changed to touch-to-tell the-script-to-do-llSitOnLink(), for reasons. Add to that four sets of customized (including the sit targets) [AV]sit scripts that take over once the avatar is seated. However, if you mean the alt was force sat while it was absent, no. That's one of the checks (using llGetAgentSize()) that happens frequently in my script before trying to do anything to with them in case the avatar has bugged out before I get chance to grab it.