• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-1548
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Finish
Priority: Major Major
Assignee: WorkingOnIt Linden
Reporter: Darien Caldwell
Votes: 14
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

Havok 4: Avatar Dismounts (Standing up/Unsitting) are now unpredictable.

Created: 14/Feb/08 08:05 PM   Updated: 28/May/08 01:18 PM
Return to search
Component/s: Physics
Affects Version/s: Havok4 Beta, 1.21.0 Server
Fix Version/s: None

File Attachments: 1. Zip Archive 20080519-beta-unsit_sequence.zip (3.66 MB)
2. File SecondLifeMono 2008-05-20 13-22-42-21.wmv (998 kB)
3. File unsit-bug.wmv (2.15 MB)

Issue Links:
Duplicate
 
Relates
 

Linden Lab Issue ID: DEV-15184


 Description  « Hide
With the Refresh of the latest Havok4 Beta (1.19.0.79818), some unusual behavior has been noted with the Sit-Teleporters we use in hour H4 sim. People are being ejected from the teleporters in what was a seemingly random fashion. After examination of the script and comparisons in H1 sims, It's become apparent that its the behavior of the Unsit/Stand up that has changed. Which brought me to this line in the Blog:

"DEV-10351: Reduced tendency of avatar to snag or be thrown into the air when standing up from vehicle or seat"

It seems Avatars no longer go straight up when Standing up, but are rather 'pushed' in the positive X direction of the prim they are sitting on (local axis). However rotations of said prim produce varying (i.e. unpredictable) results. As this change has the potential to break some content, and confuse and confound anyone who's ever built anything thats meant to be sat on, It should at least be re-examined before going live on the grid, IMHO. I wasn't aware of the full implication of that line in the blog, and I'm sure many others aren't either. So if anything else, I hope enough people see this to have a chance to weigh in on this new behavior. It's a subtle change, but significant, given the prevailent nature of the usage.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Oni Horan added a comment - 14/Feb/08 08:12 PM - edited
theres absolutely no way to properly determine the direction, people who sit on my teleporters get thrown around compeltely randomly and i see no efficient way to fix this. i rotate my TPs and press my thumbs that it actually works and here i thought gambling wasnt wanted in SL. i have spent hours of perfectly calibrating my TPs and not only are they all completely messed up now, i am barely able to fix it as well.

Oh and before I forget, I do have TPs that i can NOT rotate.


Escort DeFarge added a comment - 29/Feb/08 12:57 PM - edited
I don't believe this issue to be resolved. The avatar's legs are frequently "crushed up" on "dismount". The attempted "fix" for this issue has had a very serious side-effect on avatar/object collisions - see related issue SVC-1705

Darien Caldwell added a comment - 16/Mar/08 08:32 PM
That happend before this issue arose, and is a seperate issue. You should start another JIRA in relation to that issue. I've only seen that when standing on the edge of a prim with a very steep slope. But i've seen that in H1, so no t sure if it's really a H4 bug, or just something we would like not to see.

Zora Spoonhammer added a comment - 09/Apr/08 04:11 PM
Uh, I just tried this today in the release viewer. Avatars are not only being dismounted in random directions, they are launching anywhere from several meters to a full sim away. The rocket chair and the maintenance droids in Areumdeuli both exhibit this behavior in the extreme. The rocket chair is almost two years old, and previously operated flawlessly.

I don't know if it matters, but it's worth noting that both the rocket chair and droids are physics-based objects that allow a passenger, whom they later automatically eject upon reaching their destination. Most other teleporters are not physics-based. This may (or may not) be an important difference.

Question: Is it possible that the unsit operation is causing a momentary interpenetration of the avatar and the object they were previously sitting on, causing the avatar to be launched extreme distances?


AmigaDragon Greatrex added a comment - 22/Apr/08 11:54 PM
I've noticed this since before Havoc 4, being ejected from a TP ball not only throws me into a random direction, it can even force me into a flying condition, even though I wasn't flying when I sat. I also find that it's not an entirely straight vector, I may be thrown flying south, then turn and fly east then north, sometimes gaining altitude too. I am not selecting fly. I can understand having a little force to push me off the seat, but not a multi-vector flight-enabled shove making me fly around in circles or knotted tangles until I click on Stop Flying.

Zora Spoonhammer added a comment - 10/May/08 07:22 PM
Video of the unsit bug in action, a tiny rotational impulse applied to a cube causes long-distance flight of the avatar.

Zora Spoonhammer added a comment - 10/May/08 07:25 PM
Boo-ya! Figured out exactly what causes it. It has to do with rotational impulse: any rotation impulse-even a small one-applied to the object within a second or two of when the avatar is unseated causes the avatar to fly cross-country.

Here's a minimal script that reproduces the behavior:

default
{
state_entry()

{ llSitTarget(<0.5f, 0.0f, 0.7f>, ZERO_ROTATION); llSetStatus(STATUS_PHYSICS, TRUE); llSetBuoyancy(1.0f); }

changed(integer intChange)
{
if ( intChange & CHANGED_LINK ) {
if ( llAvatarOnSitTarget() != NULL_KEY ) { llSetTimerEvent(0.5f); llApplyRotationalImpulse(<0.5, 0.0f, 0.0f>,TRUE); }
}
}

timer()

{ llSetTimerEvent(0.0f); llUnSit(llAvatarOnSitTarget()); }

}

I've attached a movie of the result. Even though the impulse is hardly strong enough to move the cube, my avatar is flung an insane distance.

This bug obviously has clear implications for many vehicles-like objects. The 'bots and the rocket chair in Areum are both effected because they have stability control systems that use a tiny rotational impulse to turn the object back upright when they get bumped.


Zora Spoonhammer added a comment - 10/May/08 08:10 PM
Incidentally, for anyone looking for an easy work-around:

llSetStatus(STATUS_PHYSICS, FALSE);
llUnSit(llAvatarOnSitTarget());
llSetStatus(STATUS_PHYSICS, TRUE);

Fuggly, but seems to do the trick. Note that you'll lose all your momentum if you do this, so this may not be helpful in all circumstances.


Sidewinder Linden added a comment - 19/May/08 01:12 PM
Darien - is this behavior still present on the beta preview? We have done some work on a related issue and I am wondering if this has been rsolved as a result of it already. Thanks, Sidewinder

Darien Caldwell added a comment - 19/May/08 04:40 PM
Having just come from the Beta Grid, I have to say the original issue of unsit ejection has been resolved quite well. Back when I first opened the Issue, it was quite bad, but subsequent Beta iterations mitigated the issue a lot. I had closed the issue, but it was reopened by others who still felt the fix wasn't 'fixy' enough I think though mostly what they were seeing were the effects of closed-space ejection due to interpenetration of the AV and surrounding prims. I don't know if that can ever be resolved, but my original issue has been.

Zee Pixel added a comment - 19/May/08 07:46 PM - edited
Hi, I wouldn't call ejecting me two sims away on the main grid "fixy enough"

Anyways, I just tested this on the Beta grid and still see the problem. It's more of an intermittent problem though, and seems to happen more when there is rotation on more than one axis. It seems more pronounced the more spin there is occurring in the object you are sitting on. Although I still had some pretty severe ejections (nothing like on the main grid) when performing an unsit even from a object just free floating with little motion as seen in the screen shots...

I've attached some screen shots as I can't see how to do video in the beta viewer.


Zee Pixel added a comment - 19/May/08 07:50 PM
A series of screen captures showing unsit behavior:

Second Life 1.20.6 (87323) May 12 2008 17:18:14 (Second Life Mono)

You are at 255270.3, 256266.2, 32.3 in Morris located at sim9.aditi.lindenlab.com (8.4.131.202:13000)
Second Life Beta Server 1.22.0.87831


Christine Etchegaray added a comment - 20/May/08 04:52 AM
Hi there. The unsit behavior is totally erratic, be the sit object physical or not. I went on beta grid to test it with a very simple script and i join the movie of the result. Purpose was to tp my avi on a platform 10m above. Here is the script :

key av;
default
{
state_entry()

{ av = NULL_KEY; rotation my_rot=llGetRot(); vector dest = llGetPos(); dest.z += 11.0; llSitTarget((dest - llGetPos()) / my_rot,ZERO_ROTATION / my_rot); }

changed(integer change)
{
if (change & CHANGED_LINK)
{
av = llAvatarOnSitTarget();
if (av)

{ llUnSit(av); }

}
}
}

Second Life 1.20.6 (87323) May 12 2008 17:18:14 (Second Life Mono)

You are at 255256.1, 256355.1, 35.7 in Morris located at

sim9.aditi.lindenlab.com (8.4.131.202:13000)
Second Life Beta Server 1.22.0.87831

CPU: Intel Core 2 Series Processor (3000 MHz)
Memory: 2559 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.15277

(Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 0/546 (0.0%)


Darien Caldwell added a comment - 20/May/08 08:52 AM
The Test I did on the Beta grid yesterday was to do a Sit TP to a platform 20 meters above me. the dismount was flawless. Tonight I'll compare scripts to see why you are seeing such radically different results from me.

Darien Caldwell added a comment - 20/May/08 04:56 PM
Ok, pardon my fuzzy brain, it's been a few months since I posted this. The sit teleporter we created the JIRA about actually uses Warpos, it's not a sit-target type teleporter. works fine. The type of Teleporter Christine posted works by setting a large offset to the sit target. same result, different mechanism. While the original issue this JIRA was about is resolved, it appears there is a new issue illustrated by Christine's script. I see what she is seeing, however I also see a workaround.

It would appear the script is acting too quickly for either the sim or the viewer to react properly. The avatar is beginning to sit and before that even completes, it's already being unsat. this leads to strange behavior. However, inserting a suitable delay in the script eliminates the issue.

Try this script Christine, and see if you don't see the problem vanish:

key av;
default
{
state_entry()

{ av = NULL_KEY; rotation my_rot=llGetRot(); vector dest = llGetPos(); dest.z += 20.5; // or watever distance you want :) llSitTarget((dest - llGetPos()) / my_rot,ZERO_ROTATION / my_rot); }

changed(integer change)
{
if (change & CHANGED_LINK)
{
av = llAvatarOnSitTarget();
if (av) { llSleep(0.25); llUnSit(av); }
}
}

}


Christine Etchegaray added a comment - 21/May/08 04:00 PM
I tried this a dozen times and it works. Thanks a lot for the workaround Darien !

Cheshyr Pontchartrain added a comment - 27/May/08 08:34 PM
Actually, this workaround is irrelevant. While it helps slightly with sithack ports, it does absolutely nothing on elevators, vehicles, teleporters, or anything else relying on logical sitting and standing behavior.

I went so far as to remove the unsit completely from my elevators, letting the avatar stand up on their own. It did nothing. The second anyone stands up, they're facing the wrong direction, and a random one at that.


Darien Caldwell added a comment - 27/May/08 11:00 PM
Cheshyr, the issue you are referring to is a different issue. It's listed here: http://jira.secondlife.com/browse/SVC-2216

They in fact were facing East it seems.

This issue is now listed as fixed with the Rolling restart going on now.

http://blog.secondlife.com/2008/05/27/second-life-122-server-update-tue-527-thu-529/

But this does show the major issue I have with this JIRA entry. It was entered, fixed, and resolved, but seems to keep being a catch all for every single sit issue people find. It was never meant to be that.

Having said that, I'm going to close it again. If you feel you still have a sit behavior issue, please, start a JIRA entry related to that specific issue.


Zee Pixel added a comment - 28/May/08 06:06 AM
Darien, support was marking it as a catch all, and there was nothing in the subject or description to indicate the very narrow scope of your issue. Sigh... my problem really isn't anything to do with rotating any given direction (as the Jira link in your last comment covers). It's with being catapulted away from an object when being unsit... So I guess I don't know where this should go then.

Darien Caldwell added a comment - 28/May/08 08:56 AM
Well, that's why i closed it, the original issue was resolved, and now there is so many things stuck in it, I can't even tell what your specific issue is. I would strongly suggest opening a new issue under SVC -> Bug -> Physics -> 1.21 Server issues, and fully and completely as possible describe the problem. I guarantee Sidewinder and his team will look into it.

Darien Caldwell added a comment - 28/May/08 09:01 AM
I will add if your issue is the dismounting from a spinning cube, as the photos you uploaded indicate, that isn't likely a bug, but what you would expect. There is a thing called Centrifugal Force, a mass will fly off at a vector when suddenly 'released' from it's spinning parent. I would suggest stopping all spinning before unsitting the avatar. This is likely due to the more realistic nature of Havok 4 as compared to Havok 1.

Zora Spoonhammer added a comment - 28/May/08 09:45 AM
I'd agree... EXCEPT that it happens with even forces of .000001. I write physics simulations for a living, and I guarantee you that is NOT correct behavior. Mico-forces should NOT cause that behavior unless there's something wrong with your integrator, interpentetration, etc.

The cube doesn't even have to be visibly spinning as Zee shows. ANY force, even one too small to actually move the cube, will cause the sit behavior.


Zora Spoonhammer added a comment - 28/May/08 10:03 AM
In fact, it's STOPPING the rotating that causes the bug to manifest in the rocket chair. The chair applies a counter-impulse to cancel any movement before it ejects the avatar, bringing the chair to a dead stop before the unsit operation. Of course, due to floating point inaccuracy and numerical stability, we all know it's impossible to get the forces to exactly zero, but it's as near zero as I am able to achieve via LSL. In previous versions, this worked flawlessly and the avatar was dropped out of the completely stationary chair as you'd expect. Now it launches them.

I think everyone's fine with opening a new bug for this... there just seems to be an emphasis on avoiding duplicates, which is why this was posted here as the title seems very descriptive of the nature of the bug. Unsit is definitely now unpredictable.


Zee Pixel added a comment - 28/May/08 10:03 AM
I'd like to say in my defense, that in that photo that centrifugal force wasn't a factor. I'm not a retard and I understand how physics work. What you didn't see (because I do appear to have problems exporting movies from SL) is that I had several runs where I would unsit from that very cube in the picture that was just floating in the air, doing not much anything except some very slight drifting on multiple axis, and I would sometimes fall straight to the ground, and other times rocket eject half a sim away. It seemed more pronounced if the rotation was happening on two axis, but that might have been a perception thing.

If I've muddled Zora's issue, I apologize, but something clearly seems wrong here, and as I said before, the reason I ended up on this bug is because I had inquired about opening a bug and was told this was the catch all for unsit/eject buggy behavior. Anyways, I'll just bow out and let you guys work through it. Sorry again.


Zora Spoonhammer added a comment - 28/May/08 10:14 AM
> "because I do appear to have problems exporting movies from SL"

W00t. A bug-in-a-bug. It's a bug sandwich! Try RAW compression format. I've never had any of the other codecs work with SL for me, either. (Although they work fine for me with other programs.) You can always re-compress the video into something more reasonable later with Microsoft Movie Maker which comes with many versions of Windows, or any of the other free tools. Just don't let the RAW file go over 2GB or the file will wrap-around and corrupt itself.


Darien Caldwell added a comment - 28/May/08 01:18 PM
Thanks Zora. It does sound like a bug, however I think classing it a an unsit bug is a misleading. It manifests itself when you unsit, but it sounds like a rotational force issue. Maybe reclassifying it as such would get LL looking in the right direction. For what it's worth I tried your code and see the same thing, i'll be voting on your issue.