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