Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-233384] Scripts failing to receive rapid touch_start events under LL viewer #10489

Closed
1 task
sl-service-account opened this issue Feb 14, 2023 · 5 comments
Closed
1 task

Comments

@sl-service-account
Copy link

sl-service-account commented Feb 14, 2023

What just happened?

An existing game that's been running over a year has an element that simulates support of mouse double-clicks so users can manipualte an in-HUD puzzle. That doubleclick action no longer works in the LL viewer, but continues to work in some third-party viewers like Firestorm. This suggests something has changed with touch_start() event handling or generation that breaks existing content.

Here's a test script illustrating the issue:

default
{
    touch_start(integer n)
    {
        while (n--)
        { 
          float daTime = llGetTime();
          string msg = (string)daTime;
          if (daTime < 0.5)
              msg += " doubleclick!";
          llOwnerSay(msg);
          llResetTime(); 
        }
    }
}

 

Just put it in a cube. In the LL viewer, this is the output to a typical double click action:

[11:34] Object: 1.114410

 

Notice only one line of output.

Here's the output of the same script to a doubelclick action in the Firestorm viewer:

[11:41] Object: 5.445979
[11:41] Object: 0.156621 doubleclick!

 

The Firestorm behaviour seems to match what was happening then these games were designed: we were able to simulate double-click actions using llGetTime() and measuring the delay between touch_start events. Now, that behaviour has significantly changed.

Note that we're using this in a HUD; if you use it on an inworld object and have double-click teleports enabled, you may experience a surprise TP.

What were you doing when it happened?

Attempting to play a game that's been out on the grid over a year and that has had thousands of plays.

What were you expecting to happen instead?

I was expecting the double-click action I scripted would continue to behave as it did when the game was developed and tested.

Other information

At a guess, this will break quite a lot of existing content that attempts to simulate actions for double-click. That's at least half a dozen things of my own, and untold more across the grid.

Links

Related

Original Jira Fields
Field Value
Issue BUG-233384
Summary Scripts failing to receive rapid touch_start events under LL viewer
Type Bug
Priority Unset
Status Closed
Resolution Triaged
Reporter Lou Netizen (lou.netizen)
Created at 2023-02-14T20:39:41Z
Updated at 2023-05-10T17:15:51Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2023-02-14T16:01:39.614-0600',
  "Is there anything you'd like to add?": "At a guess, this will break quite a lot of existing content that attempts to simulate actions for double-click. That's at least half a dozen things of my own, and untold more across the grid.\r\n",
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'An existing game that\'s been running over a year has an element that simulates support of mouse double-clicks so users can manipualte an in-HUD puzzle. That doubleclick action no longer works in the LL viewer, but continues to work in some third-party viewers like Firestorm. This suggests something has changed with touch_start() event handling or generation that breaks existing content.\r\n\r\nHere\'s a test script illustrating the issue:\r\ndefault\r\n{\r\n    touch_start(integer n)\r\n    {\r\n        while (n--)\r\n        {\r\n            float daTime = llGetTime();\r\n            string msg = (string)daTime;\r\n            if (daTime < 0.5)\r\n                msg += " doubleclick!";\r\n            llOwnerSay(msg);\r\n            llResetTime();\r\n        }\r\n    }\r\n}\r\n\r\nJust put it in a cube. In the LL viewer, this is the output to a typical double click action:\r\n[11:34] Object: 1.114410\r\n\r\nNotice only one line of output.\r\n\r\nHere\'s the output of the same script to a doubelclick action in the Firestorm viewer:\r\n[11:41] Object: 5.445979\r\n[11:41] Object: 0.156621 doubleclick!\r\n\r\nThe Firestorm behaviour seems to match what was happening then these games were designed: we were able to simulate double-click actions using llGetTime() and measuring the delay between touch_start events. Now, that behaviour has significantly changed.\r\n\r\nNote that we\'re using this in a HUD; if you use it on an inworld object and have double-click teleports enabled, you may experience a surprise TP.',
  'What were you doing when it happened?': "Attempting to play a game that's been out on the grid over a year and that has had thousands of plays.",
  'What were you expecting to happen instead?': 'I was expecting the double-click action I scripted would continue to behave as it did when the game was developed and tested.',
}
@sl-service-account
Copy link
Author

Aglaia commented at 2023-02-14T22:01:40Z

Same issue here, in the Linden viewer only.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2023-02-14T22:14:14Z

I suspect Maint Q's fix for BUG-232446 is to blame.

@sl-service-account
Copy link
Author

JIRAUSER341305 commented at 2023-02-15T08:51:38Z

I was under the impression multiple clicks from the same agent before the script gets to process the first one, end up getting elided together.  This is why I generally advocate against trying to do double-click support in scripts.  Lag bites you both ways, either the events come in too slow and the script doesn't count it, or they come in too fast and SL elides them.

Could just be a thing with some viewers, perhaps?  Or an old issue that was fixed for a time?  I know I frequently had that issue, so I stopped trying to do multi-clicks unless I absolutely had to.  (Which is a shame, because I rather like the really simple algorithm I put together ages ago to do /(click-)*(hold)?/ as a signed click count.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2023-02-15T15:26:16Z

@blue, this isn't a case with some viewers. It, ATM, is affecting SL release and SL Maint.

I suspect the bug started in Maint Q, which was recently promoted and has not made it to TPV's yet.

The currently Firestorm beta does not have this bug.

@sl-service-account
Copy link
Author

Dan Linden commented at 2023-02-16T18:15:06Z

Thank you for the report, Lou!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant