llAvatarOnLinkSitTarget returns UUID when no-one is sat... and worse...

[Rick Nightingale]

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

Edited January 11, 2023 by Rick Daylight

[Love Zhaoying]

Do you think this is a new bug, existing "feature", looking for a code workaround, or "right way"..?

 

[Rick Nightingale]

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!

[Xiija]

@Rick Daylight

It seems to work ok for me.. are you checking this in your changed event?

default
{
    state_entry()
    {     
    }
    changed(integer change)
    {     
        if (change & CHANGED_LINK)         
        {
            integer i=2;
        do { 
           
            if (llAvatarOnLinkSitTarget(i)) {
                llOwnerSay("Link: " + (string)i + " Av:"+(string)llAvatarOnLinkSitTarget(i));
               // llLinkParticleSystem(i,gParticles);
            }
            else {
              //  llLinkParticleSystem(i,[]);
                llOwnerSay("Link: " + (string)i + " Av: NONE");
            }
        } while(++i<=4); 
        }
    }
}

 

[Rick Nightingale]

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.

Edited January 11, 2023 by Rick Daylight

[Rick Nightingale]

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

[Rick Nightingale]

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.

[Quistess Alpha]

37 minutes ago, Rick Daylight said:

Detect if an avatar is sat on a link in a linkset

If you only care about who's sat and not on which links, you could always go back to:

// number of avatars sat on the thing:
llGetObjectDetails(llGetKey(),[OBJECT_SIT_COUNT]);
// old method:
llObjectPrimCount()-llGetNumberOfPrims();
// get their keys with
llLinkKey(llGetNumberOfPrims()-avatar_index);

 

Edited January 11, 2023 by Quistess Alpha

[Rick Nightingale]

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???

[Xiija]

sometimes a script gets borked,   ..happens alot .. just delete and recode and see if it happens again?

 

[Rick Nightingale]

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.

[Quistess Alpha]

37 minutes ago, Rick Daylight said:

Yes, I'll probably delete the entire linkset and remake it,

Does the error persist on a shift-drag copy of the linkset?

[Rick Nightingale]

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

Edited January 11, 2023 by Rick Daylight

[Rick Nightingale]

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.

Edited January 11, 2023 by Rick Daylight

[Love Zhaoying]

If you get into a situation where a previously working script just..doesn't.. I've had cases where copying the source to a new script and recompiling, fixed it.  For real!

[CarlaWetter]

This sounds a lot like an error condition sailors happen to run into a lot. Usually you get it on a vehicle when you happen to get disconnected from SL (the fabulous death by grey screen).  Sit targets won't just be freed.

Associated JIRA

[Rick Nightingale]

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

[Qie Niangao]

Interesting. I hope the problematic linkset is saved for posterity.

2 hours ago, Rick Daylight said:

[...] yet another bug in SL.

Some Linden: Oh dammit now I gotta go patch my buggy virtual world again. Wonder if any links were targets of llSitOnLink(), maybe the absent alt was force-sat… and the plot thickens:

2 hours ago, Rick Daylight said:

Two huge, locked, and heavily experience-scripted linksets had just vanished,

Chekov's smoking gun right there! But how else might we confuse llAvatarOnLinkSitTarget()? Could there still be a sneak path that lets the linkset change while there's an avatar seated? Like, what happens when a vehicle passenger is denied access to a parcel? even if the parcel border is a sim border and somebody crashed in crossing? (Seems unlikely anything like that happened in this case.)

2 hours ago, Rick Daylight said:

I think my build here is cursed. Probably because I'm the devil

If the place really is cursed, it could command huge rents. Like from griefers, for example. If we can't monetize evil anymore, really, what is the point?

[Rick Nightingale]

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.

Edited January 11, 2023 by Rick Daylight

[Qie Niangao]

I'm just admiring the straws, trying not to grasp. Might be clues in how to get a reliable repro. Hunching that somehow Experience-forced sits escape clean-up under some conditions yet to be determined. And the bug @CarlaWetter cited might be another clue, another way sit-target-accounting may get confused.

[Rick Nightingale]

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.

[Lucia Nightfire]

See https://jira.secondlife.com/browse/BUG-232261

Aside from the above, I've seen vehicles changing regions where riders fall off or get disconnected causing sit targets to get stuck as well as agents having bad packet loss triggering it upon llUnsit() without a following disconnect/crash.

I think llSitOnLink() needs another error condition handling that checks if an agent is currently teleporting/region crossing and if so, throw a new error code instead of executing, resulting in a stuck sit target.

Edited January 12, 2023 by Lucia Nightfire

[Quistess Alpha]

It just occurred to me that if you want/need to be careful about planning around this bug, you can llGetObjectDetails(ID,[OBJECT_ROOT]); the ID returned by llAvatarOnLinkSitTarget(); if the avatar's object_root is the same as the linksets root, then the avatar actually exists in the region and is, in fact, sitting on the object.

[Lucia Nightfire]

13 minutes ago, Quistess Alpha said:

It just occurred to me that if you want/need to be careful about planning around this bug, you can llGetObjectDetails(ID,[OBJECT_ROOT]); the ID returned by llAvatarOnLinkSitTarget(); if the avatar's object_root is the same as the linksets root, then the avatar actually exists in the region and is, in fact, sitting on the object.

The problem happens when an agent is unsat but the server never gets the message.

Disabling then enabling the sit target does not release the stuck UUID either.

I think the server should be updated to check if sit targets are really in use when the sit target is disabled and/or enabled.

[Lucia Nightfire]

I also filed a feature request to allow scripts to know if an agent is departing a region as AFAIK, there isn't a 100% way to know without potential false positives using various means.

https://jira.secondlife.com/browse/BUG-233192