Strafe Left/Right controls generating too many events?

Maybe someone here can let me know if I'm doing something wrong here.

Basically, if you write a script that takes controls, and is filtering those controls for edge & level & CONTROL_WHATEVER, this script will generate one matching event for any single keypress of an intercepted control. So if I'm filtering for edge & level & CONTROL_FWD, and press and hold forward, I'll get one matching event. This is fine.

This fails miserably, however, for CONTROL_LEFT and CONTROL_RIGHT, both under standard camera and mouselook. In these instances, the scripts seem to generate TWO matching events every time the left or right controls are pressed-and-held. Here's an example script:

default
{
    state_entry()
    {
        llRequestPermissions( llGetOwner(), PERMISSION_TAKE_CONTROLS ) ;
    }

    run_time_permissions( integer perms )
    {
        if( perms & PERMISSION_TAKE_CONTROLS ) llTakeControls( CONTROL_LEFT | CONTROL_ROT_LEFT, TRUE, TRUE ) ;
    }
    
    control( key id, integer level, integer edge )
    {
        if( level & edge & CONTROL_ROT_LEFT ) llOwnerSay( "rotleft" ) ;
        else if( level & edge & CONTROL_LEFT ) llOwnerSay( "left" ) ;
    }
}

When you press and hold the left arrow key (in standard view), you will receive one "rotleft" message while your avatar spins left. If you press and hold shift+left arrow key, however, you will receive TWO "left" messages. Also, if you enter mouselook and press and hold the left arrow, you'll also receive two "left" messages.

What's up with this? oO

It's worse than that. Add a couple of lines to detect when the keys are released, and you'll see that when you press and hold the strafe-left key, you get a DOWN-UP-DOWN sequence of control events. Same for strafe-right.

This really put a damper on one of my projects a year and a half or so ago. I wanted to do some specific (relatively rare) action when the user hit strafe-left and strafe-right at the same time... I think I was switching modes or something. It turned out that it was pretty much impossible to detect that kind of keypress, because both keys "bounced". I sent a very detailed bug report with a reproducible test case, and I believe it was ignored. :P

What do you want to bet it's some half-assed client kludge to get around some oversight on their part?

Yeesh, you're probably right.

No need for betting, just pop open the open source viewer code and look It's pretty interesting to see the control-related kludges and workarounds in there.

Looking at the source also allowed me to finally understand why stopping or overriding the prejump anim totally borks your avatar and gets it stuck in an animation and doesn't ever jump

Holy crap, I'm not the only one who's seen that? I thought I was going crazy.

I don't really have the time to plow through the viewer code and spend hours getting a real feel for it. Life just won't give me that kind of time right now. If you're feeling up to it, would you mind giving us a quick rundown on what you find out about this strafe bug in the code?

I'd also love to hear an explanation about why stopping the prejump breaks your avatar, if you'd share :)

I actually found a fairly straightforward solution to my original problem, by the way. Instead of checking for two 'presses' within a certain timeframe, I decided to instead test for the sequence 'press-release-press-release' within a certain timeframe. Works for double-taps and the annoying strafe movement thing doesn't interfere.

Hey, check it out, someone figured out how to fix this issue in the client source code: https://jira.secondlife.com/browse/VWR-287

That's great! I surely hope that gets rolled into the main client.

Sorry I never responded to your request, Lex, I never saw it :/ The thread must have rolled off the front page quickly or something....

Basically, prejump is a hack... Apparently the viewer waits until that animation has had time to play to completion, and refuses to do anything else until then. Until that bit is cleared in the agent's control flags, many things will not be able to proceed. Hmmm.... It's early, I just woke up, and that probably didn't make much sense.

Time for code, then

  void LLAgent::requestStopMotion( LLMotion* motion )
  {
  	// Notify all avatars that a motion has stopped.
  	// This is needed to clear the animation state bits
  	LLUUID anim_state = motion->getID();
  
  	// if motion is not looping, it could have stopped by running out of time
  	// so we need to tell the server this
  //	llinfos << "Sending stop for motion " << motion->getName() << llendl;
  	sendAnimationRequest( anim_state, ANIM_REQUEST_STOP );
  
  	// handle automatic state transitions (based on completion of animation playback)
  	if (anim_state == ANIM_AGENT_STANDUP)
  	{
  		// send stand up command
  		setControlFlags(AGENT_CONTROL_FINISH_ANIM);
  
  		// now trigger dusting self off animation
  		if (mAvatarObject.notNull() && !mAvatarObject->mBelowWater && rand() % 3 == 0)
  			sendAnimationRequest( ANIM_AGENT_BRUSH, ANIM_REQUEST_START );
  	}
  	else if (anim_state == ANIM_AGENT_PRE_JUMP || anim_state == ANIM_AGENT_LAND || anim_state == ANIM_AGENT_MEDIUM_LAND)
  	{
  		setControlFlags(AGENT_CONTROL_FINISH_ANIM);
  	}
  }
  

I think that code also explains why I occasionally dust myself off at weird times, like when I try to do a waving gesture.

The one that is really pissing me off the most right now (having made half-assed workarounds for the others) is the fact that if you touch the ground or another object beneath you while moving beyond a certain speed, you go into a run animation. Nevermind the fact that you are playing a priority four super-cool-looking ninja attack flip animation (or whatever), that damned spontaneous run animation right in the middle of your flip makes it look like your product is horribly broken.

Seriously, wtf? The run is priority 0 animation, so just why in the HELL is Second Life forcing it to play over the animations that I have spent hours making? And rising a bit in the air first doesn't work cause then you get the falling animation :/

BUMPY GROUND IN SL IS ABSOLUTE EVIL!!!!!