That Rocket Launcher in the Library - Where Does It Go?

[Prokofy Neva]

So I don't know if you've ever experimented with this item called "Firework launcher (drag to ground)"

It was actually made by our illustrious leader, Philip Linden. The notecard on it says this:

Rocket Launcher
---------------

Click on the base to load and fire a new rocket. 

For extra dangerous fun, aim the rocket by rotating it before firing. 
 

It's a fascinating device, as instead of using particles, or the old "light on object," it has orange and red colored prims that appear and disappear as the "light".

So with the scripts and the little rocket inside this thing, you can launch a little rocket.

The reason I even bothered with this item was I was trying to find something free or cheap that would enable me to have something I was making explode and fire up and smoke.

Except for my "Soviet Matches" product, I'm not one to enjoy weapons and things that explode, it's not my thing. So I don't know anything about how they work.

My first concern was that if I made a thing like this, it would lead to all kinds of build up up shot rockets all over the place from people visiting the site where I was putting this. But it seemed as if one shot, the rocket disappeared, like a temp-on-rez prim, although it didn't seem to be temp-on-rez; it seemed pretty solid and seemed to "stay there". Maybe it was lost in the bushes somewhere, so I went to a Linden sandbox that was completely empty and shot the rocket and sure enough, it completely disappeared.

So while I was struggling with the different elements to this thing, different scripts, sound files, prims, and sure enough, I mixed them up, and put the script that is supposed to go only in the rocket inside the launcher, the radiation device I was making out of an expensive rare gatcha. Oops, that made it launch -- and disappear.

So the question is:

Where did it go?

How does a prim get "unmade"? 

What is the principle at work here?

Go and look at the script inside the rocket called "Rocket Booster" if you want, it has things like "status physics TRUE" and "status physics FALSE"  which may be involved in its disappearance.

What I also liked about this device is that it runs through 5 sound files with orders for "prelaunch sound" right in that script, not another sound script (I find sound scripts are always so bulky, they buffer, etc., and this one worked great, so I am going to try other sounds on it -- but then I'm stuck with the thing exploding at the end).

 

[Fionalein]

There are some scripts that can make items go temp after a time. But all my phyiscal weapons have temporary prim bullets...

... I'll inspect it and report back (that is open it and rez it's contents in a save "no script" sandbox)

UPDATE: The script contains a colission trigger and at the end of the collision sequence is the command lldie() which makes it go poof,... 

If you plan on using your own adaptation you can try if making the projectile a temp object (just check checkbox) leaves you enough time to play your sound sequence (would be even saver for the littering aspect that way)

Edited April 29, 2018 by Fionalein

[Prokofy Neva]

Thanks!

 

So lldie() makes things disappear?

Because the pixels are erased? Or what happens?

[Fionalein]

lldie() de-rezzes an object, it "dies" (goes to garbage) the particles it generated fade away and no new ones are generated (because the generating object is now gone).

[Madelaine McMasters]

I got so excited by the thread title I almost wet myself.

As Fionalein explains, llDie() performs exactly the same action that vanishes a "temp" prim one minute after rezzing. The object is removed from the simulator's object and physics queues and the removal from the queue is communicated to all connected viewers, which then remove the object from their local rendering queues. Whether killed by the expiration of the temp timer, or via llDie(), the dead object does not return to your inventory.

And pixels are never really "erased" from your view, at least not in the sense I think you're imagining. Every SL frame is a recreation, from scratch, of your viewer's render list. At the beginning of each new frame, the viewer flushes the entire frame buffer and redraws everything in the rendering queue. When an object dies, it's removed from the queue and will not be redrawn in the next frame. So, in a sense, everything you see is erased every frame. Only things still in the rendering queue will be redrawn.

Also, as Fionalein explained, particles emitted by objects become their own independent temp objects, subject to the properties imparted to them at the moment of emission (velocity, lifetime, etc.) The removal of the emitting object will not affect already emitted particles. They will continue to move, decay, and die on their own, but no new particles will be generated since the emitter is gone.

It makes sense to script a projectile to die upon collision with another object, rather than depending on the temp rez timer. You generally want collisions to somehow alter the projectile, the target, or both.

A belt and suspenders approach to projectile design would often involve both rezzing the projectile as "temp" and using llDie() in a collision event. This prevents littering the landscape with projectiles should the script or simulator physics engine malfunction.

[Ivanova Shostakovich]

2 hours ago, Madelaine McMasters said:

I got so excited by the thread title I almost wet myself.

   I'm so glad you didn't also have a sneeze coming on.

[Prokofy Neva]

On 4/29/2018 at 10:26 AM, Madelaine McMasters said:

I got so excited by the thread title I almost wet myself.

As Fionalein explains, llDie() performs exactly the same action that vanishes a "temp" prim one minute after rezzing. The object is removed from the simulator's object and physics queues and the removal from the queue is communicated to all connected viewers, which then remove the object from their local rendering queues. Whether killed by the expiration of the temp timer, or via llDie(), the dead object does not return to your inventory.

And pixels are never really "erased" from your view, at least not in the sense I think you're imagining. Every SL frame is a recreation, from scratch, of your viewer's render list. At the beginning of each new frame, the viewer flushes the entire frame buffer and redraws everything in the rendering queue. When an object dies, it's removed from the queue and will not be redrawn in the next frame. So, in a sense, everything you see is erased every frame. Only things still in the rendering queue will be redrawn.

Also, as Fionalein explained, particles emitted by objects become their own independent temp objects, subject to the properties imparted to them at the moment of emission (velocity, lifetime, etc.) The removal of the emitting object will not affect already emitted particles. They will continue to move, decay, and die on their own, but no new particles will be generated since the emitter is gone.

It makes sense to script a projectile to die upon collision with another object, rather than depending on the temp rez timer. You generally want collisions to somehow alter the projectile, the target, or both.

A belt and suspenders approach to projectile design would often involve both rezzing the projectile as "temp" and using llDie() in a collision event. This prevents littering the landscape with projectiles should the script or simulator physics engine malfunction.

Ok, I didn't know that about "die". I'm glad "die" isn't used very often.

So long story short, my single-copy rare gatcha has "died" now. What can you do...

And more to the point, I don't have to worry about sim pile-up.

What I'm now trying to do is to change the textures so there are different shapes and colours, and I don't understand why it "doesn't look like the original," i.e. last as long, even though I renamed them exactly, to avoid trying to put new names in the script.