[BUG-234405] Intermittent Scripting Issues since early July...

[sl-service-account]

What just happened?

llGetObjectDetails failed to return data when passed the UUID of an object that is on the region. Similar failures have also been observed using llKey2Name or llGetBoundingBox.

What were you doing when it happened?

I have been repeatedly probing for the cause of BUG-234214 for over a month now. Time invested has paid off as there is a reproduction script for at least the operation of llGetObjectDetails. Substituting llKey2Name or llGetBoundingBox will likely reproduce the issues as well.

What were you expecting to happen instead?

llGetObjectDetails, llKey2Name, and llGetBoundingBox should reliably return data for objects that still exist on the region. Empty lists/strings or should only be returned if the object is not on the region.

Other information

This issue is related to BUG-234214 as part of the observed behavior in that report is now able to be confirmed and replicated. This issue is still intermittent in nature so not every request will cause the issue to be observed. It may take many iterations for the behavior to be detected and measured.

Scripts attached replicate the issue. To use these scripts do the following:

1. Create an object named FauxGolfBall sensor and insert FauxGolfBall Sensor into its inventory.
2. Create an object named FauxGolfBall and insert FauxGolfBall script into its inventory.
3. Pick up the FauxGolfBall object, you will need this for the next step.

4. Create and object named FauxGolfBall rezzer and insert FauxGolfBall Rezzer and the FauxGolfBall object from the previous step into its inventory.

   These scripts will begin working immediately, and will continue testing until they are removed from the region.

   The rezzer object will rez a FauxGolfBall which will immediately alter its size, randomize a destination point within 60m of its position, and randomly choose a time between 3 and 20 seconds before it will delete itself. Once these have been done the FauxGolfBall moves incrementally toward the target location. Safeguards are in place to ensure the FauxGolfBall object does not have a final randomized destination more than 60m from the rez point (placing it firmly within the 95m sensor range at all times), and it will not exceed limits in the current region as it is programmed so that target destination positions are clamped to between 5m and 4000m on the Z axis and between 5m and 250m on either the X or Y axis.

   The rezzer and sensor track the FauxGolfBall by its UUID using llGetObjectDetails. The rezzer has this key as a result of rezzing the FauxGolfBall. The sensor has no knowledge of the UUID, but knows the objects name and that it is scripted, thus it can (and must) use llSensor or llSensorRepeat to find the object UUID.

   Once both objects have the UUID of the FauxGolfBall they can then make repeated calls to llGetObjectDetails at a rate of roughly 1 per second within a timer to get data such as name, owner, size, position, content of hovering text, and time remaining for the FauxGolfBall to exist.

   So long as the FauxGolfBall object is on the region this should allow for proper tracking of the information requested, but what is instead observed in this setup is that the calls to llGetObjectDetails don't necessarily fire properly as no data is returned (prompting a message reading "It's missing!" followed by a Unix time stamp). If this should happen more than twice in a row the object with said UUID is presumed to no longer be on the region (triggering a message reading "Lost it entirely!" again followed by a Unix time stamp). Please note that the sensor and rezzer object will issue no messages and will not turn red unless the hovertext on the FauxGolfBall was reported to display a time of 2 seconds or more remaining when data was last returned when by passing its UUID to llGetObjectDetails.

   Once the FauxGolfBall object is considered lost by the tracking object the object turns red and increments the error count on the description line. Objects are not likely to recover the data again once this occurs (this is why the same tracking simulation and reporting code is present within both the rezzer and sensor objects).

   The FauxGolfBall object will delete itself when the it's own remaining time is reduced to 0. Approximately two seconds after the object is actually gone or is considered permanently lost by the rezzer obect a new FauxGolfBall will be rezzed and the process will start anew.

    

   Balls are not going off region in all cases Maestro. The clamping failed due to a missing if statement, but you have again closed the ticket without first requesting error corrected code. By the way, this isn't the case for those of us placing the object at or near the center of our regions as the ball dies well before reaching region borders. I will refile again since you insist on me doing all this work again.

Attachments

• FauxGolfBall Rezzer.lsl 2023-09-11 19:22:14
• FauxGolfBall script.lsl 2023-09-14 14:04:00
• FauxGolfBall Sensor.lsl 2023-09-11 19:22:14
• repro.jpg 2023-09-10 07:17:31
• Smokey Valley Test Setup.png 2023-09-09 14:45:47
• So caL Test Setup.png 2023-09-09 14:45:58

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-234405 | | Summary | Intermittent Scripting Issues since early July... | | Type | Bug | | Priority | Unset | | Status | Closed | | Resolution | Not Applicable | | Reporter | Certified Lunasea (certified.lunasea) | | Created at | 2023-09-09T19:21:02Z | | Updated at | 2023-09-14T18:20:17Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-09-10T06:18:11.318-0500', "Is there anything you'd like to add?": 'This issue is related to BUG-234214 as part of the observed behavior in that report is now able to be confirmed and replicated. This issue is still intermittent in nature so not every request will cause the issue to be observed. It may take many iterations for the behavior to be detected and measured.\r\n\r\nScripts attached replicate the issue. To use these scripts do the following:\r\n\r\n1. Create an object named FauxGolfBall sensor and insert FauxGolfBall Sensor into its inventory.\r\n2. Create an object named FauxGolfBall and insert FauxGolfBall script into its inventory.\r\n3. Pick up the FauxGolfBall object, you will need this for the next step.\r\n4. Create and object named FauxGolfBall rezzer and insert FauxGolfBall Rezzer and the FauxGolfBall object from the previous step into its inventory.\r\n\r\nThese scripts will begin working immediately, and will continue testing until they are removed from the region.\r\n\r\nThe rezzer object will rez a FauxGolfBall which will immediately alter its size, randomize a destination point within 60m of its position, and randomly choose a time between 3 and 20 seconds before it will delete itself. Once these have been done the FauxGolfBall moves incrementally toward the target location. Safeguards are in place to ensure the FauxGolfBall object does not have a final randomized destination more than 60m from the rez point (placing it firmly within the 95m sensor range at all times), and it will not exceed limits in the current region as it is programmed so that target destination positions are clamped to between 5m and 4000m on the Z axis and between 5m and 250m on either the X or Y axis.\r\n\r\nThe rezzer and sensor track the FauxGolfBall by its UUID using llGetObjectDetails. The rezzer has this key as a result of rezzing the FauxGolfBall. The sensor has no knowledge of the UUID, but knows the objects name and that it is scripted, thus it can (and must) use llSensor or llSensorRepeat to find the object UUID.\r\n\r\nOnce both objects have the UUID of the FauxGolfBall they can then make repeated calls to llGetObjectDetails at a rate of roughly 1 per second within a timer to get data such as name, owner, size, position, content of hovering text, and time remaining for the FauxGolfBall to exist.\r\n\r\nSo long as the FauxGolfBall object is on the region this should allow for proper tracking of the information requested, but what is instead observed in this setup is that the calls to llGetObjectDetails don\'t necessarily fire properly as no data is returned (prompting a message reading "It\'s missing!" followed by a Unix time stamp). If this should happen more than twice in a row the object with said UUID is presumed to no longer be on the region (triggering a message reading "Lost it entirely!" again followed by a Unix time stamp). Please note that the sensor and rezzer object will issue no messages and will not turn red unless the hovertext on the FauxGolfBall was reported to display a time of 2 seconds or more remaining when data was last returned when by passing its UUID to llGetObjectDetails.\r\n\r\nOnce the FauxGolfBall object is considered lost by the tracking object the object turns red and increments the error count on the description line. Objects are not likely to recover the data again once this occurs (this is why the same tracking simulation and reporting code is present within both the rezzer and sensor objects).\r\n\r\nThe FauxGolfBall object will delete itself when the it\'s own remaining time is reduced to 0. Approximately two seconds after the object is actually gone or is considered permanently lost by the rezzer obect a new FauxGolfBall will be rezzed and the process will start anew.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Simulator', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'llGetObjectDetails failed to return data when passed the UUID of an object that is on the region. Similar failures have also been observed using llKey2Name or llGetBoundingBox.', 'What were you doing when it happened?': 'I have been repeatedly probing for the cause of BUG-234214 for over a month now. Time invested has paid off as there is a reproduction script for at least the operation of llGetObjectDetails. Substituting llKey2Name or llGetBoundingBox will likely reproduce the issues as well.', 'What were you expecting to happen instead?': 'llGetObjectDetails, llKey2Name, and llGetBoundingBox should reliably return data for objects that still exist on the region. Empty lists/strings or should only be returned if the object is not on the region.', 'Where': 'Multiple regions including Smokey Valley and So caL upon which testing apparatus has been installed.', } ```

[sl-service-account]

Certified Lunasea commented at 2023-09-09T20:06:29Z

Smokey Valley Test Setup image was take at a time that the error condition had been met 38 times on the sensor object (upper) and was not detected on the rezzer object (lower).

So caL Test Setup image was taken at a time that the error condition had been met 63 times on the sensor object (upper) and 1 time for the rezzer object (lower).

 

These test setups are still running as of this time but are in locations that are protected by security systems (meaning no public access).

[sl-service-account]

Alistar Snook commented at 2023-09-10T11:18:11Z

I was able to repro the bug in a region with different server release than your: Second Life RC Magnum 2023-08-24.581535

These are the message I got after more or less 1 hour and 10 minutes I launched your scripts:

[13:42] FauxGolfBall Sensor: It's missing! 1694292139

[13:42] FauxGolfBall Sensor: Lost it entirely! 1694292141

In attachment, the ball object became red.

[sl-service-account]

Certified Lunasea commented at 2023-09-10T18:03:11Z

It should be noted that the test setup will only turn red and increment the count if it was unable to recover from the issue (triggering the "Lost it entirely!" message). This count is written to the description line.

 

As of today logging in at just under 48 hours since last modification the sensor object on Smokey Valley is reporting 84 such instances, while the sensor object on So caL is reporting 139 such instances and the rezzer object on So caL reports 3 such instances.

[sl-service-account]

Lucia Nightfire commented at 2023-09-11T02:07:57Z

I don't understand what the problem is.

I added a UUID, llGetTimestamp() and llGetOwnerKey() check in the sensor script and added an ownersay with llGetTimestamp() when the ball executes llDie().

The ball dies and the sensor script no longer sees it which is proven by llGetOwnerKey() equalling the UUID, called after llGetObjectDetails().

[18:12:57] FauxGolfBall: Dying 2023-09-11T01:12:56.039869Z [18:12:57] FauxGolfBall sensor: 61131632-4fd6-c89f-a643-20e03bfdd2d4 is missing! 2023-09-11T01:12:56.284015Z 61131632-4fd6-c89f-a643-20e03bfdd2d4

[18:15:29] FauxGolfBall: Dying 2023-09-11T01:15:28.519035Z [18:15:29] FauxGolfBall sensor: a4d6b92a-1ee8-5581-5836-5553fde363ea is missing! 2023-09-11T01:15:28.519148Z a4d6b92a-1ee8-5581-5836-5553fde363ea

[18:29:20] FauxGolfBall: Dying 2023-09-11T01:29:19.611340Z [18:29:20] FauxGolfBall sensor: efa3dc22-16f4-9fcb-2c00-c2e7f3b9e4a4 is missing! 2023-09-11T01:29:19.611438Z efa3dc22-16f4-9fcb-2c00-c2e7f3b9e4a4

[18:47:36] FauxGolfBall: Dying 2023-09-11T01:47:35.024074Z [18:47:36] FauxGolfBall sensor: ab558763-ba9f-5da3-3099-39132d535920 is missing! 2023-09-11T01:47:35.024228Z ab558763-ba9f-5da3-3099-39132d535920

 

 

[sl-service-account]

Certified Lunasea commented at 2023-09-11T11:29:55Z, updated at 2023-09-11T12:18:00Z

The UUID is known by the rezzer object as it rezzed the tracked object, and the sensor object knows the name of the object. The sensor needs to obtain the UUID using llSensor, which is how discovery of specific object UUIDs work for many systems in SL.

The tracking occurs once per second or so depending upon time dilation, which on the regions I am running this on is extremely close to a value of 1 (perfect).

The tracked object displays its remaining lifetime in seconds (updated once per second) in hovering text which both the rezzer and sensor objects read when using llGetObjectDetails. If the last read of this text shows less than 2 seconds remaining then the error is not reported, as it is assumed that the tracked object has simply run llDie. If the last read text shows 2 seconds or more remaining then the object will report the issue.

The first message in the unmodified script occurs on the first instance that the object is found to be missing, and the second message in the unmodified script occurs when this state continues 3 times in a row. Again the tracked object is not considered missing if the object showed less than 2 seconds remaining in its lifetime, the error state only gets counted if the lifetime remaining was 2+ seconds as of the last read of the object using llGetObjectDetails.

In addition if what you saw was what was triggering the test devices that are currently out on more than just 2 regions, then we would should the testing objects reporting issues reliably on death of every tracked object, both by the sensor and by the rezzer object. This is not the case though.

Hopefully that clears your confusion.

[sl-service-account]

JIRAUSER332906 commented at 2023-09-11T21:09:20Z, updated at 2023-09-11T21:30:07Z

So at Rainbow Golf Links that i run,  i added a sensor object as our golf ball keep getting lost(still are) And it has in the 2 days its been here reported 97 lost or errors in the sim Thats just a havoc for our loveing SL golf game, as all scorecards give out all kinds of errors thats wrong and we cant do anything about.

Some thing is messed up as it happen after a Update from you guys in LL, and all worked fine before

PLEASE FIX IT 

 ღLexyღ (lexy.amore) http://maps.secondlife.com/secondlife/Gooseberry%20Elms/122/123/35

 

[sl-service-account]

Certified Lunasea commented at 2023-09-11T23:24:22Z

Rezzer and Sensor scripts updated to reduce the returned time remaining in the life of the FauxGolfBall to a simple integer for comparitive purposes. The results are identical.

[sl-service-account]

Certified Lunasea commented at 2023-09-12T19:29:32Z

Additional results today since rolling restarts, confirming that the issue is present for both Second Life Server 2023-07-31.581251 and 2023-08-24.581535.

[sl-service-account]

JIRAUSER332906 commented at 2023-09-13T08:12:30Z, updated at 2023-09-13T08:16:59Z

So almost 2 days later we are up to 187 @Gooseberry Elms https://gyazo.com/0356fddce9077babc29792f46bb84549 New FauxGolfBall is added Sep. 13. 2023

[sl-service-account]

Certified Lunasea commented at 2023-09-13T11:19:28Z, updated at 2023-09-13T11:25:33Z

I installed the newer scripts into the setups I had and reset them on the 11th.

From the 11th through the 13th the newer scripts have been running constantly on both the Smokey Valley and So caL regions and the findings with the new setups are as follows:

• The setup on Smokey Valley shows 44 instances recorded on the sensor object.

• The setup on So caL shows 150 instances on the sensor object and 2 instances on the rezzer object.

  These readings are only the occurrences since the new setups were installed and are the current readings on the objects as of 04:18:54 on 09/13/2023.

[sl-service-account]

JIRAUSER332906 commented at 2023-09-13T18:29:02Z

so far 36 [11:26] Faux Golf Ball Sensor: It's missing! 1694629568 [11:26] Faux Golf Ball Sensor: Lost it entirely! 1694629570

[sl-service-account]

JIRAUSER332906 commented at 2023-09-14T11:19:22Z

Do we even know if they looking at this or just dont give a %&%¤ Be nice to know!!

[sl-service-account]

Certified Lunasea commented at 2023-09-14T15:18:58Z

Updated report on the reproduction scripts that are setup on the Smokey Valley and So caL regions:

• The setup on Smokey Valley shows 90 instances recorded on the sensor object (sensor object detected an additional 46 instances since last report).

• The setup on So caL shows 238 instances on the sensor object and 2 instances on the rezzer object (sensor object detected an additional 88 instances since last report).

  These reading are cumulative for the period from the 09/11/2023 through 09/14/2023 at 07:55:52AM SLT and show a total of 134 additional instances across both regions since last report.

  It would be nice to know if any Linden has even peered into the issue since other Jira reports have been opened, investigated, and closed since this report was filed. I do hope that once a Linden does look into this issue that they will post a comment to let us know if they are willing or able to dedicate time to test and/or correct this issue or if they should need more information. That said, I believe that since they now have a set of issue reproduction scripts the information may just take them time to gather and may require them to analyze the issue reproduction scripts and how they work.

[sl-service-account]

JIRAUSER332906 commented at 2023-09-14T15:58:34Z, updated at 2023-09-14T18:20:17Z

update now up to 85 pressent moment @Gooseberry Elms

@Maestro Linden and Your answer under here. Guees you had it closed so we could not respond to you................... Support they call it ROFL You think we hit the damn ball off sim??? What ever you say there is just wrong, bet you say it and close the ticke as you and all of you have no clue. But you want us all to spend our money in here and this is the support we got when we need it? Sad is what you all are, lets hurry to close this ticke before thet know we got no clue what we are doing her@LL Sure we are just 1100 memebers in my golf group and all love Golf and why i made a golf course in there. my 6th if your counting. Guess we dont care for you all to try and help with a problem we having and all from you guys making it??

[sl-service-account]

Maestro Linden commented at 2023-09-14T16:37:14Z

I added a a few basic debug statements to the scripts

1. Updated the "missing", "lost" messages in both the rezzer and sensor scripts to be more specific: Java llOwnerSay((string)uuid + " is missing! " + llGetTimestamp()); ```Java llOwnerSay("Lost " + (string)uuid + " entirely! " + llGetTimestamp());

2. Updated the golf ball script to actually announce when it's dying: ```Java llOwnerSay((string)llGetKey() + " die at " + llGetTimestamp());

3. Updated the golf ball script to announce its position each time it moves: ```Java llOwnerSay((string)llGetKey() + " moving to position " + (string)(llGetPos()+step)); llSetPos(llGetPos()+step);

   
   - This is important in case the golf ball is moving to off-sim coordinates, which would of course cause llGetObjectDetails() to not pick it up 
   
    With these debug messages in place, the messages leading up to the "missing" and "Lost it entirely!" messages look like this:
    > [09:25] FauxGolfBall: 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 moving to position <235.94980, 99.69374, 2002.87400>
    > [09:25] FauxGolfBall: 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 moving to position <244.03340, 104.80750, 2005.79000>
    > [09:25] FauxGolfBall: 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 moving to position <252.11700, 109.92120, 2008.70700>
    > [09:25] FauxGolfBall: 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 moving to position <260.20060, 115.03490, 2011.62300>
    > [09:25] FauxGolfBall rezzer: 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 is missing! 2023-09-14T16:25:55.306151Z
    > [09:25] FauxGolfBall sensor: 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 is missing! 2023-09-14T16:25:55.549645Z
    > [09:25] FauxGolfBall rezzer: Lost 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 entirely! 2023-09-14T16:25:57.306094Z
    > [09:25] FauxGolfBall sensor: Lost 5e59bc2a-0e1c-f9bd-27d1-d16dca930bd2 entirely! 2023-09-14T16:25:57.549933Z
   
    I stayed through this for a few dozen balls, and the balls that go "missing" are ones that move to off-sim coordinates - <260.20060, 115.03490, 2011.62300> in this particular example.   This indicates that the clamping logic is failing; it is not clamping ball positions to the [5, 250]m range on the horizontal axes - you need to fix your math.  The `target` vector appears to be clamped, but you need to reexamine the math used for either your `step` vector and `llSetPos()` call.
   
    The balls while do not go off-sim make it to the llDie() call without any errors being reported.