Talk:AGENT FLYING

Difference between AGENT_FLYING and AGENT_IN_AIR...?

Currently we seem to have two very closely aligned flags — or, at least, that's what the page implies.

AGENT_FLYING is set when the avatar is flying (one assumes that this happens under the control of the user) or hovering, i.e. not moving and staying statically on the same spot (whatever the animation might show — most set a certain degree of buoyancy for the sake of visual sugar candy, but from the perspective of the simulator, it's not moving).

AGENT_IN_AIR is set when the avatar is flying (same assumption as above), jumping (presumably as a result of the user having pressed the key for a jump) or falling (very likely not because the user deliberately made the avatar drop to the ground, but because the avatar was set far above ground — due to a teleport, for example — and was not in 'fly mode', so gravity catches up and makes the avatar fall down).

So, from the above, one might deduce...

• Both are set when the avatar is 'flying', because the user is pressing the appropriate keys (or whatever input device they use) to make it fly;
• Only AGENT FLYING is set when the avatar is in 'fly mode' but not actually moving around, remaining at a static point;
• AGENT_IN_AIR is additionally set when the avatar is jumping (a deliberate action) or, having been caught far above the ground without being in 'fly mode', being pulled by gravity towards the ground.

This, for me, is utterly confusing, but perhaps my problem is just because I cannot warp my mind in order to fully process what the flags really mean.

For instance, it would make sense that AGENT_FLYING simply meant that the avatar is in 'fly mode'. Moving around or staying at the same spot would be irrelevant — what matters is that the user placed the avatar in 'fly mode': essentially, suspending gravity under the control of the user.

It would also make sense that, in all circumstances when the avatar is not physically touching the ground, but 'fly mode' is not set, then the flag AGENT_IN_AIR will be set. This would simply mean that the avatar is being subjected to gravity (because 'fly mode' is off). However, for consistency's sake, this would also be the case if the avatar is being transported on a flying vehicle of some sort (at least from the moment it's left the ground), even though it's technically the vehicle's frame of reference that is being subjected to gravity — the avatar just happens to be in the same frame of reference.

However, this flag would probably not be set if the avatar is sitting on a non-physical cube which is being moved away from the ground. Non-physical objects are not affected by gravity, so the avatar sitting on it won't be, either. They're 'not on the ground' but technically not 'in the air', so to speak. In the case that a scripter suspects the avatar is not on the ground (i.e. too far above whatever the ground level is at the position being checked), then they can check for these two flags — if none is set, then the avatar presumably is sitting (or walking) on top of a non-physical object "up in the air".

"Swimming" is a special — but analogous! — situation when all the above applies under the water level, although there are some non-obvious nuances: an avatar which is under the water level, but above the ground level (i.e. the 'ocean floor') does 'not' need to be in 'fly mode' in order to swim. If they're on ground level ('ocean floor'), then all movement is precisely as it happens above water level. If they're not in touch with the ground but remain under water level, then gravity will pull them down to the 'ocean floor', just like it happens above water. The most significative difference is that an avatar falling down into the water will automatically start swimming! (At least that was the case, the last time I checked.) Technically speaking, they should continue their voyage until they exhaust their kinetic energy potential from drop — taking into account that water is far more viscous than air, thus exerting a much stronger reaction force due to extra friction, which, again, will mean exhausting their kinetic energy faster (again, my maths fail me, but this is the reason why a 4-metre-deep swimming pool can be safely used for 10 metre jumps — you won't hit the bottom, no matter how hard you try, unless, of course, you swim to a deeper level) — or, well, hit the 'ocean floor' first.

As said, I haven't tested that very recently — it's possible that things have changed — but none of that actually happens in Second Life: if your avatar drops from the sky and falls below water level, it starts to swim. You can stop swimming in order to sink to the 'ocean floor', though, just like you can stop flying in order to fall to the ground. Flying and swimming are therefore quite similar, as said.

Anyway... my point with all these divagations: this is the assumption I made, based on what is logical or at least reasonable to implement, assuming that you have two flags for different situations. Since this Wiki page lists 'flying' as being common to both flags, either there is some unexplainable redundancy, or one flag is used for detecting 'active fly mode', while the other means 'avatar under control of gravity, not of the fly mode'. This would make some sense, even taking into account that the edge cases — such as flying on an airplane, or sitting on a non-physical prim cube moving 'up in the air' but not subject to gravity — are not being considered in the descriptions of these two flags.

The main reason I'm asking is just because I need to figure out some of those edge cases — namely, when the avatar might be on the ground, up in the air, or under water, but not moving at all, just remaining rooted in the same spot. I was tempted to do it the easy way, which would be just to figure out what flags have been set in this case — rather than having to do some math during every timer event call, just to see if there was some movement (i.e. comparing the current position with what it was on the previous cycle).

Also note that I'm deliberately ignoring the possibility of checking what animation is being run, and checking for that instead. There are two good reasons for that: first, there are quite some more animation states than there are flags. And secondly, flags are integers that can straightforwardly be checked or compared without requiring many CPU cycles. By contrast, listing all possible animations to check which ones are active, may allow for far more types of checking, without incurring in the penalty cause by comparing (many) strings...

In either scenario (assuming there are just two!), it's important to understand which flag(s) will be set, and which have to be sort-of-guessed indirectly, via llGetAnimation (or similar functions).

— Gwyneth Llewelyn (talk) 20:21, 13 October 2023 (PDT)