Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006892opensim[REGION] OpenSim Corepublic2013-12-14 16:152014-07-29 13:42
ReporterMata Hari 
Assigned Tojustincc 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformIntel i7 930 quad coreOSWindows .NETOS VersionWin7 x64
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0006892: Sit targets seem randomly borked with r/24130
DescriptionI updated to r/24130 opensim-00e632e today and find that about 50% of the prims I have with sit targets already set are now completely wrong and seemingly randomly so. With broken ones, the avi could end up in almost any position or orientation and it doesn't seem to be consistent in any way, other than that standing up and sitting again will always put you back in the same wrong position (so it isn't varying from sit to sit) and if you make a copy of the prim and sit on the copy, it will also exhibit the exact same error.

The only thing I can see that might differentiate between the ones that are broken and the ones that aren't is the rotation of the sit target. The prims with sit targets that involve only a position offset and little or no rotation seem to be okay...any that aren't ZERO_ROTATION seem to be borked to varying degrees.
TagsNo tags attached.
Git Revision or version numberr/24130 opensim-00e632e
Run Mode Standalone (Multiple Regions)
Physics EngineBulletSim
Environment.NET / Windows64
Mono VersionNone
ViewerFirestorm 4.5.1 (38838)
Attached Filesjpg file icon example.jpg [^] (777,168 bytes) 2013-12-14 16:34
jpg file icon Scren-shot-1-r24153.jpg [^] (179,740 bytes) 2013-12-24 12:11


jpg file icon Scren-shot-2-r24153.jpg [^] (198,487 bytes) 2013-12-24 12:12


patch file icon sitrot.patch [^] (1,450 bytes) 2014-01-05 22:56 [Show Content]

- Relationships

-  Notes
(0024870)
Mata Hari (reporter)
2013-12-14 16:22
edited on: 2013-12-14 16:23

Experimenting further...


You can clearly reproduce this issue as follows:

1. Rez a simple cube
2. Sit on it
3. Rotate the cube 90 degrees on either the X or Y axis while you are still sitting on it
4. Make a note of your position/rotation
5. Stand up and then sit again...your sit position will be quite different than it was moments earlier.

This will happen even with no sit target set.

(0024871)
melanie (administrator)
2013-12-14 22:06

If this is a very recent release, then please read the ML and chat announcements - TRUNK is BROKEN. Sitting is one part that is currently NOT working. Please use the last announced good version or use branch justincc-master for the time being. The work being done includes massive changes to the way sits happen. Sitting on child prims is currently completely unpredictable and root prims are iffy This is due to the fact that a partial change has been committed but the LSL and Scene parts corresponding to it are not yet in core. Please don't use officially broken versions.
(0024872)
Mata Hari (reporter)
2013-12-15 02:25
edited on: 2013-12-15 02:25

I was under the impression that r/24130 was the justincc-master but perhaps I misunderstood.

(0024873)
Bruce (reporter)
2013-12-15 14:19

I can confirm this is happening as early as r24105, i.e. before trunk was broken. In my case it only happens when agent is laying down. Instead of laying down horizontally on his/her back, the agent lies down on his/her side. The objects (bed, lounge chair, etc.) contain a laying down script that worked up to r24091. Probably due to the script, the agent is always laying down on his/her right hand side. Objects (chairs, etc.) with scripts for sitting down (chairs, etc.) still work correctly with r24105.
(0024876)
Mata Hari (reporter)
2013-12-16 16:09

Have now downloaded and applied jcc master (opensim-51da52f) as per the link provided by Justin...identical results with sit target being incorrect when sitting on any prim with non-zero rotation.
(0024877)
justincc (administrator)
2013-12-16 16:12

Okay, I will take a look when I can. Sounds like this was broken before the merge.
(0024878)
Mata Hari (reporter)
2013-12-16 17:32
edited on: 2013-12-16 17:32

I am fairly sure I was using r/24105 prior to this and at that time it wasn't broken so it's something that changed since then...perhaps something related to "refix sit" r/24112?

(0024907)
justincc (administrator)
2013-12-20 14:48

Could you give me a specific example script and set of steps? As far as I know, when sitting on a prim without a sit target, it's expected that the avatar will sit differently depending on which direction you are facing when you sit. You can see the same effect on the LL grid, albeit there are fewer different positions that avatars sit in.
(0024913)
Mata Hari (reporter)
2013-12-21 08:27
edited on: 2013-12-21 08:29

Ah yes, with no sit target set that's true; however I can definitely reproduce it as follows:

1. Launch an "old" instance -- the test I did was to d/l the current OSG build from Nov.30 r/24087

2. Log in and rez a cube.

3. Put this in it:
default
{
    state_entry()
    {
        llSitTarget(<-0.259146,-0.643980,0.338205>, <-0.653290,0.270578,0.270618,-0.653273>);
        llRemoveInventory(llGetScriptName());
    }
}

4. Sit down and take careful note/screencap of your seated position/rotation relative to the cube.

5. Stand, rez a second cube and put this in it:
default
{
    state_entry()
    {
        llSitTarget(<-0.259146,-0.643980,0.338205>,ZERO_ROTATION);
        llRemoveInventory(llGetScriptName());
    }
}

6. Sit and again take careful note/screencap of your position/rotation.

7. Stand, log out, shut down instance.

8. Load the same region using a newer build (I just tested using jcc-master r/24152)

9. Log in, sit back down on the first cube and you'll see that the position and rotation are completely different than they were

10. Stand, sit on the second cube and you'll see that it's unchanged.

(optional) 11. Repeat that process with the current dev master and you'll see it's the same as the jcc master


So what this means is any object with a sit target that has non-zero rotation will be "broken" when a region runs the new code (= a lot of unhappy campers).


EDIT: not that it should make any difference, but when I was doing this I set the default touch action for each cube to "sit" so I wasn't right-click>sitting

(0024915)
mewtwo0641 (reporter)
2013-12-21 20:37

I am unsure if this is related to this particular issue, but I have noticed similar effects in objects with multiple links utilizing a scripted sit target set (such as a pose ball with pose script). If the scripted prim itself is root prim the rotations appear to work properly (assuming ZERO_ROTATION); if the root prim is set to something other than the scripted prim then the rotation of the avatar appears to take on the rotation property of that prim instead. This can be seen by relinking random prims in a link set to be root which have different rotations and then attempt to sit.
(0024916)
Bruce (reporter)
2013-12-24 12:14

This is still happening with r24153 of 21 Dec 13 (see attached screen shots).
(0024943)
danbanner (manager)
2014-01-05 17:12

This seems to mostly affect sitting on root prims in a linkset or on single prims
(0024944)
tglion (reporter)
2014-01-05 23:09

commit 17b32b764acd815400d9eb903aaec6dcebd60ac7
Author: Justin Clark-Casey (justincc) <jjustincc@googlemail.com>
Date: Thu Dec 5 02:10:46 2013 +0000

This comment:
// body rotation. It does not affect sitting avatar since it's the sitting part rotation that takes
// effect, not the avatar rotation.
This statement seem not realy true?

I have uploaded a small patch, that should resolve this problem.
The patching of the comment is not yet done with this patch.
(0024951)
justincc (administrator)
2014-01-07 17:32

Thanks tglion, this is an issue where body rotation was not being properly transmitted - I have used your changes as is with a change to the comments. I have applied this to both justincc-master and master. Feedback from both would be appreciated.
(0024954)
Mata Hari (reporter)
2014-01-08 01:47

Tested with r/24172 and this seems to have resolved the issue for all objects in my regions.

- Issue History
Date Modified Username Field Change
2013-12-14 16:15 Mata Hari New Issue
2013-12-14 16:22 Mata Hari Note Added: 0024870
2013-12-14 16:23 Mata Hari Note Edited: 0024870 View Revisions
2013-12-14 16:34 Mata Hari File Added: example.jpg
2013-12-14 22:06 melanie Note Added: 0024871
2013-12-15 02:25 Mata Hari Note Added: 0024872
2013-12-15 02:25 Mata Hari Note Edited: 0024872 View Revisions
2013-12-15 14:19 Bruce Note Added: 0024873
2013-12-16 16:09 Mata Hari Note Added: 0024876
2013-12-16 16:12 justincc Note Added: 0024877
2013-12-16 16:13 justincc Assigned To => justincc
2013-12-16 16:13 justincc Status new => assigned
2013-12-16 17:32 Mata Hari Note Added: 0024878
2013-12-16 17:32 Mata Hari Note Edited: 0024878 View Revisions
2013-12-20 14:48 justincc Note Added: 0024907
2013-12-21 08:27 Mata Hari Note Added: 0024913
2013-12-21 08:29 Mata Hari Note Edited: 0024913 View Revisions
2013-12-21 20:37 mewtwo0641 Note Added: 0024915
2013-12-24 12:09 Bruce File Added: Scren-shot-1-r24153.png
2013-12-24 12:09 Bruce File Deleted: Scren-shot-1-r24153.png
2013-12-24 12:11 Bruce File Added: Scren-shot-1-r24153.jpg
2013-12-24 12:12 Bruce File Added: Scren-shot-2-r24153.jpg
2013-12-24 12:14 Bruce Note Added: 0024916
2014-01-05 17:12 danbanner Note Added: 0024943
2014-01-05 22:56 tglion File Added: sitrot.patch
2014-01-05 23:09 tglion Note Added: 0024944
2014-01-07 17:32 justincc Note Added: 0024951
2014-01-08 01:47 Mata Hari Note Added: 0024954
2014-01-08 01:47 Mata Hari Status assigned => resolved
2014-01-08 01:47 Mata Hari Fixed in Version => master (dev code)
2014-01-08 01:47 Mata Hari Resolution open => fixed
2014-07-29 13:42 chi11ken Status resolved => closed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker