Problem using llSitOnLink() to sit an avatar

[Rick Nightingale]

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.

Edited January 20, 2023 by Rick Daylight

[Lucia Nightfire]

It's called the "interest list".

If someone gets scripted sat on something outside of your FoV, they might not update correctly when you change your camera angle to bring them back into FoV.

Everything from hover text, to prim position/rotation is affected.

There's also an issue with sitter rotation not updating when their viewer is minimized.

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

[Rick Nightingale]

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.

[Rick Nightingale]

It also happens just when simply sitting an avatar which is given the menu; I use the system to quickly TP or move to seats around my parcel depending on the menu selection. All that is happening is the avatar selects the seat from a dialog, the menu script messages the seat which does the llSitOnLink(). The viewer is, of course, not minimised; I'm driving it normally.

It's happened twice like that, yesterday and today. Both times the avatar was first zapped to <0,0,0>, yet the seat reported that the avatar was sat on it correctly. Trying to get the avatar back this time didn't work; camming and click-TPing back to my parcel ended up with the avatar being zapped well off region in the opposite direction, stuck at location something like <400,400,30> and unable to do anything else. I needed to relog.

After a relog, I tried sitting again and it worked. I can't yet see anything different that would have caused the occasional failure.

Edit: Possibilities:

1. AVsit is incorrectly setting the sit position, randomly. I doubt it, but I've added debug code to AVsit to read out the sit offset every time.

2. The link is somehow being left with an incorrect sit target otherwise, and this is being used before AVsit takes over. Again I doubt it, but I've added code to read out all the sit targets before seating the avatar.

3. There's a bug somewhere in the llSitOnLink() function, or just in the viewer or SL in general that is causing this and no debug lines can catch it. This is my bet.

I find it curious that the failed-to-sit avatar's viewer shows the avatar at <0,0,0>, while another viewer shows the avatar seated where it should be. Both viewers being not-minimised at the time.

 

Edited January 26, 2023 by Rick Daylight

[Love Zhaoying]

Have you tried sprinkling holy water on the goat's head pentagram? 

[Lucia Nightfire]

14 hours ago, Rick Daylight said:

It also happens just when simply sitting an avatar which is given the menu; I use the system to quickly TP or move to seats around my parcel depending on the menu selection. All that is happening is the avatar selects the seat from a dialog, the menu script messages the seat which does the llSitOnLink(). The viewer is, of course, not minimised; I'm driving it normally.

It's happened twice like that, yesterday and today. Both times the avatar was first zapped to <0,0,0>, yet the seat reported that the avatar was sat on it correctly. Trying to get the avatar back this time didn't work; camming and click-TPing back to my parcel ended up with the avatar being zapped well off region in the opposite direction, stuck at location something like <400,400,30> and unable to do anything else. I needed to relog.

After a relog, I tried sitting again and it worked. I can't yet see anything different that would have caused the occasional failure.

Edit: Possibilities:

1. AVsit is incorrectly setting the sit position, randomly. I doubt it, but I've added debug code to AVsit to read out the sit offset every time.

2. The link is somehow being left with an incorrect sit target otherwise, and this is being used before AVsit takes over. Again I doubt it, but I've added code to read out all the sit targets before seating the avatar.

3. There's a bug somewhere in the llSitOnLink() function, or just in the viewer or SL in general that is causing this and no debug lines can catch it. This is my bet.

I find it curious that the failed-to-sit avatar's viewer shows the avatar at <0,0,0>, while another viewer shows the avatar seated where it should be. Both viewers being not-minimised at the time.

 

Is the sit object within the target's FoV, IE, close by and in their interest list (on-screen)?

Is the sit object in a location in the region, that when an agent who is not alt-cammed on anything, camera is following them, draw distance is low enough to not load other regions, get sat causes an adjacent region to load when their camera position changes?

[Rick Nightingale]

Most of the time no, while it's within my draw distance (usually) it's hidden from view and I might be facing the other way, but even so mostly it will work. I just did a test, accessing the menu from about 120m away from the sit target, with a 32m draw distance, facing away, and the sit target (even if it was in my draw distance) would be hidden behind a small hill and several walls. It worked.

There are no adjacent regions; it's a single private island surrounded by nothing. There are other regions on the world map after that region wide spacing (standard, spaced out islands) but as far as I know, they technically don't exist from my viewer's point of view when it's like this. I certainly can't cam to them.

One thing that makes me wonder is that the sit targets are all under water (like 2m to 3m above zero) although I don't know why this should be an issue and it probably isn't. It's just one thing that strikes me as potentially unusual in what I'm doing.

It's hard to catch anything specific when it happens because it works most of the time and always takes me by surprise when it doesn't. I'll be paying more attention from now on though, and checking all the debug output for the targets and [AV]sit movement of the seated avatar. Pretty sure it's not that though.