[BUG-42] Physical flexi attachments when dropped from avatar fall through solid prims

[sl-service-account]

Steps to reproduce:

• Stand on a build platform, or on any solid prim floor, as long as you are not standing on terrain
• Rez a cube prim
• Edit cube and make it Physical
• Wear the cube
• Edit attached cube and make it a flexi
• Drop the cube

Observed behaviour: Cube falls through all prims in its path and lands on the terrain

Expected behaviour: Cube lands on the floor

Attachments

• physical_remains_checked.jpg 2012-09-13 14:04:29

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-42 | | Summary | Physical flexi attachments when dropped from avatar fall through solid prims | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Released | | Reporter | Whirly Fizzle (whirly.fizzle) | | Created at | 2012-09-08T22:29:58Z | | Updated at | 2014-03-10T21:30:35Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2012-09-09T11:51:35.613-0500', "Is there anything you'd like to add?": 'blah', 'System': 'SL Simulator', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'Blah will edit once created because this form is useless', 'What were you doing when it happened?': 'blah', 'What were you expecting to happen instead?': 'blah', } ```

[sl-service-account]

Whirly Fizzle commented at 2012-09-08T23:04:55Z, updated at 2012-09-08T23:06:12Z

On this new form, there is nowhere now to distinguish which server versions server bugs repro on. I would have thought that's quite important.

[sl-service-account]

Strife Onizuka commented at 2012-09-09T16:51:36Z

Flexi prims are forced to be phantom. This is unfortunately the expected behavior.

[sl-service-account]

Strife Onizuka commented at 2012-09-09T16:52:42Z

It's in the environment string.

[sl-service-account]

Whirly Fizzle commented at 2012-09-09T18:55:04Z

Ahhh! Kinda weird though, you can hear the collisions as the physical flexi falls through whats in its way to the terrain. I didnt actually realise you could have a prim that was both physical and flexi untill I was looking at VWR-29665

I know the server version Im on when I pull system info shows in environment, but I may not have pulled that from where I actually tested. I was meaning, there is no way to indicate in the fields of the report what server versions the bug repros on. Now its just SL Simulator, and which component. If I found a bug that only repros on Bluesteel and Magnum for example, my environment info isnt going to show that. This means you cannot search new BUG reports for issues that only occur on one of the RC regions for example. There is also no indication to the filer that they should check if the bug is reproducible on different server versions. I did ask Oskar about this and he sighed and said it needed to be fixed :D

[sl-service-account]

Maestro Linden commented at 2012-09-10T19:00:46Z

This seems to be classic behavior. I see the same results on 12.04.30.255166 (region Commerce on Aditi), which is a pre-pathfinding simulator version; an unlinked physical flexi box becomes phantom, and falls through solid prims.

This behavior is also well documented; from https://wiki.secondlife.com/wiki/Flexi :

A side affect of enabling flexible is that phantom is also enabled.

[sl-service-account]

Whirly Fizzle commented at 2012-09-10T19:06:49Z

Thanks Maestro :)

[sl-service-account]

Moon Metty commented at 2012-09-10T23:55:12Z, updated at 2012-09-11T00:15:40Z

There was a discussion in the 'Bug Bashers' groupchat about http://jira.phoenixviewer.com/browse/SVC-2 This is not expected behaviour, as flexible objects aren't supposed to be physical.

[sl-service-account]

Maestro Linden commented at 2012-09-11T00:04:29Z

Hm, I do see that the viewer UI disables the 'physical' checkbox if an unlinked object is flexi, so I had to use llSetStatus(STATUS_PHYSICS, TRUE) to enable physics my test object.

I suppose one could consider it a bug that scripts can enable physics for flexi objects, but on the other hand we allow non-flexi phantom objects to go physical via scripts or the build tool, which also causes them to fall through other objects.

[sl-service-account]

Moon Metty commented at 2012-09-11T00:18:27Z

Should I register at the firestorm jira, and pass on your information now, Maeastro?

[sl-service-account]

Maestro Linden commented at 2012-09-11T00:25:41Z

At this point I want to wait for our next triage so we can get some more opinions. Right now, the only documented special behavior about flexi is that when you enable flexi, phantom is also automatically enabled for the prim.

[sl-service-account]

Moon Metty commented at 2012-09-11T00:54:15Z, updated at 2012-09-11T01:06:50Z

It's a case of undefined behaviour, I guess. Actually, it makes sense as a viewer issue: "Setting an attachment to flexible doesn't turn off the physical-bit"

[sl-service-account]

Strife Onizuka commented at 2012-09-11T04:36:20Z, updated at 2012-09-13T16:48:24Z

As to the behavior, I think it is wrong. Ideally it should set PRIM_PHYSICS_SHAPE_NONE for the flexiprim instead of turning the object phantom. Since some folks will be relying upon the current functionality, I suggest an alternative.

If a prim is PRIM_PHYSICS_SHAPE_NONE, and then is set flexi, it should not change the object phantom. If the user tries to disable PRIM_PHYSICS_SHAPE_NONE while flexi, it should fail and stay PRIM_PHYSICS_SHAPE_NONE. This way you could have a flexi physical object that doesn't have to fall through things.

[sl-service-account]

Maestro Linden commented at 2012-09-13T17:20:19Z

Hi Strife, setting an object to PRIM_PHYSICS_SHAPE_NONE wouldn't change this 'bug' at all, since an object with no physics shape won't collide with any prim floors. Also, enabling PRIM_PHYSICS_SHAPE_NONE on a prim would make the linkset use new prim accounting, which could increase land impact, so we don't want to make this an automated change. If somebody wants that behavior (for slightly better physics performance, or so that the prim doesn't collide with terrain), they can enable it manually via the build tool.

We triaged this again, and we don't have any clear 'bug', or a solution that doesn't break existing content. I think the solution is to not enable physics on objects that are intended to be attachments - you shouldn't do that unless you want the object to physically move when dropped.

[sl-service-account]

Moon Metty commented at 2012-09-13T18:04:29Z

Phantom & physical is an awkward combination, because the prim falls to a place where you might not find it. That's why the viewer explicitly turns off and greys out the physical checkbox when you enable flexi.

Using 1.23.5 , when setting a physical attachment to flexi, a notification pops up:

"This object is flexible. Flexible objects may not be physical and must be phantom until the flexible checkbox is unchecked"

The physical checkbox is greyed out, but it remains checked. Whether you drop the prim, or detach and rez, the result is the same: you have to chase an escaped phantom.

It's a small bug, but it's a bug.

[sl-service-account]

Maestro Linden commented at 2012-09-13T18:27:42Z

So what is the expected behavior, is it that you shouldn't be able to enable flexi on an attached object which has the physics flag enabled?

[sl-service-account]

Moon Metty commented at 2012-09-13T18:45:13Z, updated at 2012-09-13T18:56:45Z

Ummm no, enabling flexi should work the same as it does when it's rezzed: grey out and uncheck the physical checkbox. :)

[sl-service-account]

Maestro Linden commented at 2012-09-17T18:47:00Z

Here's a summary of the behavior for 1-prim objects when a user enables the flexi flag:

• If the object is non-physical and not attached to an avatar, when the user enables flexi, the object automatically becomes phantom
• If the object is non-physical and attached to an avatar, when the user enables flexi, the object automatically becomes phantom
• If the object is physical and not attached to an avatar, when the user enables flexi, the object automatically becomes phantom and becomes non-physical
• If the object is physical and attached to an avatar, the user enables flexi, the object automatically becomes phantom (the 'bug' is that it doesn't lose its physics flag, as it does in the previous case)

Other behavior of 1-prim flexi objects:

• The viewer UI disables toggling the Physical and Phantom checkboxes if the object is flexi.
• A script can change the physics status at any time via llSetStatus(STATUS_PHYSICS, x)
• A script cannot change the phantom status at any time via llSetStatus(STATUS_PHANTOM, x) - phantom is always enabled

Here's a summary of the behavior for multi-prim objects when a user enables the flexi flag; it follows the single-prim case.

• If the linkset is non-physical and not attached to an avatar, when the user enables flexi in any prim, the linkset automatically becomes phantom
• If the linkset is non-physical and attached to an avatar, when the user enables flexi in any prim, the linkset automatically becomes phantom
• If the linkset is physical and not attached to an avatar, when the user enables flexi in any prim, the object automatically becomes phantom and becomes non-physical
• If the linkset is physical and attached to an avatar, when the user enables flexi in any prim, the object automatically becomes phantom

Other behaviors of multi-prim flexi linksets:

• The viewer UI disables toggling of the Physical and Phantom checkboxes if the root prim is flexi.
• The viewer UI dies not disable toggling of the Physical and Phantom checkboxes if root prim is non-flexi and a child prim is flexi.
• A script cannot change the phantom status at any time via llSetStatus(STATUS_PHANTOM, x) if the root prim is flexi - the object is always phantom
• A script can change the phantom status at any time via llSetStatus(STATUS_PHANTOM, x) if the only flexi prims are child prims - the flexi prims always remain phantom, but the non-flexi prims change their flexi status as you'd expect
• A script can change the physics status at any time via llSetStatus(STATUS_PHYSICS, x), regardless of the flexi state of the root or child prims

To be more consistent, I guess we could change 2 things:

• Enable toggling of physics via viewer UI the cases where LSL scripts can change it
  • This change would affect cases in which the root prim is flexi
• Automatically disable the physics flag when flexi is enabled in any prim of an attached object
  • This may break content in weird edge cases (objects which expect to remain physical), so I'm not sure if it's worthwhile

[sl-service-account]

Strife Onizuka commented at 2012-09-17T21:57:19Z

Isn't PRIM_PHYSICS_SHAPE_NONE a prim attribute and not an object attribute? The idea is to only set the physics shape to none on the prim that is to be flexible, leaving the rest of the object unchanged.

I agree that we don't want to change how current objects are accounted for. Which is why I'm suggesting that the user has to explicitly set the physics shape to none before setting flexible to get the new functionality, eg. the entire object doesn't turn phantom. Existing objects won't be affected.

However, if the flexiprim is the root, naturally you can't set it to NONE and thus it has to turn the object phantom, etc.

So here is my suggestion spelled out as a table. The first four preserve the current functionality. The last four add the new functionality, and allow for a multi-prim physical object with flexi children to still be non-phantom.

• If the linkset is non-physical and not attached to an avatar, when the user enables flexi in any prim that is not PRIM_PHYSICS_SHAPE_NONE, the linkset automatically becomes phantom
• If the linkset is non-physical and attached to an avatar, when the user enables flexi in any prim that is not PRIM_PHYSICS_SHAPE_NONE, the linkset automatically becomes phantom
• If the linkset is physical and not attached to an avatar, when the user enables flexi in any prim that is not PRIM_PHYSICS_SHAPE_NONE, the object automatically becomes phantom and becomes non-physical
• If the linkset is physical and attached to an avatar, when the user enables flexi in any prim that is not PRIM_PHYSICS_SHAPE_NONE, the object automatically becomes phantom
• If the linkset is non-physical and not attached to an avatar, when the user enables flexi in any prim that is PRIM_PHYSICS_SHAPE_NONE, the linkset phantom attribute is unchanged
• If the linkset is non-physical and attached to an avatar, when the user enables flexi in any prim that is PRIM_PHYSICS_SHAPE_NONE, the linkset phantom attribute is unchanged
• If the linkset is physical and not attached to an avatar, when the user enables flexi in any prim that is PRIM_PHYSICS_SHAPE_NONE, the object phantom and physical attribute are unchanged
• If the linkset is physical and attached to an avatar, when the user enables flexi in any prim that is PRIM_PHYSICS_SHAPE_NONE, the object phantom attribute is unchanged

[sl-service-account]

Moon Metty commented at 2012-09-18T09:57:08Z, updated at 2012-09-18T11:19:20Z

Hrrmm. Apparently, the server rejects all changes to the locked, physical, temporary and phantom settings in attachments (whether by script or by viewer tools). This behaviour is not new, looking at SVC-6549, and may be subject to change.

An exception is that phantom is enabled by turning on flexible in the viewer. Of course, turning flexible off doesn't disable phantom again, but that's not the issue here.

=======

Concerning disabling physical when flexible is turned on: If this behaviour doesn't break rezzed content, how can it possibly break attached content?

Also, when you run this script in a physical attached prim:

default
{
    state_entry()
    {
        llSetPrimitiveParams([PRIM_FLEXIBLE, TRUE, 3, 3, 3, 3, 3, ZERO_VECTOR]); 
    }
}

Two things happen:

• Phantom is enabled.

• Physical is disabled. :)

  [Note: PRIM_TEMP_ON_REZ actually works in attachments.]