Previous fix in llSetHoverHeight, turned this into a fly command (!)
complete
Zack Ormidale
The SetHoverHeight function was designed to make the avatar float without flying. The wiki page's own example script is described this way. Now, this function is broken because it is erroneously making the avatar fly, and no longer just standing still in the sky like it was before.
The reason for this error may have been the pressure the team faced with a bug that was occurring for everyone in Second Life. It seems that the fix was made provisionally, because now SetHoverHeight has been replaced by fly. In other words, now SetHoverHeight is no longer floating without flying, it has been changed to literally fly, even activating the AO animation.
Below is the link to the previous error:
_______________________________________________________
One comment:
The consequences of this problem will be discovered over time, but I can already mention some that are affecting me, and are probably affecting other people, who are probably confused, since the problem is difficult to understand (I was just lucky enough to catch AO being activated while my equipment was breaking):
1- Equipment that uses the llSetHoverHeight language is not AO equipment. The llSetHoverHeight script is inside an object attached to the avatar, and has its own rules about activating or not animations (written inside it). Keeping this error would be like forcing a link between the object that has llSetHoverHeight and AO.
Imagine how many people have designed products with their own animations for llSetHoverHeight, and now they will have a conflict with AO. So now they will have to create bizarre rules like: "please, deactivate your AO while using this HOVER equipment".
2- It's not just an animation, because Second Life also computes that your avatar is flying. You can even get banned from a land where flying is prohibited, since you can override the browser before you see that you can't do it. It happened to me, because I was testing the bug, and forgot to disable hover when I went to an unknown land. I got an automatic eject as if I was flying, when in fact I was just suspended in the air and forgot to turn it off. Second Life people are not friendly to clarifications, I would probably turn into a troll or something similar at the first suggestion to solve a problem (laughs).
Log In
Zack Ormidale
It was completed as it was. This was not good news for me, who used this feature for 2 years without any problems. But you have to respect the support. I just wanted to add a comment in case someone comes back to this topic in the future.
I think there was a problem in the interpretation not only of the programming line but also "why would you use a script for this?" llSetHoverHeight() is a way to hold the avatar in the sky, so, just like it happened in these two years that I used the function, it keeps falling: So what should the programmer do? Add a line of what animation he wants! For example, the avatar can be hovering on a cloud. The cloud will have the animation of sitting down. The avatar is then sitting on an artificial cloud . But now he will fight with the AO because he thinks he is flying.
As I said, I used this for two years, I sold programmed products with great respect for those who bought it. I saw other vendors exploiting the function. It is a creative function and not an alternative to "page_UP". But I see that there is nothing more to be done, after all, the status is complete. I have already removed my product from the marketing place, and what will happen to it is up to other users, because I have to respect the completion.
So that's it, for now the logic about the avatar writing remains, and this was considered correct, although I do not agree. Good luck to everyone who opens this topic to try to make decisions in their own project.
This post was marked as
complete
Leviathan Linden
I have a fix for this that will go into some server update, not sure yet which one, but probably late Nov or early Dec. Basically I added a new avatar movement mode when "hovering via scripted attachment". When in this mode the avatar will stay in the Hover animatio and its movement speed will be the same as walking. I also added an AGENT_HOVERING bit to the value of llGetAnimationInfo() just in case anyone wants to query for it.
Jeremy Duport
Leviathan Linden Thanks, this is important nuance for a lot of movement related content :D
Leviathan Linden
For the record:
For the record: llSetHoverHeight() was designed to allow objects to hover, not avatars. However it combines with the attachment feature such that the hover behavior is transferred to the avatar wearing it. Unfortunately it would interact poorly with the avatar's own movement logic causing undesirable animation states and transitions: stuck in falling animation or bouncing between falling and hovering. The recent fixes were to eliminate the animation glitches and inadvertently caused the AGENT_FLYING bit to be set when not actually flying
I can see how to remove the AGENT_FLYING bit when not intentionally flying, and I can easily add an AGENT_HOVERING bit for anyone who might want to query it, but the question remains: What should be the animation state when "hovering but not flying"? I guess it should be "hovering" even when moving, and this would be the same animation played when "flying but at rest".
Zack Ormidale
Leviathan Linden
I saw that it was finalized as it was, so I wanted to leave a comment IN CASE SOMEONE OPENS THIS TOPIC to make decisions in the future about their own collaboration on the case.
I think there was a problem in the interpretation not only of the programming line but "why would you use a script for this?" llSetHoverHeight() is a way to hold the avatar in the sky, so, just like it happened in these two years that I used the function, it keeps falling: So what should the programmer do? Add a line of what animation he wants! For example, the avatar could be hovering on a cloud. The cloud will have the animation of sitting down. The avatar is then sitting on an artificial cloud. But now he will fight with the AO because he thinks he is flying.
As I said, I used this for two years, I sold programmed products with great respect for those who bought it. I saw other vendors exploiting the function. It is a creative function and not an alternative to "page_UP". But I see that there is nothing more to be done, after all, the status is complete. I have already removed my product from the marketing place, and what will happen to it is up to other users, because I have to respect the completion.
Thank you very much. Sorry for the delay, it is difficult to follow the progress. Excuse the vocabulary, I use a translator, it can be a little confusing.
Enviar feedback
Resultados de tradução disponíveis
Leviathan Linden
I was looking into fixing this bug and encountered a complication.
The LSL wiki says the AGENT_FLYING bit of llGetAgentInfo() return value is true when agent is "flying or hovering". There is ambiguity here since the "hovering" animation state is what happens when the agent is flying but at rest.
Meanwhile, the ancient code in the server implementation sets AGENT_FLYING bit if the viewer claims to be flying (and was allowed to fly) OR if the avatar is in a hovering animation state. This has been the case since "forever" (at least since 2007) when the changes to the source code started to be timestamped.
What changed recently was that llSetHoverHeight() used to not successfully put the avatar into a hovering animation state, and instead would put the avatar in the falling state, or sometimes in a neverending cycle of "falling", "hovering", "falling", ."hovering"...
So, I guess the solution is to add a AGENT_HOVERING bit to the llGetAgentInfo() return value and differentiate between the two conditions: "agent is explicitly flying" vs "scripted attachment is hovering agent". However... I wonder how much stuff this would break.
Journey Bunny
Leviathan Linden 🤔 would it make sense as a compromise to set it to falling when llSerHoverHeight, and to also add a new hovering bit? If I'm reading this right, that would give older stuff the expected value while addressing the long-standing bug by adding a status that properly reflects hovering, while adding a new "functionality" to detect scripted hover height as the "state when the Avatar would otherwise be falling but has been made to hover?" (eg, falling+hover bits are true)
Jeremy Duport
AGENT_FLYING should only be true when an agent has client flying enabled,
not
when hoverheight and groundrepel are affecting it. That's long standing behavior as far as I know, going by animation state (falling) when held off the ground by hh/gr.Maestro Linden
tracked
Maestro Linden
needs info
Maestro Linden
Hi Zack Ormidale, thanks for the report. I do see that when I attach the script from the linked canny issue and have it make my avatar float via llSetHoverHeight, the agent flags returned by llGetAgentInfo() have the following flags enabled for the agent:
* AGENT_FLYING
* AGENT_ATTACHMENTS
* AGENT_IN_AIR
* AGENT_SCRIPTED
To be clear, is your complaint specifically that the AGENT_FLYING flag is enabled for the agent when hovering this way, with consequences to AO-set animations and some scripts kicking your agent for "flying" on no-fly parcels? Would suppressing that specific bit when hovering via llSetHoverHeight/llGroundRepel solve the problems you see?
The test scripts I used are shown below.
// llSetHoverHeight test
integer on;
default
{
touch_start(integer n)
{
on = !on;
if(on)
{
//llGroundRepel(2, TRUE, 1);
llSetHoverHeight(2, TRUE, 1);
}
else
{
//llGroundRepel(0, TRUE, 1);
llStopHover();
}
}
}
// llGetAgentInfo() test script
default
{
state_entry()
{
llSetScale(<0.2, 0.2, 0.2>);
llSetTimerEvent(0.5);
}
timer()
{
integer agentinfo = llGetAgentInfo(llGetOwner());
list info_list = ["llGetAgentInfo() for owner"];
if(agentinfo & AGENT_AWAY) info_list += "_AWAY";
if(agentinfo & AGENT_BUSY) info_list += "_BUSY";
if(agentinfo & AGENT_SITTING) info_list += "_SITTING";
if(agentinfo & AGENT_ON_OBJECT) info_list += "_ON_OBJECT";
if(agentinfo & AGENT_ALWAYS_RUN) info_list += "_ALWAYS_RUN";
if(agentinfo & AGENT_FLYING) info_list += "_FLYING";
if(agentinfo & AGENT_WALKING) info_list += "_WALKING";
if(agentinfo & AGENT_MOUSELOOK) info_list += "_MOUSELOOK";
if(agentinfo & AGENT_TYPING) info_list += "_TYPING";
if(agentinfo & AGENT_ATTACHMENTS) info_list += "_ATTACHMENTS";
if(agentinfo & AGENT_AUTOPILOT) info_list += "_AUTOPILOT";
if(agentinfo & AGENT_CROUCHING) info_list += "_CROUCHING";
if(agentinfo & AGENT_IN_AIR) info_list += "_IN_AIR";
if(agentinfo & AGENT_SCRIPTED) info_list += "_SCRIPTED";
info_list += "at " + llGetTimestamp();
llSetText(llDumpList2String(info_list, "\n"), <0,1,0>, 1.0);
}
}
Zack Ormidale
Maestro Linden
To your question:
Yes, it is correct! llSetHoverHeight says that my avatar is flying and as a consequence activates the AO animation. Furthermore, the fact that the avatar is flying generates AGENT_FLYING as true incorrectly, since this function should not activate the flight.
For the llGroundRepel suggestion, it went wrong:
I have never used llGroundRepel before, so I ran a test and the same thing happened, it also thinks that the avatar is flying, that is, using llGroundRepel did not work for me, keeping the same problem.
I have been using llSetHoverHeight for over two years and I can confirm that it has always worked correctly (and according to the wiki page that I included in a Print Screen). llSetHoverHeight is a function that holds the avatar in the sky without the avatar actually flying. During this function, AGENT_FLYING should not be detected as true.
It worked this way until the bug incident I mentioned, which trapped avatars in the sky. I believe whoever made the fix used some logic to free the avatars but left the function wrong.
Maestro Linden
Zack Ormidale: Thank you for the confirmation. I think your suggested change is doable.
Maestro Linden
under review
Zack Ormidale
Maestro Linden
Hello, I answered above. I use a translator, I hope everything works out. I look forward to hearing from you if you have any further questions.
Load More
→