Control event overrunning

[Gregory McLeod]

I am trying to debug a HUD which responds to key presses to start or stop walking, running, or sprinting.

The problem is the transition from Running to Sprinting. This  is currently achieved by a Double Tap and Hold of the Forward key. There is a hesitation occurring between the Running and the Sprinting animations. I initially put this down to the need to release the Forward key before the Double Tap and Hold of the Forward key stopping the Running Animation before the Sprinting animation is started. However further thought created some doubt on this analysis.

The question is related to the amount of processing that needs to be done by the HUD script in the control event section of the code.

What happens if the code for the first control event is not completed before the second event is triggered?

Any help appreciated.

[Innula Zenovka]

This doesn't answer your question directly, but since you say you are "stopping the Running Animation before the Sprinting animation is started," wouldn't that cause the hesitation anyway?

I would start the sprinting animation and then stop the running one, and see what that looks like.

[Gregory McLeod]

The existing script does just that: stops the running script then starts the sprinting script.

I plan to change that.

The two animations currently have the same priority. Starting the second does not change the animation that is seen.

I plan to change  the controlling or operating keys:

The current has the double tap and hold of the Forward key for sprinting. My plan is to utilise the Backward key in conjunction with the Forward key with suitable detection. Sprinting key will NOT be honored while the Foward key is NOT held, it will still be the backward movement key. If the Forward key is held and the Backward key is pressed and then held the sprinting animation will be started and then the running animation stopped. I plan to go further in that if the Forward and the Backward keys are both held then the running animation will be retarted. When the sprinting key is released and the running key continued to be held the sprinting animation will be stopped  leaving the running animation to be seen.

My concern is the extra processing that will be involved and my question remains what happens if the script is still processing one movement key 'Control Event' when another movement key is pressed or released or held?

Thanks for your interest.

 

[Ela Talaj]

An "event" is a system function which differs from a user function only in that that instead of being passed arguments it waits to receive same from the operating system which in turn receives them from the outside world. In stand-alone applications such arguments are called signals while in embedded environment they are called interrupts. How the interrupts ("events" in our terms) are processed depends on a specific system.

Some systems allow what is called "nested interrupts" that is interrupts of different priorities. When an interrupt of a higher priority is received while the previous one of a lower priority i still being processed the OS stops processing a lower priority interrupt and switches to the processing a new higher priority interrupt. The old processing resumes when the new one is complete.

In other systems all interrupts have the same priority and the LSL state machine resides in this group. An event (interrupt) is processed by its event code until completed. If a new event comes during processing the previous one it is queued in FIFO order. On information and believe the LSL queue is limited to 64 events.

[Gregory McLeod]

Thanks for your input Ela.

The problem I aam having is understanding the timescale of the events. Remember the user is pressing keys and the viewer is sending them to SL. While I understand about the limit of events (64 I think you said) I am not clear on what controls the events in this case. If an SL viewer is running on a slower machine are the control inputs still generated or are they limited to the frame rate?

I have tested a simple control box which responds to the pressing and holding of a movement key every 20-25 mSecs.

Now I am not sure whether this is because of the speed of my machine or the frame rate, it seems suspiciously like the frame rate. Now 20mSecs is a long time in a computer but if there are other actions going on in the sim what time slice does the script get to process the control event interrupt?

[Ela Talaj]

There is no way on earth your fingers no matter how fast can press a key with 40 Hz frequency. So how do you simulate one in 25 msec key press to deliver from your PC to the server? From what I remember your kbrd driver works on a 100 msec timer though I might be wrong...don't recall for sure from the top of my head.

[Gregory McLeod]

I am not sure what you mean.

I have setup a box prim with a script which requests control of movement keys.

When running the control event fires and presents three parameters id, level, and edge.

If I say the the time every time it fires and then press and hold one of the movement keys it puts timestamps which are 20 - 25 mSecs apart. I have tried this from another PC and there is a difference the timestamps are 45 - 50 mSecs apart.

This suggests to me that the timing is driven by the rate at which the viewer can generate a message to SL and the SIM respond by creating the control event. It is not the rate at which you can press and release the keys it is the rate at which your machine and the SIM can generate the event.

Now in my case the HUD that I am working on could generate all these control events and although 20 mSecs is a very short time in RL it is a lot of time to process things in a script. However I want to plan for the situation where for reasons of load on the SIM the timeslice given to the HUD and the HUDs of all the other players is insufficient to process the script.

What happens?

Other sources suggest there is a queueing of events up to 64 deep but what then are they just dropped?

What about 24 HUDs all in one SIM doing the same thing generating control events for themselves by holding down movement keys?

I hope I have explained more fully.

[Qie Niangao]

I'm not really following all this, but you mentioned that you're planning to change the specific control gestures used to determine what animation will play. I'd recommend that you debug using those planned gestures, if they won't be including double-tap of the CONTROL_FWD key. The reason is that this particular keypress activates AGENT_AUTOPILOT (depending on viewer and perhaps preference settings) and there are some known eccentricities with how that works.

I realize this isn't the question you're asking. I don't know what happens to new control events when the buffer is full, and whether or not that's different when the sim is lagging. It's a valid question, but maybe there's a way to make progress before knowing the answer.

[Gregory McLeod]

Thanks for your input Qie. The HUD does use the double-tap and hold function but it is with the Foward key and not the left mouse button as described in the Ui advanced features article. Necertheless thanks for the thought.

[Ela Talaj]

Ahh... so you are just holding the key. Then I guess I was wrong about the kbrd 100 msec timer and it is much faster. Apparently you are holding an arrow key for the agent keep moving. From a purely prctical point of view I wouldn't worry about the interrupts rate and such.

I've written several scripts which include taking control for a purpose of moving the agent. For as long as I keep the key pressed the agent is walking when I release the key it stops. I'm yet to notice it quits walking while the key is pressed and no customer reported such occurance either. In a very busy sim with many agents present the walk would be lagging of course but no more than when I just move the agent via arrow keys manually. The lag has more to do with the sim rendering avatars (it is a very complex process) than with dropping keystrokes in a script.

[Qie Niangao]

Oh, duh. You're right: I mentioned the vagaries of AGENT_AUTOPILOT but was thinking about "Tap-tap-hold to run" which is a different thing altogether.  Sorry.