Difference between revisions of "Talk:Phantom Child"
Aeron Kohime (talk | contribs) (→Oh Wow: new section) |
|||
Line 55: | Line 55: | ||
--[[User:Michelle Resistance|Michelle Resistance]] 17:41, 18 March 2010 (UTC) | --[[User:Michelle Resistance|Michelle Resistance]] 17:41, 18 March 2010 (UTC) | ||
== Oh Wow == | |||
I didn't think this would take off with so many revisions. I decided to post it because I found it useful so long ago. I only recently found it again because of someone selling the script on the market https://marketplace.secondlife.com/p/Dvandva-Phantom-Child-Script/1219467. [[User:Aeron Kohime|Aeron Kohime]] 09:48, 23 March 2011 (PDT) |
Revision as of 08:48, 23 March 2011
Awesome script. Still works as of 9/25/2008. And you can even set the object as physical! (Change the 'flexible-set' by a 'physical-set')—The preceding unsigned comment was added on 16:46, 26 September 2008 by Protector Cone
Reboot?
It has to be reseted on reboot. I wish I knew what event a server reboot causes to script, to avoid that it is not phantom for even 1 second after restart.
Bug Fix
Since this is an exploit of a current bug (jiralink?), would it be possible to estimate how the item reacts once the bug is fixed? Which would be the expected behaviour?
- Script silently fails, child and object staying solid?
- Script shouts an error on debug channel, child and object staying solid?
- Script works, child and object turning phantom?
I'm currently thinking about using it for a friends product but am afraid of the consequences... Others might be too. So it would be noteworthy in the article.
Greetz, Lynch (talk|contribs) 15:26, 28 October 2008 (UTC)
- The only bug I can see in this is enabling flexible on shapes that aren't allowed to be flexible. After the second type change it disables it but (I assume) it forgets to tell the physics engine. If this is the case, the fix would result in the objects staying solid. -- Strife (talk|contribs) 01:11, 6 April 2009 (UTC)
Reboot
llGetTime and llRequestSimulatorData could both work in a loop, but CHANGED_REGION_START is probably the better solution. <lsl> //-- add this
changed (integer vBitChanges){ if (CHANGED_REGION_START & vBitChanges){ llResetScript(); } }</lsl>
I'm adding the change to the main page, but posting this here in case anyone objects to the change Void Singer 18:21, 5 April 2009 (UTC)
- Void, I had to remove your change while testing this script in-world: I got error on CHANGED_REGION_START - that was today on Hippotropolis, running Second Life Server 1.25.6.113484 - --oobscure 15:16, 6 April 2009 (UTC)
- At this point I'm not sure if the CHANGED_REGION_START return value is live on the server. the constant itself obviously (now) isn't live. either someone forgot to update the viewer with the new constant(I think the keyword checking still happens there?), or the wiki page for it got mislabeled/changed(more likely). I changed the code to compile regardless, and if it's live on the server it should work, otherwise it does nothing. unfortunately I can't restart a sim to check. Void Singer 06:33, 8 April 2009 (UTC)
Even better...
A friend of mine recently (3/16/2010) discovered that we can get a much better phantom child effect by calling llVolumeDetect in a prim, linking it to something, and deleting the script:
<lsl> default {
state_entry() { llVolumeDetect(TRUE); }
changed(integer change) { if (change & CHANGED_LINK) { llRemoveInventory(llGetScriptName()); } }
} </lsl>
This appears to persist even after re-rezzing, changing owner several times, and survives toggling phantom on the linkset. Apparently there are already products on the market using this trick to great effect, but I can't find any previous mention of this technique. I'm considering posting this to the JIRA as a "please don't fix!" issue.
--Michelle Resistance 16:39, 18 March 2010 (UTC)
Ok, some experimenting has revealed quirky side-effects to doing this. The collision_start event behaves very oddly in linksets using this technique. Scripts in the root will get collision_start events when phantom children are intersected, but collisions with solid prims in the linkset will trigger a flood of collision_start events. In phantom child prims, no collision_start events are generated at all. Solid child prims seem to have normal collision_start triggering. Prims delinked from the linkset seem to have lingering issues with collision_start events. Please reply here if you discover additional side-effects, or can elaborate on what's been posted.
--Michelle Resistance 17:41, 18 March 2010 (UTC)
Oh Wow
I didn't think this would take off with so many revisions. I decided to post it because I found it useful so long ago. I only recently found it again because of someone selling the script on the market https://marketplace.secondlife.com/p/Dvandva-Phantom-Child-Script/1219467. Aeron Kohime 09:48, 23 March 2011 (PDT)