|
|
|
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
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.
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? 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.
Video of the unsit bug in action, a tiny rotational impulse applied to a cube causes long-distance flight of the avatar.
Boo-ya! Figured out exactly what causes it. It has to do with rotational impulse: any rotation impulse-
Here's a minimal script that reproduces the behavior: default changed(integer intChange) 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. Incidentally, for anyone looking for an easy work-around:
llSetStatus(STATUS_PHYSICS, FALSE); 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. 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
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
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. 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) 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; changed(integer change) } 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) CPU: Intel Core 2 Series Processor (3000 MHz) (Mozilla GRE version 1.8.1.13_0000000000) 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.
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; changed(integer change) } I tried this a dozen times and it works. Thanks a lot for the workaround Darien !
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. 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. 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.
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.
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.
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. 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. 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. > "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. 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.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Oh and before I forget, I do have TPs that i can NOT rotate.