Difference between revisions of "Talk:Phantom Child"

From Second Life Wiki
Jump to navigation Jump to search
(Comments on two threads)
m
 
Line 61: Line 61:


:Selling a feebie? Who'd have imagined such a thing possible in SL? <--- Sarcasm. Some folk just have no scruples do they? Thankfully though other folk do or scripts like these might cost a fortune. -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 14:11, 24 July 2011 (PDT)
:Selling a feebie? Who'd have imagined such a thing possible in SL? <--- Sarcasm. Some folk just have no scruples do they? Thankfully though other folk do or scripts like these might cost a fortune. -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 14:11, 24 July 2011 (PDT)
The script I sell at Dvandva and on Markeplace is not the same script... this script long ago fixed the issue of persistence and also works for sculpties and at the same time protects the sculpts uuid thru encryption
--[[User:Rian Jayaram|Rian Jayaram]] 20:58, 26 June 2012 (PDT)


== Caveat needed? ==  
== Caveat needed? ==  

Latest revision as of 19:58, 26 June 2012

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?

  1. Script silently fails, child and object staying solid?
  2. Script shouts an error on debug channel, child and object staying solid?
  3. 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, Zai signature.png 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. —Aeko Signature.png Aeron Kohime 09:48, 23 March 2011 (PDT)

Selling a feebie? Who'd have imagined such a thing possible in SL? <--- Sarcasm. Some folk just have no scruples do they? Thankfully though other folk do or scripts like these might cost a fortune. -- Fred Gandt (talk|contribs) 14:11, 24 July 2011 (PDT)

The script I sell at Dvandva and on Markeplace is not the same script... this script long ago fixed the issue of persistence and also works for sculpties and at the same time protects the sculpts uuid thru encryption --Rian Jayaram 20:58, 26 June 2012 (PDT)

Caveat needed?

The Advanced version could maybe use the caveat that llGetPrimitiveParams([PRIM_TEXTURE, ALL_SIDES]) is going to return NULL_KEY if the object isn't full perms, thus removing the texture completely (I found this our the hard way yesterday). My quick work-round was to hard-code the uuids, but otherwise I guess you have to scale, rotate and offset the textures separately. Innula Zenovka 04:03, 24 July 2011 (PDT)

Good point. I'll have a look at an addition if/when I get the time. More when than if but I'd be glad if someone beat me to it. -- Fred Gandt (talk|contribs) 14:11, 24 July 2011 (PDT)