Touch Start delays on an object after rotation?

[Eric Stuart]

I figure I know the answer to this and I'm just making sure I'm not going crazy.  A game I'm working on requires targets to be pressed when they rotate out.  When I tested without pop-up, no delays, no issues, I could touch them the moment they activated and it worked.  But now that the targets are in and it's rotating out, if I click the target, it's immediately failing to fire off and takes a few clicks.  It doesn't seem super consistent but there's often a slight delay (up to maybe half a second, maybe more, never longer than a second) after the rotation.  Is that just Second Life catching up to the rotation?  I am using llSetLinkPrimitiveParamsFast, in case I'm missing a better option.  Only reason I think this could be it is if I click where the root of the object is, it seems to still activate immediately because it never moves from that spot, though the targets do rotate.  I've tried even setting an activation true/false before the rotation happens and it still delays when I click the target so I'm hopeful I'm just doing something wrong.  Any help would be greatly appreciated.  Thanks!

 

[Qie Niangao]

Maybe somebody else will recognize this but it doesn't sound familiar to me, so a minimum script that reproduces the effect might help. (If I were sure what it means for a target—whatever a "target" is—to "rotate out", I'd try to replicate it myself.)

Just to make sure I understand what this script is doing: you are using llDetectedTouchUV, or llDetectedTouchST, right? or even llDetectedTouchFace if that's all that matters? or… yeah, now I really wonder what "rotate out" means here.

If the rotation is being done by llSetLinkPrimitiveParamsFast, not llTargetOmega, that removes one set of potential complications.

It's not obvious why there'd be a state change in the script, but I'm reminded that touch_start() after returning from a state change is problematic. And that reminds me that it's possible for the event queue to overflow but that's not easy to make happen.

[Wulfie Reanimator]

llSetRot has a forced delay of 0.2 seconds.

[Eric Stuart]

18 minutes ago, Wulfie Reanimator said:

llSetRot has a forced delay of 0.2 seconds.

So I tried to combat this with having the root object be what controls the rotation, and then the script in the linked object (the target) is the one that handles the touch start reaction.  To answer both questions, this is my current attempt to see if I can figure out what is causing the delayed response:

• Root object with game engine randomly chooses a select number of targets based upon difficulty.
• Root object sends an activation linked message to the linked target, setting it's activation to TRUE.
• Linked object receives activation message, llSetColor() on a face of the mesh to show it's lit up and ready to be clicked.
• Root object immediately rotates the target out as the linked object activates.
• Target rotates out, red light indicating target is ready.
• Player clicks the target that appears to show it's activated and ready.
• Touch_Start verifies activation is TRUE, immediately sends a linked message to another script that controls game progress, flashes green, then back to the "off" color (grey).
• Root stores a timer for all targets simultaneously and also sets the linked object's specific face's color to the grey, just in case they missed it.
• Root rotates the targets back, then processes the next set of targets.

Everything here works perfectly except that odd delay.  I originally just had it trigger the rotation within the linked object's script on activation, but I was getting delays so I thought it was possibly that.  So instead, I programmed the root to handle rotation and a color reset only in the case that it didn't get pressed.  The target now only waits for an activation, and then immediately sets the color and is able to be clicked through Touch_Start.  I tried having the activation sent before the llSetLinkPrimitiveParamsFast so that I can maybe bake the delay in before the rotation, thinking it was a sleep of some kind that was forced by something, but it still has the same issue.  Target pops out and if you click it too fast, even though it's activated and shows as much, it doesn't recognize it if you click within the first quarter second.  This seems trivial for most things but as this is meant to be a reflex game, I'm having a lot of issues with that small delay and it's the one thing standing between a frustrating game and a finished game.

I hope this helps.  I'm open to options and things to try too, because with that ever-present delay, it almost punishes having too good of reflexes, even if the target is in place, lit up, and clearly activated.

[Qie Niangao]

Would it be possible to just comment out all code that performs the rotation, just to see if that rotation is somehow causing the problem?

If it were me, I'd put everything in the root prim, with all the gameplay in a single script, only using llMessageLinked if necessary to send results to a housekeeping/recordkeeping script, also in the root prim. I'd also use PRIM_LINK_TARGET if needed to combine any simultaneous object updates into a single call to llSetLinkPrimitiveParamsFast().

[Quistess Alpha]

5 hours ago, Eric Stuart said:

Is that just Second Life catching up to the rotation?

If I had to guess, it might be somehow due to the client-side rotation interpolation effect. If this is as important as it seems to be, you might consider re-designing the system so that instead of rotating the pieces, you have 'before' and 'after' as separate pieces, and toggle the alphas visible and invisible instead of moving the parts.

[Eric Stuart]

4 hours ago, Qie Niangao said:

Would it be possible to just comment out all code that performs the rotation, just to see if that rotation is somehow causing the problem

One of the first things I tried, which led me to wonder if rotation on an object in general caused some issue like this, and not just an lsl issue.  Commented out the rotation and there's no delay whatsoever, only comes after rotating the targets out.  That led me to have the root alter the linked object's rotation, and have the actual script in the target be separate, to try and eliminate any baked in sleeps/delays.  It does combine them though, so that's not an issue.  I had thought if it sent the activation first, then it'd be okay, but still that delay persists.

3 hours ago, Quistess Alpha said:

If I had to guess, it might be somehow due to the client-side rotation interpolation effect. If this is as important as it seems to be, you might consider re-designing the system so that instead of rotating the pieces, you have 'before' and 'after' as separate pieces, and toggle the alphas visible and invisible instead of moving the parts.

And this was my fear, that it may be client side.  That I can SEE it rotate but the item itself doesn't register properly between client and server.  I know I can do alpha toggling, I just hoped to avoid it because the targets popping out just looks so much better.  Oh well, nature of the beast if that's the case.

Thank you all for your help, if it wasn't a game based on reflexes this wouldn't be anywhere near the issue it is.

[Quistess Alpha]

9 hours ago, Eric Stuart said:

I know I can do alpha toggling, I just hoped to avoid it because the targets popping out just looks so much better.

Here's a thought: what if you put an invisible clickable thing just in front of where the clickable things move to, and you just use logic to not count if it's touched before the visual display thing behind it pops out?

[Qie Niangao]

I still don't understand what this game is doing and what's going wrong. I realize it's been explained twice now, so just assume I'm an idiot, but I need an example. So I made one that seems sorta like what's described, so we can look at the script and figure out how to make it fail. To try, link together four prims and drop this script in it:

rotation ROT_UP = <0, -0.70711, 0.70711, 0>;
rotation ROT_DOWN = <-0.5, -0.5, 0.5, 0.5>;
vector GRAY = <0.5, 0.5, 0.5>;
vector RED = <1,0,0>;
vector GREEN = <0,1,0>;

integer flipLink;

countDown()
{
    integer count;
    for (count = 3; count > 0; --count)
    {
        llSetLinkPrimitiveParamsFast(3, [PRIM_TEXT, (string)count, <1,1,1>, 1.0]);
        llSleep(0.5);
    }
    llSetLinkPrimitiveParamsFast(3, [PRIM_TEXT, "", <0,0,0>, 0.0]);
}

default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(LINK_SET,
            [ PRIM_TEXTURE, ALL_SIDES, TEXTURE_BLANK, <1,1,0>, <0,0,0>, 0.0
            , PRIM_COLOR, ALL_SIDES, GRAY, 1.0
            , PRIM_FULLBRIGHT, ALL_SIDES, FALSE
        , PRIM_LINK_TARGET, LINK_ROOT
            , PRIM_SIZE, <1.5, 1.5, 1.5>
            , PRIM_ROT_LOCAL, ROT_DOWN
            , PRIM_TYPE, PRIM_TYPE_BOX, PRIM_HOLE_DEFAULT, <0.625, 0.875, 0>, 0.95, <0,0,0>, <1,1,0>, <0,0,0>
        , PRIM_LINK_TARGET, LINK_ALL_CHILDREN
            , PRIM_SIZE, <0.01, 0.375, 1.5>
            , PRIM_ROT_LOCAL, ROT_DOWN
            , PRIM_TYPE, PRIM_TYPE_BOX, PRIM_HOLE_DEFAULT, <0,1,0>, 0.0, <0,0,0>, <1,1,0>, <0,0,0>
            , PRIM_SLICE, <0.5, 1, 0>
        , PRIM_LINK_TARGET, 2
            , PRIM_POS_LOCAL, <0, 0.71, 0.5625>
        , PRIM_LINK_TARGET, 3
            , PRIM_POS_LOCAL, <0, 0.71, 0>
        , PRIM_LINK_TARGET, 4
            , PRIM_POS_LOCAL, <0, 0.71, -0.5625>
        ]);
    }

    touch_start(integer total_number)
    {
        string timeString = (string)llGetTime();
        integer touchedLink = llDetectedLinkNumber(0);
        if (1 == touchedLink)   // touched backstop to start
        {
            llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN, 
                [ PRIM_ROT_LOCAL, ROT_DOWN
                , PRIM_FULLBRIGHT, ALL_SIDES, FALSE
                , PRIM_COLOR, ALL_SIDES, GRAY, 1.0
                ]);
            flipLink = 2 + (integer)llFrand(3.0);
            countDown();
            llResetTime();
            llSetLinkPrimitiveParamsFast(flipLink, 
                [ PRIM_ROT_LOCAL, ROT_UP
                , PRIM_COLOR, ALL_SIDES, RED, 1.0
                , PRIM_FULLBRIGHT, ALL_SIDES, TRUE
                ]);
        }
        else
        if (touchedLink == flipLink)
        {
            llSetLinkPrimitiveParamsFast(touchedLink, [ PRIM_COLOR, ALL_SIDES, GREEN, 1.0 ]);
            llWhisper(0, timeString+": touched "+llGetLinkName(touchedLink));
            llSleep(1.0);
            llSetLinkPrimitiveParamsFast(touchedLink, 
                [ PRIM_COLOR, ALL_SIDES, GRAY, 1.0 
                , PRIM_FULLBRIGHT, ALL_SIDES, FALSE
                , PRIM_ROT_LOCAL, ROT_DOWN
                ]);
        }
    }
}

I know it's not the same, but what am I missing?

Edited August 6 by Qie Niangao
missing "what" in "what am I missing" — a self-referential typo

[Eric Stuart]

I will give that a go but I believe it's a rotation issue client side that's causing it.  I had another scripter friend take a look and he came to the same conclusion, something with the rotation is causing it to have issues natively and not through code.  Like it's not recognizing my click based not on LSL but the object itself not even thinking I am clicking it, even when I remove the if/then and just have it be general with how it responds on touch.  So I'm just trying it with a mesh that has hidden and visible parts.

It is close to that, but the version I had before I reworked it to just do transparency swapping I also tried a secondary controller in the pads that handled the touch_start.  Tried a few things too, like detecting it was activated based on the color of the face, based on an activation command, etc.  Something within SL just does not like sudden click on a rotated mesh, unless it's at a place where the object isn't moving, so it's likely some client side issue.  If you'd like, you're welcome to hit me up in world and I'll send you what I've got and you can poke it, if the mystery intrigues you.

[Phate Shepherd]

I've had some really bizzaro behavior on some self-modifying objects related to touch_start. In those rare instances, switching to using the touch_end event resolved it. Worth a shot.

Edited August 11 by Phate Shepherd

[AWalphaomega]

Sounds like whack-a-mole

 

does it do this if the object is physical?

[Qie Niangao]

52 minutes ago, Phate Shepherd said:

I've had some really bizzaro behavior on some self-modifying objects related to touch_start. In those rare instances, switching to using the touch_end event resolved it. Worth a shot.

There's a very long history of state related bugs with touch_start. You may have encountered something else, but the one I was thinking of has carried down to this form in the jira archive.

I took a look at @Eric Stuart's specific situation and it appears that this affects exclusively the extreme "tip" of the rotating mesh: the visual representation got there before there was "stuff" to register the touch. Waiting a tiny fraction of a second after the rotation appeared complete and touch_start worked as expected.

(I wasn't able to replicate this problem with my hokey prim build.)

[Eric Stuart]

Prim build works fine.  The mesh on the rotation causes all sorts of weirdness that we couldn't pinpoint.  With it being a game that required fast reactions, the faster you get, the higher the chance that a click didn't register and my god does that affect gameplay in the biggest way.

I've got it now set to do an alpha swap between two objects.  It's not what I wanted but it's precise and no issues.  Nature of the beast that is SL.