Difference between revisions of "User talk:Icra Nosferatu"
(more collision filter bug updates) |
(update addendum) |
||
Line 67: | Line 67: | ||
} | } | ||
}</lsl> | }</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]]. | ::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]]. Addendum: I herpd a derp. It seems that [[llVolumeDetect]] doesn't generate a main collision event anyway. Discovered this when I inverted the change to TRUE>FALSE and it still generated a main collision event (as well as start and end) despite the filter. | ||
Final testing script: | Final testing script: | ||
<lsl>default { | <lsl>default { | ||
Line 89: | Line 89: | ||
} | } | ||
}</lsl> | }</lsl> | ||
::--[[User:Icra Nosferatu|Icra Nosferatu]] 11:42, 7 January 2014 (PST) |
Latest revision as of 11:42, 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. Addendum: I herpd a derp. It seems that llVolumeDetect doesn't generate a main collision event anyway. Discovered this when I inverted the change to TRUE>FALSE and it still generated a main collision event (as well as start and end) despite the filter.
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>
- --Icra Nosferatu 11:42, 7 January 2014 (PST)