llAvatarOnSitTarget reports incorrect agent on sit target after disconnect
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
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
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