Link message queue?

Ive been playing around with gun scripts, and I have got this working well, but I'm running into a problem. What I do is send a link message to the link set, and another prim in the set picks it up and rezzes a little ball (bullet). This works perfectly fine, until I try to turn the rezzing off. Since rezobject has a bit of delay/lag for some reason the link messages queue up and the gun keeps firing after I have cut off the link messages. I'm wondering if there is any way to kill this queue of link messages flooding into my listening object? I tried sending a cutoff message to the firing prim, but it just queues up and gets there at the end of the queue and doesn't accomplish anything. If anyone can shed some light on this, I would be much appreciative.

P.S. I checked the wiki, could not find anything related to link message queues

What about sending a single link message in to your BulletRezzingThingy to turn a timer on, and letting the timer rez the bullets until you send a single stop message?

Hmm...I just realized I'm uncertain as to how timers interact with built-in delays, like the one-second throttle in llRezObject(). Do timers account for throttled time when deciding whether to fire, or ignore it?

*tries to decide between trip to wiki and trip to sandbox*
*heads for bed instead*

-- danny d.

Just call llResetScript() after your llRezObject() calls. That way they'll rez an object, then immediately clear their own linkmessage queue. I forget who passed me that little nugget of wisdom.

just curious... are you using "touch_start()" or just "touch()"?

The function "touch_start()" may be firing many times and might not be what you want. The other function "touch()" only goes one time.

Just a thought since there was no script to view.

well that worked! thanks a lot

llResetScript is one way, but you can also just switch states if you don't want to lose variable information. According to Cory, switching states clears all pending events, and since he fixed this (it didn't used to work even though it was supposed to I reported the bug a long time ago), it appears to be so. I stumbled on the reset angle but it was frustrating since I track ammo, and after the fix I never had the problem again. The same thing used to happen with listens, touches, all kinds of stuff, but now (actually for some time) state exit does what it is supposed to do.

Keep in mind you actually need to switch states.

For added fun, you can try using llResetOtherScript() from the controlling script to immediately stop any firing. I imagine llResetOtherScript() is not really intended to be used as a normal part of scripting design, but it really works handily to interrupt a script immediately

Really? I would have thought it would be the other way around...

Actually, last I checked, it was the other way around. No offense to the original poster.

Use states. This will enable the gun to ignore all incoming link_messages while it is rezzing the projectile.

Example:

integer force = 0;

default
{
  link_message(integer sender, integer num, string str, key id)
  {
    if(str == "fire")
    {
      force = num;
      state fire;
    }
  }
}

state fire {
  state_entry()
  {
    llRezObject("bullet", <1,0,0>, 30.0, ZERO_ROTATION, force);
    state default;
  }
}

Since the fire state has no link_message event, all link messages recieved during the time the bullet is rezzed will be ignored.

edit: the force variable is a habit of mine. A handy way to relay variable push force settings to the projectile.