Jump to content

Temporary Projectile refuses to die or LLDie after region change


You are about to reply to a thread that has been inactive for 2706 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I'm not certain if this belongs more in the Technology forums than here, but anyway...

Can anyone shed any light on this, and/or offer a solution?

Executive Summary

Physical projectile, set as Temporary and with failsafe llDie() timer, does not die or get garbage collected if it gets too far away into a neighbouring region. The script works perfectly within the region, but seems to just stall outside, or still runs but the projectile refuses to die.


Long-winded description

I have a physical projectile spear, quite simply scripted for some actions on collision, and it runs a failsafe timer to llDie. It is also set manually (before putting in the gun) as Temporary. The spear is fired from a speargun and returns after collision or first timeout on the end of a ribbon particle rope.

Tested within a region, it all works perfectly. It's really good!

However, if it crosses a region boundary and doesn't get a collision quite quickly, it nearly always 'hangs' some distance away (as in a sim or more!) and often goes right through hills which it shouldn't be able to do. It does not llDie or get garbage collected even after five minutes. I've traced every step of the script and frankly it's simple enough. There's nothing wrong with the script. It simply seems to either completely stop running mid-flow, or the spear just refuses to die.

Note: A key point is that the spear doesn't even get garbage collected. It is temporary. Even if the script were faulty, that should still happen if something external wasn't 'wrong' to prevent things happening.

It isn't about going into a script-disabled parcel. If it does, it still doesn't get garbaged when it should. I checked.

I've followed the particle rope and found the spear over two sims away, spinning in the air. If I right click on the spear, it instantly vanishes.

I put llInstantMessage() calls all over the script to trace execution. I get the startup message, meaning the timer is set and everything is running. Within the region, everything happens correctly. On leaving the region and not hitting something quickly, I either get nothing at all (meaning the timer event didn't get called) or, occasionally, I'll get the manual 'kill' state being entered, but the thing still doesn't die. This is the manual kill state that gets entered from several places, including the timer.

state Dead {
	state_entry() {
		llInstantMessage(llGetOwner(),"State Dead");

Obviously the llRegionSay in there is pointless out of region. It's  there for when things work, to signal back to the speargun for reloading.

When I get the "State Dead" message out of region, the ribbon particles and spear still remain (and the spear doesn't get garbage collected) and I have to go searching for the spear to right-click it to kill it.

Note that if I hit my target (or any llCollision event) and it's just over the boundary, that's not a problem. It works! It also works if I throw low and bounce it along the ground to stop its flight. That's not a collision event, and the failsafe timer kicks in as expected.

It's not just a local viewer-side effect. I logged my alt on and could see the particales and stuck spear from there too.

All I can think of to cure this is to detect new region and instatly die, but that means I can't use the weapon across a boundary, and it does work fine across the boundary if it hits something before it gets too far away, or whatever it is that causes it to stop working right..

Any ideas?



Link to comment
Share on other sites

When any object crosses a region boundary, it has to pass from the control of one region's servers to the other.  That's not easy if the object is moving fast, which is partly why vehicles often have wonky behavior.  I imagine it's easy for the servers to lose track of a bullet or a lance.

Depending on your design, you might be able to use llSetStatus with its STATUS_SANDBOX parameter.  That will not let your rezzed object travel more than 10m and kills it a a region boundary.

Link to comment
Share on other sites

Hmm... servers losing track of it seems exactly what is happening. It isn't flying all that fast (25-30m/s at rez) but obviously that's fast enough.

STATUS_SANDBOX looks quite useful for testing things; I hadn't noticed that one before, thanks! It won't do here though as I want to have a useful range of at least 60m. My system works nicely and reliably from one side of a sim to the other if I don't restrict it to keep it 'realistic'.

If I started the parrticles from the gun instead of the spear, I could at least kill them after a timeout and not be left with a rope disappearing into the distance. I tried it that way though and it often lags the spear, ruining the effect of it being tethered.

Some thought and experimentation is required... (looks around for the bottle of Kraken rum to lubricate the cogs...)

Link to comment
Share on other sites

Spotted the reason... well, the cause of the servers losing the plot.

After speed being mentioned above, I realised that I was accelerating it at one point, instead of decelerating. I got my vectors reversed when I copy/pasted during a small edit. That made it go a bit too quick and clearly the servers didn't like it if the missile crossed a region at that speed.

I never spotted it because the missile was barely visible at the end of its range by the time that happened, and it only happened if there was no specific target set and no collision for a while. Plus I was testing just at the right (or wrong) distance from the boundary for the acceleration to happen just before the cross.

After correcting that simple mistake, the missile doesn't go so far or fast and that itself has cured the issue, even when it crosses into the next region.

As usual, the problem was really caused at layer eight.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2706 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now

  • Create New...