llAvatarOnSitTarget reports incorrect agent on sit target after disconnect
tracked
TrishAce Resident
This is a super old bug that I want to bring back to light, I could not find a canny on this.
This bug alone, is responsible for several vehicle woes, often requiring vehicles to be re-rezzed.
Old archived posts referencing this issue:
Summary:
In short, when an agent crashes and disconnects uncleanly, the sit target remains occupied. Other viewers will still show the (now gone) avatar on the seat, scripts who call llAvatarOnSitTarget or related functions will be told that the sit target is occupied by the avatar who got disconnected.
What makes this particularly evil for scripts?
- This stale state survives script resets, since it's a simulator state issue.
- The stale sit target survives sim crossings
- Even worse, you can unlink and relink the link with the sit target, and the simulator will still report that the disconnected avatar is sitting on that sit target once you relink.
- If the disconnected avatar relogs to a different region, and teleports back to the region the vehicle is in, when they resit, the avatar will now occupy two sit targets.
Side note: If a linden wants help reproducing this bug, I'm happy to help. It can be reproduced easily if we stress test and try to crash on purpose; by having a multi-avatar vehicle with several avatars running several scripts.. we can make ourselves crash onto sim corners.
Log In
Alistar Snook
I'll add my observations here for this issue, in case they might be helpful to someone.
I tested it within a single region, with 1 region crossing, and with multiple crossings, and the behavior remains likely the same.
The timestamps below should help clarify what's happening.
I sat on my vehicle:
[05:23] Object #2 sussurra: [2026-05-16T12:23:46.141373Z] ColiseumGateway Resident sat down on Object #2 (Key: 93b20ca0-a283-456e-8ac4-e1d02dd692bb)
[05:23] Object #1 sussurra: [2026-05-16T12:23:52.097106Z] Alistar Snook sat down on Object #1 (Key: ff62d488-6f53-4498-8975-0d86834ef446)
I drove around a bit and simulated a crash. A few seconds later, I checked the status, and even after the crash, the function triggered showing that both were still seated:
[05:25] Object #2 sussurra: [2026-05-16T12:25:05.794364Z] Object #2 is occupied by: ColiseumGateway Resident (Key: 93b20ca0-a283-456e-8ac4-e1d02dd692bb)
[05:25] Object #1 sussurra: [2026-05-16T12:25:07.772081Z] Object #1 is occupied by: Alistar Snook (Key: ff62d488-6f53-4498-8975-0d86834ef446)
After a few seconds:
I stood up and tried to check the vehicle's driver seat status again. It still showed as occupied. I sat back down, but the function didn't trigger:
[05:25] Object #1 sussurra: [2026-05-16T12:25:38.349800Z] Alistar Snook left or disconnected from Object #1
[05:25] Object #2 sussurra: [2026-05-16T12:25:42.727758Z] Object #2 is occupied by: ColiseumGateway Resident (Key: 93b20ca0-a283-456e-8ac4-e1d02dd692bb)
It was impossible for my main avatar to drive the vehicle because the script didn't trigger, claiming the seat was still occupied by ColiseumGateway Resident.
[CONTINUE]
Alistar Snook
Finally, I got this message:
[05:26] ColiseumGateway è offline.
[05:26] Object #2 sussurra: [2026-05-16T12:26:16.395466Z] left or disconnected from Object #2
As you can see here, I was already seated but unable to drive: https://gyazo.com/60bb488c7ca11aaa1f8df70ce8fcc9e6
I had to stand up and sit down yet again. After doing that, the function finally triggered correctly and I was able to drive:
[05:27] Object #2 sussurra: [2026-05-16T12:27:03.706635Z] Object #2 is not occupied.
[05:27] Object #2 sussurra: [2026-05-16T12:27:30.395274Z] Alistar Snook sat down on Object #2 (Key: ff62d488-6f53-4498-8975-0d86834ef446)
After driving for a bit, it correctly detected when I stood up:
[05:28] Object #2 sussurra: [2026-05-16T12:28:04.395724Z] Alistar Snook left or disconnected from Object #2
Even in cases where the sit target doesn't become permanently corrupted (the bug's infinite loop), the server still requires the user to stand up and sit back down after the 90-second timeout to re-trigger the function, as it fails to realign the avatar already seated on the prim to the newly freed sit target.
Alistar Snook
I found and managed to reproduce the bug!
It happened after crossing multiple regions several times. My main avatar (acting as a passenger) experienced an actual crash, so this wasn't a forced disconnect for testing, but a real SL crash. When this happens, the sit target becomes permanently corrupted.
[11:07] Alistar (alistar.snook) è offline.
[11:07] Object #2 sussurra: [2026-05-16T18:07:34.210201Z] Object #2 is occupied by: (Key: ff62d488-6f53-4498-8975-0d86834ef446)
[11:07] Object #1 sussurra: [2026-05-16T18:07:37.588700Z] Object #1 is occupied by: ColiseumGateway Resident (Key: 93b20ca0-a283-456e-8ac4-e1d02dd692bb)
[11:08] Object #2 sussurra: [2026-05-16T18:08:11.332011Z] Object #2 is occupied by: (Key: ff62d488-6f53-4498-8975-0d86834ef446)
[11:08] Object #1 sussurra: [2026-05-16T18:08:13.338971Z] Object #1 is occupied by: ColiseumGateway Resident (Key: 93b20ca0-a283-456e-8ac4-e1d02dd692bb)
[11:08] Object #2 sussurra: [2026-05-16T18:08:41.210830Z] Object #2 is occupied by: (Key: ff62d488-6f53-4498-8975-0d86834ef446)
[11:08] Object #1 sussurra: [2026-05-16T18:08:43.610723Z] Object #1 is occupied by: ColiseumGateway Resident (Key: 93b20ca0-a283-456e-8ac4-e1d02dd692bb)
[11:08] Alistar (alistar.snook) è online.
[11:09] Object #2 sussurra: [2026-05-16T18:09:01.256768Z] Object #2 is occupied by: Alistar Snook (Key: ff62d488-6f53-4498-8975-0d86834ef446)
[11:09] Object #1 sussurra: [2026-05-16T18:09:03.167777Z] Object #1 is occupied by: ColiseumGateway Resident (Key: 93b20ca0-a283-456e-8ac4-e1d02dd692bb)
[11:09] Object #1 sussurra: [2026-05-16T18:09:52.316009Z] ColiseumGateway Resident left or disconnected from Object #1
[11:09] Object #2 sussurra: [2026-05-16T18:09:57.916127Z] Object #2 is occupied by: Alistar Snook (Key: ff62d488-6f53-4498-8975-0d86834ef446)
[11:10] Object #1 sussurra: [2026-05-16T18:10:06.853316Z] Object #1 is not occupied.
As you can see from the logs, even though my avatar was completely offline, Object #2 kept reporting the seat as occupied by my UUID.
The worst part is that at 18:08:41 I logged back into SL (without getting back on the vehicle), and at 18:09:01 Object #2 automatically resolved my name again, claiming I was still seated there. The sit target remained permanently broken and stuck with my UUID, even though I was no longer anywhere near the vehicle.
Kyle Linden
marked this post as
tracked
AWalphaomega Resident
We have been experimenting with scripted workarounds for the phantom Avatar. Currently the best results are to use llUnSit on that key. Scripting something to automatically do this in the event of avatar crashing out is more complex
TrishAce Resident
AWalphaomega Resident From my testing, doing llUnSit on a ghost avatar does nothing if the agent is not present in the region (Disconnected) or simply not sitting on the vehicle in the middle of a public area (like mainland roads). Which is consistent with the documented behavior:
"The agent identified by id is forced to stand up if any of the following apply:
The agent is sitting on the scripted object
The agent is over land owned by the scripted object's owner and/or a group the owner has land rights for."
If we had a force unsit for sit targets, that could be a good workaround in all areas, but wouldn't solve the root cause.
Peregreena Resident
There is another "failure mode" connected to sim crossings.
Sometimes, when the avatar's handover at the crossing takes too long, the changed event is fired. That event is used to deal with avis sitting and unsitting.
So when the event is fired in that scenario, the avi isn't sitting on the vehicle.
But if the avi is then handed over and added to the vehicle again, the event isn't fired again.
That results in scripts thinking the avi is gone, even though the avi is back and part of the vehicle's linkset.
TrishAce Resident
There are several functions and events that behave unintuitively after crossings. While it would be nice to fix them, I would argue that they're mostly all things a scripter can work around if they know about it. This bug report targets a specific bug in the simulator that makes it continuously report an erroneous state no matter what a scripter does, rather than a one-off failure.
Example of crossing-induced failures and their workarounds:
- Changed Region doesn't fire in the root -> should check for region change manually on a timer
- Changed Link doesn't fire -> Should check for the presence of a sitter periodically
- Runtime permission event handler executes in the wrong region after a corner (Region B granted permissions but you receive that response after crossing into Region C) -> should always validate if you do still have permissions in the current region after supposedly receiving permissions
Peregreena Resident
TrishAce Resident Speaking of workarounds: the problems in the opening post can be avoided, simply by not setting sittargets.
TrishAce Resident
Peregreena Resident True, but the better workaround at that point is to get off SL
TrishAce Resident
For debugging purposes, this sim corner here is particularly bad and usually where I like to test my crossing crashes: http://maps.secondlife.com/secondlife/Amella/254/0/64
Here is an example of the duplication happening. It took me just 15min of testing today to get it to happen on purpose.
I had a bad crossing, got unsat and never automatically resat. When I manually sat on the vehicle, the simulator assigned me to a new sit target instead of the old stale one, and now the simulator will report both sit targets as occupied.
This can happen without a crash/disconnect, like in this instance, it was a simple bad crossing/unsit process.
Edit: in this case, llGetNumberOfPrims() returns 31, the only avatar is Link #31, the vehicle itself has 30 links, and there are 2 sit targets occupied. You can deduce this bad state because 1) two sit targets report the same avatar 2) 30+2 > 31
Peregreena Resident
TrishAce Resident
When multiple links carry the same avatar on sit target, re-seating and standing only clears the link with the lowest link number. If sittargets are necessary for seating, there are some ways to deal with blocked links.
What would help is a function that allows to clear avatar on sit target by script.
TrishAce Resident
Peregreena Resident Yes, a way to forcefully clear a sit target could solve this.
Peregreena Resident
TrishAce ResidentOne easy way to implement this, would be to clear AvatarOnSitTarget when the (Link-)SitTarget itself is cleared, either by using
llLinkSitTarget(link, ZERO_VECTOR, ZERO_ROTATION);
OR
llSetLinkPrimitiveParams(link, [PRIM_SIT_TARGET, 0, <0,0,0>, 0,0,0,1>] );
The SitTarget can be set again afterwards, if necessary.