SLJiraStats : Bug: SVC-5923

SLJiraStats Bug: SVC-5923

Main Menu - Search For Bugs - Responsiveness Statistics

child prims with multiple scripts are incorrectly passing touch events to root prim

Reporter:	Soft Linden
Assignee:	Andrew Linden
Votes:	0
Environment:	n/a
Status:	Resolved
Resolution:	Fixed
Created:	2010-06-16 13:35:19-04
Updated:	2010-06-28 17:08:14-04
Linden ID:	DEV-51204
Components:	Simulation

From issue filed in SEC:

New Server has issues with what appears to be llDetectedTouchFace()

I got a stable to test to work... I made a new script and added this:

default
{
state_entry()
{ llSay(0, "Hello, Avatar!"); }

touch_start(integer total_number)
{ llSay(0, (string)llDetectedTouchFace(0) ); }

}

Touched what I know to be prim 9 and it reported 6. Dragged the following into the touched sub-prim:

default
{
state_entry()
{ llOwnerSay( "Prim '" + llGetObjectName() + "' is link number " + (string)llGetLinkNumber() ); llRemoveInventory(llGetScriptName()); }

}

It properly identified itself as prim #9

Comments

Maestro Linden 2010-06-16 13:48:17-04

I created a simple sample script to test if llDetectedTouchFace and llDetectedLinkNumber. If you run this script in the root prim of an object, any prim face you touch should turn into a random greyscale color:

default
{
    touch_start(integer total_number)
    {
        
        llSetLinkColor(llDetectedLinkNumber(0),<1,1,1>*llFrand(1.0),llDetectedTouchFace(0));
    }
}

I tested this out on 1.40.0.205924, and these functions appear to detect the correct link/face numbers.

Moon Metty 2010-06-16 13:51:54-04

Hi Soft,

llDetectedTouchFace Is supposed to return the number of the face on the prim you're touching, not the link-number.
In the first test, if you touch the prim on another face, do you get a different result?

Soft Linden 2010-06-16 13:57:20-04

Moon, I haven't touched any of this. I merely pasted code that a resi misfiled as a security issue.

Moon Metty 2010-06-16 14:17:01-04

No problem, it looks like expected behaviour then

Maestro Linden 2010-06-16 15:33:52-04

I worked with the original reporter some more. It seems that the problem doesn't lie with llDetectedFace or llDetectedLinkNumber, but rather the handling of touch event passing.

The object in question has a script with a touch_start event in the root prim, and another script with a touch_start event in link #9. There is no llPassTouches() call, so touch passing should follow the default behavior:

touching any child prim with a touch event should not trigger a touch event in the root prim
touching any child prim without a touch event should trigger a touch event in the root prim
The problem is that (1) is failing in some (but not all) instances of the object - the touch_start event is triggering in both the child prim and the root prim.

I tried a minimal repro setup like this:
1) Rez 2 boxes and link them together
2) Put this script in both the root prim and the child prim:

default
{
    touch_start(integer total_number)
    {
        llSay(0, "Touched link "+(string)llGetLinkNumber());
    }
}

3) Touch the child prim and notice the output
Expect:
Only the child prim's touch event should trigger, the output should be "Touched link 2" (there should not be a "Touched link 1" message).
.. but so far, I'm only seeing the expected behavior.

Andrew Linden 2010-06-17 12:22:43-04

I'm updating the summary of this bug to be more correct. The problem is that some child prims will incorrectly pass the touch event to the root prim.

The bug happens when there are multiple scripts on a child prim, at least one that has a touch handler, at least one other that does not, AND the other must try to process the touches first (that is, it probably has to be added to the child prim first).

I've got a fix for this and we'll be testing it more today.

Andrew Linden 2010-06-18 16:36:24-04

A fix is pending. This will be included in the final version of server-1.40.

Kitto Flora 2010-06-24 14:32:47-04

If a child prim that has 'glow' and a touch-intercepting script is touched the touch event is passed along to the root, the child does not get an event.

Maestro Linden 2010-06-24 19:01:18-04

Here's how 1.38 reacts when a child prim is touched:

If any script in the child prim has llPassTouches(PASS_ALWAYS), pass all child prim touches to the root prim
Else If any script in the child prim has a touch event handler, don't pass any child prim touches to the root prim
Else pass all child prim touches to the root prim

1.40 includes some new PASS_* constants, which llPassTouches and llPassCollisions use. Here's how the constants are defined.
PASS_IF_NOT_HANDLED=0 (same as 'FALSE')
PASS_ALWAYS=1 (same as 'TRUE')
PASS_NEVER=2

Here's how 1.40.2 should react when a child prim is touched:

If any script in the child prim has llPassTouches(PASS_NEVER), don't pass any child prim touches to the root prim
Else If any script in the child prim has llPassTouches(PASS_ALWAYS), pass all child prim touches to the root prim
Else If any script in the child prim has a touch event handler, don't pass any child prim touches to the root prim
Else pass all child prim touches to the root prim

So 1.40.2 should exactly behave the same as 1.38, except if one of the scripts in the child prim have lPassTouches(PASS_NEVER). This appears to be working properly on 1.40.2.206322, which is currently deployed to Aditi ("Beta grid"). Collisions with objects (collision events) should follow the same flow as touch, and are controlled by llPassCollisions.

Disable Ads