An event for avitar flight

If it wouldn't be too much trouble. Could we have an event that is triggered when an avatar takes flight and one when an avatar gets out of flying mode? This is simply to make it easier for scripting attachments that need to be turned on or off when an avatar is flying, like wings, extra speed, etc.

Ground collision isn't a good way to do this because prims don't trigger a ground collision when the avatar lands on them.

This would replace the usage of timers to check whether or not a person is flying via llGetAgentInfo. Timers use unnecessary resources (cause lag and crashes) and I would like to not have to use one for this.

Seems like such a common "event" such as flying should have event triggers associated with it.

Thanks
P

I'd like to see just a general LSL event version of llGetAgentInfo(). It'd probably have to use the "edges" and "levels" system in controls, so you can see the current agent info and what changed to cause the event.

Timer notwithstanding, the script will still use up sim time as long as it's active. Making flight state detection an event won't change the lag situation.

True, but if it's not executing code it takes up less script time.

The question then is will the savings be worth it? When the avatar is in fly state the script is obviously active and busy. When the avatar is on the ground hardly any instruction gets executed so it's taking up minimal time. For physics scripting (single script) there's no point in doing more than about 18 polls per second since the sim won't execute physical instructions any faster than that. For reference, llGetAgentInfo() uses up about 2.6ms, a flight state IF takes up 0.8ms.

IMO the savings will probably only matter if there are a huge number of avatars on the map with flight-related scripts because the time savings is per script.

Can someone figure how much savings will be realized given 18 polls per second and the above execution times?

Then there is also the possiblity that LL has some other reason for making flight detection state-based.

actually the script is ALWAYS active because the timer has to check every so often (my wings are set to 2 seconds) whether or not the agent is flying. If they are flying it has to check if they are still flying and if they are on the ground it has to check if they are still on the ground. The timer is always active. With an event, you would have MUCH less activity.



The reason is that they didn't think about it. Another reason is that they don't spend any time making SLS as event driven and object oriented as it should be. It's like coding with abacus!

On the first matter I still would like to see hard numbers showing how much savings can be realized. A few milliseconds savings per 2 seconds for 30 devices (such savings are per similar device per sim) may not be worth the trouble.

On the second matter I strongly feel it's not that they didn't think about it, but it either was not worth the fuss because of too little gain, or that it makes everything else simpler.

You're obviously a programmer of some experience, so perhaps you can find a way to quantify the difference, time-wise, between event and state detection that you're looking for.

It's better to use llTakeControls to detect flight rather than a timer, perhaps with llMinEventDelay(1.0) to make it less crazy.

But ehm yeah, I suggested this in the agent_info() event topic.

Been though this several ways in Cyberflight. You really need to have a periodic check *and* monitor controls, because you can change state between flying and not flying without touching any of the controls.

But the sim lag from conservative flight scripts (slow poll every second or so when not flying) really isn't ever going to be significant. Even thugh I would personally benefit from being abe to have a "CHANGED_FLYING" event I'd rather LL spent their time fixing other problems.

That was exactly what I thought on seeing the title of this thread. It always seems terribly wasteful to have a timer checking whether someone is in mouselook or whatever - though apparently it's not actually too bad - and, more importantly, it would mean the checking wouldn't have to be incorporated with any *other* timer-based functions you wanted to put in.

Multiply that by the number of scripts doing it though? Offline status checkers, typing effects (e.g keyboards appearing while typing), animation over-riders and self deploying wings all using timers, it gets pretty hefty on the script time, for things that rarely trigger (compartively).

The issue isn't timer events. The question is whether or not creating a flight status event realize significant savings.

A flight status event will only reduce timer event load of those scripts that are checking for flight.

Such an event will not realize savings from offline status checkers, or typing effects.

IMO realizing savings from only 30-60 scripts per sim isn't worth it.

Furthermore, having events for all the different statuses like flying, typing, etc will make scripting even more difficult because you'll have many more events queuing up for control. If it gets clogged, events will be missed.

I've gotten a script to a point where the events were getting missed.

Better to keep things the way they are.

That's why my suggestion is avatar_info() event opposed to changed_flying() event, which is far too restricted. avatar_info() returns a lot of information using the same amount of data (an integer if you limit to only one avatar's info at a time). But no-one seems to be posting in my thread despite it being the more flexible solution for the same problem with no extra cost since the info is already available =S

And it would be fairly significant, say I'm online for an hour with an animation over-rider, a typing status effect and a flying status effect. Each one is using a 1.0 second timer. That's 10,800 checks while I'm online, regardless of what I'm doing. I could be standing around doing nothing for the whole time. If I used an event instead, then that would be 0 checks. If I take flight, or walk about a bit, then it's still only a handful of checks.

Really the issue is; if something can be optimised like that, should it be? My answer is yes, anything that can be optimised, should be. Whether it be scripting calls, or networking code, it should all be gone over with a fine-toothed comb because lag isn't getting much better lately.

An event-based Agent info will generate an event everytime any of its statuses changes. The issue I see right now is if we are checking only for typing then we will still be getting events from at the very least fly, sit, stand, fall. All this can mess up the flow of a script.

I can see promise in such an event if the item above can be addressed.

Well, only scripts in attachments could be expected to be able to recieve this event[1], and even the most grotesquely overscripted avatar is likely to have more then two or three scripts to detect that its flying... they don't run timers in every script in a 500 prim wing, they use link messages.

A more general avatar-changed-state event has more justification, but not because of lag but because AOs could really benefit from better real-time feedback on state changes. The best thing to do would be add another flag to the change event CHANGED_AVATAR_STATE.

[1] For offline status checkers to get this LL would have to add another central registry and add more cross-sim traffic for every state change... it'd never happen.

How do you figure? Events aren't asynchronous.

integer old_info;

change(integer what)
{
  if(what & CHANGED_AGENT_INFO)
  {
    integer info = llGetAgentInfo();
    if(info & AGENT_TYPING != old_info & AGENT_TYPING)
    {
      if(info & AGENT_TYPING) llSetAlpha(1.0, ALL_SIDES);
      else llSetAlpha(0.0, ALL_SIDES);
    }
    old_info = info;
  }
}

The event will still be generated even if nothing we are concerning ourselves with will happen.

Yeah, and events are still better anyway, because it's better to be receiving events for things you're not looking for, than receiving timer events all the time when nothing's changed at all anyway.
Even if I'm running and jumping all the time instead of flying, that's only a few events compared with the thousands called by a timer.

Adding it to the changed() event is a nice idea, I'd personally still like to see it separated since it's not the object that has changed, but really it's no different, since the same checks are required, only a different event is triggered.

We really need more stuff attached to changed. ... like detecting push?

You'd save one call to llGetAgentInfo(), but LL would have to implement and document a new event and they seem reluctant to do that.

Hmm, but should our suggestions be tailored toward what LL seems reluctant to do? Heh, they need to get the thumbs out and get some better organisation and planning going, then these details won't be much of a problem.

But that's a larger issue than this topic, I'm happy with either solution

Oh my I sound so angry! or atlease irritable. Sorry, I don't mean to sound unappreciative of everything LL has done for us with SL. I just get irritable from time to time when I think about the fact that the entire scripting language will not scale well and needs to be replaced with an object oriented event driven language. This should lift many developmental limitations and the sooner they do this the better it will be as the community gets larger everyday. When I'm scripting I get the feeling that we are adding onto a house with a weak foundation, and I get scared that I'm really just waisting my time.

P

Yes. If they're reluctant to do something it's probably because it's harder, which means they're less likely to do it soon, and less likely to do it right.