Particle trail

I'm trying to create a particle trail from an attachment, that activates on flight. However, the only ways I can seem to find to do it use the timer, which I'm told can lag a place pretty bad. Anyone have any suggestions to make this work?

do a drop particle and turn it on when they are moving and flying, off otherwise

essentially use two state... one for flying one for not, and moving start/end in the flying state... check flying in moving start in the off state, and check it again in the move end in the flying state

It will work the same way an AO works. You use llGetAgentInfo inside a timer to find out what the av is doing. Turn the particles on in an if test for:

if (llGetAgentInfo(llDetectedKey(i)) & AGENT_FLYING)

if the test fails, then turn the particles off.

http://lslwiki.net/lslwiki/wakka.php?wakka=llGetAgentInfo

testing from moving/not moving will cut down on some of the polling

i'm wondering, would using controls be laggier/better than a timer? when one of the controls is pressed it could do the same thing as when the timer goes off, but doesn't do anything really when there's no controls used.....

edit: just thought about that some more after i said that. i guess the timer is needed to continue checking the status, since with a control, it would only check the status when the control is pressed, so with nothing to check the status, whatever animations/particles were started would continue when not wanted/needed

actually no, controls get events when the button is pressed, held, and released, so it COULD be effective (use edge to check status much like you would moving_start/end). again, no timer needed, and the additional free benefit of working in no script areas (although you'll have to be careful of what you check, since turning of fly can be done from the menu bar)

I don't know that controls will help, because controls can be used when flying or not flying and collisions can also cause your avatar to move. You probably won't want to take the controls 100% of the time as well (when the avatar is walking and sitting?), so I think the timer is the nicer of the options in this case. I've also been told on many occasions that 'moving_start' and 'moving_end' have been very unreliable for a long time, though I haven't tested them recently myself.

Timers themselves don't cause much lag. It's what is done with them that can make a difference. Don't make the timer extremely small in period (i.e. every 0.5-1.0 seconds is probably sufficient for this application; no need for a 0.05 second timer), and do as little as possible in the timer. For example, keep a flag around that tells you whether the particles were already on or not, and if the state of the avatar hasn't changed in a way that should trigger a CHANGE in the particles, return without making any llParticleSystem() calls.

you don't have to take over the control, just capture them, and it'd only be a place to test from, so that you aren't testing constantly

I use controls *and* a slow timer in the Flight Feather, because controls won't detect when you click the "fly"/"stop flying" button.

yeah that's kinda why I favor the moving events myself

But what would cause more event triggers? someone who is walking on the ground or a timer, would be a balance thing I'd assume..... something to keep in mind if you use the moving events

well I wouldn't use moving... just the start and end ones... but they have their own host of issues with not triggering in certain situations last I checked so... I guess it falls down to how often you check those timers, or haw active you av is in start stop situations...

of course most people already have one fast timer going, and it's a small thing to add a line to an an AO that spits out the current av status on on a large negative channel for all devises to catch....

Yep, was just a warning to think about which way would be best to implement what they want. To look at the benefits vs costs of each way to do it. All a part of the fun of scripting

That's an interesting possibility. And if it only chats when the status CHANGES....

Even if you use moving start and end, you still need a timer, because you don't always stop or start moving when you stop or start flying.

Flight feather is using controls anyway, so it just runs a slow timer checking for a status change when it's not active. When it is active it's running a faster timer anyway to maintain the feedback.

doesn't moving start trigger for falling?

If you were already moving?

well no... but it'd catch it at moving stop... because IIRC the viewer (or server I'm not sure) stops you if you land, not 100% sure about soft landings though.

technically you'd still be in the air =X

Two years ago I investigating making a friendlier AO. moving_start, moving_end and the changed events just really are not very reliable, as opposed to just checking in a timer event.

That's what I found out, too. They can augment a slow timer but you can't get away without any timer at all.

If the moving events DID work reliably, you could use them to start and stop a timer, so that you aren't making use of one ALL the time.

If they worked reliably and triggered when you changed state, you wouldn't need a timer at all. The unreliability is that you don't necessarily stop or start moving when you stop and start flying, so you don't know when to stop or start the timer.