Difference between revisions of "User talk:Icra Nosferatu"

From Second Life Wiki
Jump to navigation Jump to search
(more collision filter bug updates)
Line 34: Line 34:
:I'm reposting your comments (I hope that is ok) from here to the bug. I'm reopening it. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:52, 6 January 2014 (PST)
:I'm reposting your comments (I hope that is ok) from here to the bug. I'm reopening it. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:52, 6 January 2014 (PST)
::That's great! I'll be watching it, thank you for reopening it. --[[User:Icra Nosferatu|Icra Nosferatu]] 21:59, 6 January 2014 (PST)
::That's great! I'll be watching it, thank you for reopening it. --[[User:Icra Nosferatu|Icra Nosferatu]] 21:59, 6 January 2014 (PST)
::After reading Maestro's response and some further testing, this looks like it might be even more esoteric than it first appeared. following does not reproduce the bug:
<lsl>doThing(){
    llVolumeDetect(TRUE);
    llCollisionFilter("",llDetectedKey(0),FALSE);   
}
default {
    state_entry() {
        llVolumeDetect(FALSE);
    }
    touch_start(integer total_number){
        doThing();
       
    }
    collision(integer total) {
        llOwnerSay("collisions "+(string)total);
    }
}</lsl>
<lsl>doNothing(){}
default {
    state_entry() {
        llVolumeDetect(FALSE);
    }
    touch_start(integer total_number){
        doNothing();
        llVolumeDetect(TRUE);
        llCollisionFilter("",llDetectedKey(0),FALSE);   
    }
    collision(integer total) {
        llOwnerSay("collisions "+(string)total);
    }
}</lsl>
::However, if using the [[collision_start]] event instead of just [[collision]], it reproduces the bug. So, a little more coding... it seems that in this case, the collision filter is in place for the -main- collision event, but not for collision_start or collision_end. I even put the code for them before, after, and around the [[collision]] event code, didn't make a difference (thankfully. That would have been even more wierd). Even with no user defined function, it reproduced the bug. After that, I experimented with what event I did the volume detect change and called the collision filter. It reproduces in both [[touch_start]] and [[touch_end]], but not [[touch]], though event reporting shows that the [[touch]] event happens twice. So, in conclusion, changing the volume detect state in the same event as calling the collision filter results in the filter being applied to [[collision]], but not [[collision_start]] or [[collision_end]].
Final testing script:
<lsl>default {
    state_entry() {
        llVolumeDetect(FALSE);
        llOwnerSay("State Entry");
    }
    touch_end(integer total_number){
        llOwnerSay("touched");
        llVolumeDetect(TRUE);
        llCollisionFilter("",llDetectedKey(0),FALSE);   
    }
    collision(integer total) {
        llOwnerSay("collisions "+(string)total);
    }
    collision_start(integer total) {
        llOwnerSay("collision start "+(string)total);
    }
    collision_end(integer total) {
        llOwnerSay("collision end "+(string)total);
    }
}</lsl>

Revision as of 11:26, 7 January 2014

Welcome to the wiki!

Thank you for contributing to the wiki. I would especially like to thank you for your edit to llCollisionFilter, without your edit I wouldn't have known to go looking into this, I wouldn't have found SVC-2490 (I was looking in preparation to creating a new bug report) which had been prematurely closed, and I wouldn't have reopened it. Lets hope now it will get fixed. Keep up the good work. -- Strife (talk|contribs) 22:13, 5 January 2014 (PST)

I noticed that Maestro has commented that he hasn't been able to repro. I came across it while scripting an orbital laser platform that chases people down. Since I can't seem to comment on the JIRA, I'd like to note that the repro script does seem to work as intended, but the laser still does not and registers all collisions no matter how the collision filter is set. Doing my best to prune through it and find out exactly why that's happening, but I use preproc includes and functions quite heavily. Should be able to pin it down by Thursday. --Icra Nosferatu 20:39, 6 January 2014 (PST)
It seems to be tied to changing the prim from non-volume detect to volume detect. If both are called in the same event, then the llCollisionFilter call seems to be dropped/ignored, no matter if it's before or after the llVolumeDetect change. If, however, they're called in different events (like touch_start and touch_end, or even just touch_start and touch) the collision filter takes. Since I can't comment on the JIRA, here's the script I finally cooked down to:

<lsl>collisionFilter(key id) {

   llOwnerSay("Filter target is " +llKey2Name(id));
   llVolumeDetect(TRUE);
   llCollisionFilter("",id,FALSE);

}

default {

   state_entry() {
       llOwnerSay("state entry");
       llVolumeDetect(FALSE);
   }
   touch_start(integer total) {
       collisionFilter(llDetectedKey(0));
   }
   //Collision events
   collision_start(integer total) {
       llOwnerSay("Collision start "+(string)total);
   }
   collision(integer total) {
       llOwnerSay("Collision "+(string)total);
   }
   collision_end(integer total) {
       llOwnerSay("Collision end "+(string)total);
   }

}</lsl> As for taking until thursday... I cannot leave a script without a bug crushed or pinned to a board in my collection. --Icra Nosferatu 21:32, 6 January 2014 (PST)

I'm reposting your comments (I hope that is ok) from here to the bug. I'm reopening it. -- Strife (talk|contribs) 21:52, 6 January 2014 (PST)
That's great! I'll be watching it, thank you for reopening it. --Icra Nosferatu 21:59, 6 January 2014 (PST)
After reading Maestro's response and some further testing, this looks like it might be even more esoteric than it first appeared. following does not reproduce the bug:

<lsl>doThing(){

   llVolumeDetect(TRUE);
   llCollisionFilter("",llDetectedKey(0),FALSE);    

} default {

   state_entry() {
       llVolumeDetect(FALSE);
   }
   touch_start(integer total_number){
       doThing();
       
   }
   collision(integer total) {
       llOwnerSay("collisions "+(string)total);
   }

}</lsl> <lsl>doNothing(){} default {

   state_entry() {
       llVolumeDetect(FALSE);
   }
   touch_start(integer total_number){
       doNothing();
       llVolumeDetect(TRUE);
       llCollisionFilter("",llDetectedKey(0),FALSE);    
   }
   collision(integer total) {
       llOwnerSay("collisions "+(string)total);
   }

}</lsl>

However, if using the collision_start event instead of just collision, it reproduces the bug. So, a little more coding... it seems that in this case, the collision filter is in place for the -main- collision event, but not for collision_start or collision_end. I even put the code for them before, after, and around the collision event code, didn't make a difference (thankfully. That would have been even more wierd). Even with no user defined function, it reproduced the bug. After that, I experimented with what event I did the volume detect change and called the collision filter. It reproduces in both touch_start and touch_end, but not touch, though event reporting shows that the touch event happens twice. So, in conclusion, changing the volume detect state in the same event as calling the collision filter results in the filter being applied to collision, but not collision_start or collision_end.

Final testing script: <lsl>default {

   state_entry() {
       llVolumeDetect(FALSE);
       llOwnerSay("State Entry");
   }
   touch_end(integer total_number){
       llOwnerSay("touched");
       llVolumeDetect(TRUE);
       llCollisionFilter("",llDetectedKey(0),FALSE);    
   }
   collision(integer total) {
       llOwnerSay("collisions "+(string)total);
   }
   collision_start(integer total) {
       llOwnerSay("collision start "+(string)total);
   }
   collision_end(integer total) {
       llOwnerSay("collision end "+(string)total);
   }

}</lsl>