'Bullet' problem

So im still pretty new to LSL i do have a decent amount of coding experience but not a whole lot in SL. Anywho im making an arcing bullet for a project im working on and so far ive got a decent arc but there is a problem. I have (or think i have) the bullet set to explode and delete itself when it collides with anything. I can fire it directly up in the air and watch it drop but just about any other angle it will die with no explosion in mid-air.

Im omitting the particle effect code but heres the main part, some of the processes seem redundant but thats only because im trying to get it working before i clean it all up

i just need to know why the projectiles are somtimes disapearing into thin air, and if there is a better method to force the gravity to make the arc. Thanks

die()
{
    llDie();
}
particles()
{
    llSetStatus(STATUS_PHYSICS, FALSE);
    llSetStatus(STATUS_PHANTOM, TRUE);
    updateParticles();
    llParticleSystem(sys);
    llSleep(1.0);
}    
default
{
    state_entry() 
    {
    llSetStatus(STATUS_PHYSICS, TRUE);
    }
    
    timer()
    {
        if(col == FALSE)
        {
        llApplyImpulse(llGetMass()*<0,0,-3.0>,FALSE);
        }
        else
        {
            particles();
            die();
        }
    }
    
    on_rez(integer start_param)
    {
        llSetTimerEvent(0.1);
    }
    
    land_collision_start(vector pos)
    {
        particles();
        die();
    }
    
    collision_start(integer num_detected)
    {
        particles();
        die();        
    }
}

Are you sure it dies? It might just be being eaten by the LOD monster.

Try making your bullet's material "light". That makes it less subject to being culled over a distance.

wow thats all it needed, thanks jillian

Also, you might want to look into llSetBuoyancy and llSetForce. Those are MUCH smoother than repeated impulses. In addition, your "col" check is unnecessary. One script is not multi-threaded--It will progress through each state and function in order, and won't jump off in the middle.

Yes.. after doing some testing, I have found that when using objects of the default "Wood" material they will disappear at certain ranges based on their size. It seems to be fairly consistent, and if I remember correctly it was something like:
1m x 1m x 1m box disappears at 64m.. so 1:64.

The distance that is disappears at grows proportionately to the size of the prim. So a 2m x 2m x 2m box would disappear at 128m. This is provided it is as separate prim and not linked with a larger object. I didn't do any testing with linked objects but I assume it would base itself from the total or mean size of the object.

Since particles are driven by the client, it needs to be able to see the emitter to have the particles emitting, and also if you are using a target for the particles to go to, the target also needs to be visible.. or at least potentially visible. If it is hidden by a wall but still within visible range, it will still find it and send the particles there. So you have to make sure both prims, the emitter and the target are not disappearing for it to work. If the emitter is visible but the target is out of range, the particles will just default to going to the emitter as if the target prim does not exist.

Spot on, Gaz. The client renders object based on the bounding-box size.

For example, my clouds are particle emitters, so they don't need a visible prim, but I had to make their transparent cube prim 10x10x10 or else the cloud particles wouldn't show up at all unless the cloud cover was a few meters from the ground.