Question about llDie()...

Hi, I hope this is not too noob a question, but I am working on a set of objects, where one after a time needs to drop down from the other (they are not linked at the moment) and then die. But prior to dropping down, it will rezz a new version of itself. So I am basically using the dropping object to rezz a copy of itself (with the same script only with its timer just started) and then llSetStatus to switch this dropping object to physical so that it drops down and hits the ground. Its newer copy remains behind in the original position where in time it too will repeat this process again. My question is I am hoping to use llDie() to emulate temp on rezz, so that the dropping object spends some time on the ground before it deletes itself. I am unsure if one can have a timed llDie() or not. Is there a better way to do this?

llDie will occur immediately it is evoked, however, using llSetPrimitiveParams (see: PRIM_TEMP_ON_REZ) you can set an object to become temp on rez on the fly.

Cool I missed that in the wiki, as I search under 'TempOnRezz' for some tupid reason Thanks a lot for the correction, Pale!

Setting temp on rez is one thing, but you would be advised to set a timer for the die concerned to maintain your own control.

For example...

default
{
   on_rez(integer p)
   {
      llSetTimerEvent(30.0);
   }

   timer()
   {
      llDie();
   }
}

I put llSay("kthxbye";llSleep(10); infront of a llDie(); as saveguard for content loss.

Thanks Ordinal and Ollj, I agree with tighter controls when using llDie() and I have made a copy (with your perm of course) of your suggestions in my own lsl reference library for the future

In the end for this project PRIM_TEMP_ON_REZ worked a charm, with the trash sweep giving the object just enough time to do its thing before wiping it

Now I am battling with the orientation of the newly rezzed replacement. But let me fight that a little before I pop back for more advice

Mmm, embarrassing as it may be I coding everything the first time only to see my one and only version disappear when set to temp as I completely forgot to take a copy into inv first

Yep, easy done. We have all done it!

In an attempt to overcome that, I use a system of SAFE and LIVE, as illustrated in the snipet below. This can get as complex as you need it to, but I have kept the example below deliberately straightforward for illustration purposes.

//"LiveStatus = TRUE" will set the object to Physical, Temporary and Alpha. Otherwise FALSE assumes that the object is still being tested
integer LiveStatus = FALSE;

// maximum life of object
float DieTime = 15.00
	
// product name
string ProductName = "Debbie's R&D Test Explosion";


MakeLive()
{
	LiveStatus = TRUE;
	// set TEMP, Alpha, phantom and physical
	llSetPrimitiveParams([
		PRIM_TEMP_ON_REZ, TRUE,
		PRIM_COLOR, ALL_SIDES, <1.0, 1.0, 1.0>, 0.0,
		PRIM_PHANTOM, TRUE,
		PRIM_PHYSICS, TRUE
		]);
	llSetObjectName(ProductName + " ~ LIVE");
}

MakeSafe()
{
	LiveStatus = FALSE;
	// unset TEMP, Alpha, phantom and physical
	llSetPrimitiveParams([
		PRIM_TEMP_ON_REZ, FALSE,
		PRIM_COLOR, ALL_SIDES, <1.0, 1.0, 1.0>, 1.0,
		PRIM_PHANTOM, FALSE,
		PRIM_PHYSICS, FALSE
		]);
	llSetObjectName(ProductName + " ~ SAFE");
}


ActivateExplosion()
{
	timer(0.25);
	// do your stuff starting here
}

default
{
	on_rez(integer StartParameter)
	{
		if ( StartParameter != 0 )
		{
			// any non-zero parameter received on rez will activate the object
			// reset the internal timer
			llResetTime();

			if (!LiveStatus)
			{
				// the attributes have not been set manually, and so have be done now
				MakeLive();
			}
			
			ActivateExplosion();
		}
	}
	
	state_entry()
	{
		MakeSafe();
		if (LiveStatus)
		{
			llOwnerSay("!! MAKING LIVE !! : Ensure to 'Take Copy' *immediately* the Compile has completed (but not before)");
			MakeLive();
		}
	}
	
	timer()
	{
		// if timer exceeds DieTime and LiveStatus is TRUE
		if ( llGetTime() > DieTime ) && (LiveStatus))
		{
			llDie();
		}
	}	

// default end
}

So, effectively, while 'LiveStatus = FALSE', the object can not die or be TEMP'd away.

To set to LIVE, EITHER:

1) Set "LiveStaus = TRUE" and immediately the compile completes, "Take Copy". The way I do it is I "Save" the script and then immediately right-click the object and navigate the pie-menu to "Take Copy". I hover my mouse cursor over "Take Copy" and immediately the compile is complete, I click it. It gets copied to my Inv suffixed " ~ LIVE"

OR

2) On rez, pass a non-zero value from llRezObject. As "LiveStaus" would still have been FALSE, this forces function MakeLive() to be activated. The downside of this is that there is a slight delay while function MakeLive() is being performed. (0.2 secs if using llSetPrimitiveParms)

Anyway, hope the above conveys the concept....

EDIT:
oh! Before setting "LiveStatus = TRUE" and compiling, always take a copy of the object. This will put a copy in your Inv suffixed " ~ SAFE". This is important. Now, should anything go wrong, you have a deactivated SAFE version of the object with which you can continue to work with.

The suffixes " ~ SAFE" and " ~LIVE" easily identify and differentiate between the two types when you look at them in your Inv.

Hey, I am trying to set a script I wrote yesterday, that worked perfectly throughout to 'run' but each time I do it the script resets itself back to 'not running' - arghhhh! Any ideas? Or is it just SL today?

Hi Debbie, forgive my rudeness for not thanking you for your excellent tip! I do appreciate this very much.

This usually means it has a compile error. Try changing something (just add a comment) are Save. If there is a compile error it will tell you, otherwise you should be good to go.

Thanks Pale, amazing, no errors anywhere. I just added a space as you suggested, deleted it and saved, this time everything works. Cept rotation of the rezzed replacement, but Im fighting that one

Me again

Before I struggle with getting the Rotation correct, I am wondering if there is a way to rezz an exact copy of an object. Currently I copy the object and place the copy into it including the script that controls its behaviour. However after the first object rezzes what should be a copy, I find that the copy gets to the end of its cycle and then issues a script error as it cannot find an 'object' in its Contents, and the cycle ends there. Am I taking a copy wrong or is there a way to turn this self rezzing model into a perpetual model where A rezzes A1 rezzes A2 and so on?
In SL terms my object is born at rezz as part of a collection of prims. This specific object goes through color changes and shapes and so on, until it gets to a certain stage in its life after which it dies. Before it dies (PRIM_TEMP_ON_REZ) it rezzes a copy of itself in that exact position it was before going temp and physical. Physics allows it to fall away from the prim collection as if it separates and in its place is a nice new healthy version of itself. That cycle just keeps repeating itself all the time over days (I speed it up for testing though ). So you can see why this rezzing an exact copy of itself all the time is kinda important to me

POSSIBLE ANSWER: My rezzing code read 'llRezAtRoot("object", pos + <0.0,0.0,0.0>, <0.0,0.0,0.0>, <90.0,0.0,0.0,1.0>, 0);'
Am I right that the last number after the rotation data should be an indicator of the number of times the prim will rerezz itself?

Place the object into 'Contents'
Right-click it and ensure that 'Next Owner' can 'Copy.

From wiki:

"If the inventory object that is to be rezzed has copy permission, a copy of the object will be rezzed. However, if it doesn't have copy permission, the original will be rezzed and removed from the object inventory. Any subsequent calls to this function with the same inventory will then fail because the inventory object is gone. It's important to set copy permissions for the next owner if an object is to be sold (or given away) and is rezzed by llRezObject (unless only a single copy is rezzed)."

http://rpgstats.com/wiki/index.php?title=LlRezObject

I think that is what you seem to be describing anyway

Debby, you had it right, somehow the original all perm setting I did when starting had possibly due to the same code error problem earlier today, not stuck, so the object was no-perm

/me bows head in shame - locking himself into room with no access to forum until product is tested properly!

Ok, so this script of mine runs down to a point where the object no longer replicates. What I need is a method to have the object continue to replicate itself until the owner either takes it into inventory or never I know it sounds like grey goo here, but honestly it is not. Basically I am trying the reverse of the normal object rezzing products out there, by having the object rezz replacements of itself continuously. My script at the moment does not re-rezz the object, but rezzes a copy (ful perms) from out of its Contents tab. Sooner or later as the object rezzes a replacement from within itself and then deletes, the script runs down to a version or copy that no longer holds a copy of itself internally. Thats when things currently stop for me. I need for this not to happen and all I can think is two options: 1 my premise is wrong and I restart the process by for example making a invisible version of the object that never deletes and that holds the copies within itself. This is commonly the method I see a lot and similar to vendors rezzing products. or 2. I learn over the way I thought objects rezz themselves, and try and understand self replication with deletion better. I am open to guidence here big please anyone