|
OneBigRiver Stork
Diversity matters
Join date: 29 Mar 2006
Posts: 44
|
01-05-2007 06:48
Has anyone else seen this bug? I reported it, and posted about it in the llGiveInvetory comments at the wiki. ( http://lslwiki.com/lslwiki/wakka.php?wakka=llGiveInventory&show_comments=1#Comment3404) Here is the brief synopsis: Create two prims, and link them. Drop this script into the root prim, then drop any object (I used a snapshot, with full permissions) named "A" into the root prim's inventory. An infinite loop results. default { state_entry() {}
changed(integer change) { if(change & CHANGED_INVENTORY) { key k = llGetLinkKey(2); llOwnerSay(llGetDate() + " Giving inventory"); llGiveInventory(k, "A"); } } }
As far as I can tell, it is llGiveInventory that is triggering changed in the GIVING (root) prim. But, of course, the inventory of the root prim only changed once, when you dropped the "A" object in there. I have not been able to find any other reports of this bug, so I reported it and posted a comment on the wiki. Could someone else try it out, and see if the repro works for them too? Or am I missing something obvious here?  On the wiki comment there is another version of the script that uses a timer to actually do the giveinventory call, so I could verify that I wasn't getting multiple changed events queued up when I do the first change. The second changed() is not triggered until after the timer fires, and llGiveInventory is called. I'm trying to think of a work-around that won't break once the bug is fixed. Simply keeping a variable that notes whether or not the "spare" change has arrived yet would break things once the bug is fixed, so right now I'm using a timer and flag variable to ignore all changes that occur right after the llGiveInventory. 
|
|
Elsewhere Essex
Registered User
Join date: 8 Sep 2006
Posts: 50
|
01-05-2007 10:07
From: OneBigRiver Stork Has anyone else seen this bug? I reported it, and posted about it in the llGiveInvetory comments at the wiki. ( http://lslwiki.com/lslwiki/wakka.php?wakka=llGiveInventory&show_comments=1#Comment3404) Here is the brief synopsis: Create two prims, and link them. Drop this script into the root prim, then drop any object (I used a snapshot, with full permissions) named "A" into the root prim's inventory. An infinite loop results. default { state_entry() {}
changed(integer change) { if(change & CHANGED_INVENTORY) { key k = llGetLinkKey(2); llOwnerSay(llGetDate() + " Giving inventory"); llGiveInventory(k, "A"); } } }
As far as I can tell, it is llGiveInventory that is triggering changed in the GIVING (root) prim. But, of course, the inventory of the root prim only changed once, when you dropped the "A" object in there. I have not been able to find any other reports of this bug, so I reported it and posted a comment on the wiki. Could someone else try it out, and see if the repro works for them too? Or am I missing something obvious here?  On the wiki comment there is another version of the script that uses a timer to actually do the giveinventory call, so I could verify that I wasn't getting multiple changed events queued up when I do the first change. The second changed() is not triggered until after the timer fires, and llGiveInventory is called. I'm trying to think of a work-around that won't break once the bug is fixed. Simply keeping a variable that notes whether or not the "spare" change has arrived yet would break things once the bug is fixed, so right now I'm using a timer and flag variable to ignore all changes that occur right after the llGiveInventory.  there is a secondinventory change taking place in your script/object the CHANGED_INVENTORY event fires in the root prim when child prims in a linked set have inventory changes as well so, your script see's 2 distinct inventory changes, the first when the root prim recieves the drop inventory, and again when the root gives link 2 that droped inventory
|
|
OneBigRiver Stork
Diversity matters
Join date: 29 Mar 2006
Posts: 44
|
01-05-2007 12:01
From: Elsewhere Essex there is a secondinventory change taking place in your script/object the CHANGED_INVENTORY event fires in the root prim when child prims in a linked set have inventory changes as well so, your script see's 2 distinct inventory changes, the first when the root prim recieves the drop inventory, and again when the root gives link 2 that droped inventory Well, that would make sense. I thought it was not supposed to do this, because the lslwiki entry for changed() says that changes in the inventories of linked objects do not raise changed(). See http://lslwiki.com/lslwiki/wakka.php?wakka=changedAh well. I'll try to do it a different way.
|