Rick Nightingale

@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.

@CarlaWetter Interesting... the symptoms certainly sound similar. There were no disconnects or anything like that, but perhaps related is that my dungeon is under water to take advantage of the different lighting effects. Whatever caused it managed to happen twice; the first sit target getting stuck causing the alt to then sit on the next sit target, which then got stuck too... I'll keep a close eye on this and add to the Jira if it happens again and I can pinpoint anything useful. It was working fine before my rebuild, but I made big changes to the [AV]sit and other code in it to force sit target changes and other stuff, so maybe I managed to break something in a similar way to the crashing.

Not really related, but... I think my build here is cursed. Probably because I'm the devil The number of odd things that have happened to it is just going up and up. The other week, I went down into my dungeon for the first time in a few days only to find half of the build had gone. I thought it was the missing mesh issue at first and was even taking some snapshots to add to the Jira. Then, to me horror, I realised it was really gone. Two huge, locked, and heavily experience-scripted linksets had just vanished, taking half the visible build with them. No way I had done that myself, my landlord certainly hadn't and no-one else can edit my stuff. There was no sign of them in my inventory (not returned or deleted) and of course, I had backups of the entire build except those two which I had been working on the most until a few days before they vanished. A ticket to get a rollback was filed... which was answered long after the 72 hours that they said was all that it could be rolled back. Useless. I've just about finished rebuilding now... and I get this. So you'll understand that I'm a bit frustrated with LL.

No... no it doesn't. Since the new copy stays put - that's just saved me (by seconds) from deleting it and making it again. Thank you! I was in the middle of re-writing the [AV]sit code. There's a very customised version of it in the thing. I wonder if that somehow caused this to happen. It shouldn't (how can a prim get stuck like that???) but who knows, lol

It's not the script - I've changed and recompiled it and it gets the same results. It's the prims. A new script in the same object, just to check the llAvatarOnLinkSitTarget() output, gets the same nonsense returned keys of an avatar that's not even logged in. This is a failure at a fundamental level. Yes, I'll probably delete the entire linkset and remake it, since I don't really know where the failure is and cannot trust the entire thing now. Yet another several hours wasted troubleshooting my work only to find it's nothing to do with me and is yet another bug in SL. I'm very unimpressed with LL.

I care about which links, not who's sat. I think the point here is that the function is completely failing... it's like the prim has got itself stuck thinking it has an avatar sat on it. That's some serious wrongness... but how to repro this for a Jira report???

A copy rezzed elsewhere doesn't do it. A copy rezzed in my region doesn't do it, while the original is still doing it. The original object is convinced it is still sat on.

I'm going to take a copy of my thing and try in another region...

That function I excerpted is called both from changed() and if I change the particle mode manually. The script does a few other things, but nothing that would interfere with this. If it wasn't for the fact that it's getting my alt's key, I might think I'm doing something wrong, somewhere... but llAvatarOnLinkSitTarget() is returning the key of an avatar that's not even logged on. Twice.

Right now... my brain is so boggled with this I'm stumped. I've just relogged (and the alt is not logged on) and it tells me that alt is still sat on those two links at the same time. I give up!

OK, figure this one out: I've simplified this code while troubleshooting. Long story short: Detect if an avatar is sat on a link in a linkset, if so, start some particles from that link. Except... I'm getting the same valid avatar key (my alt) from two links at the same time, yet that avatar is not sat on the item at all. It was, but isn't now, and it certainly wasn't sat on two at the same time. No-one is sat on the thing! Code excerpt: integer i=2; // Don't care about root, start at link 2 do { // Itterate the child prims in the linkset llOwnerSay((string)i); if (llAvatarOnLinkSitTarget(i)) { llOwnerSay("Av:"+(string)llAvatarOnLinkSitTarget(i)); llLinkParticleSystem(i,gParticles); } else { llLinkParticleSystem(i,[]); llOwnerSay("No"); } } while(++i<=4); // Four prims in the linkset This is the test output: 2 Av:[my alt's key redacted] 3 Av:[my alt's key redacted] 4 No So... my alt is sat on both links 2 and 3, and yet is not actually sat on anything. In fact, I've just TP'd the alt out of the region and re-run the test - it gives the exact same output. Sometimes I think SL is just playing with my mind...

The word "Oriental" being politically incorrect is another result of the "I'm offended for you" culture. And I have that from an Oriental (her own description; via Google) who says she is completely confused by it being seen as such, since all it means is 'Eastern'. In her words (paraphrased): "Haven't we all got far more important things to be concerned with?"

Same in the UK. Seen it for decades.

I accidentally posted above before I had finished... I see nothing wrong with someone making what is, in effect, a 'mixed' race picture. Frankly, aren't many (maybe most) of us really that anyway? I'm part indiginous English (whatever that means), Welsh, Romany, and probably all sorts of others knowing what little I do about my ancestry. If I wasn't paranoid about people getting my DNA I would do one of those ancestry tests out of curiosity. Paint any picture, and someone, somewhere probably looks something like that. Well, unless you paint a purple, six-eyed, two-nosed alien... and I wouldn't put money against that. Unless it is clearly intended to mock... let's not assume racism where there isn't any intended. Edit: Even then, there is such a thing as humour.

How long has the term 'yellowface' been around? Is it defined in a dictionary, and is that definition the same in everyone's dictionaries? I've never heard it before today, but I guess it's intended to imply a derogatory/demeaning portrail of a race like the obvious origin of [insert some colour here]face. I certainly don't see that here, and I think the only people who's answers are even relevent are those of the picture's perceived race.