I have been able to reproduce it on demand. You have to be in a very laggy sim to be able to reproduce the problem, and at same time click on the object with the touch_start() event. THe higher the lag in the SIM, the higher the chance of a touch_start() endless-loop event will be created.

I have found a "work-around" that cancel's this endless loop tho. If the endless loop occurs, just SLOW-click once more on the same object (left-click and HOLD mouse button for a second, then release), and the endless touch_start() and touch_end() loop will disapear again.

This problem has been existing for at least 2 years of my experience. I personally discovered it back in early 2006 and it has since then existed in very laggy sims all over secondlife.

This problem occurs on ALL kinds of products using touch_start() as a event trigger for menus or anything else for that matter. Anything using touch_start() event has a chance of getting into a endless loop (even tho there is no loop inside the event itself). But to my experience, laggy SIM's seems to be the major trigger-factor. Fast working SIM's (low-lag or no lag) seems to rarely or never create this weird endless loop.

I am not sure if its a server-side problem or client-side problem. The way it acts, it could be any of them. I really don't know for sure.

With the help of my customer Tristram Petion, this issue is now isloated to a failed llDialog call when the following conditions are true:

1) The object containing the script is deeded to the group owning the parcel the object is on.
2) The script employs a repeating sensor.
3) The script calls llDialog during a touch_start event.
4) An unknown condition exists on the server.

Alvargi....

At the time of the test:
Time Dilation :96
Script Time: 18.2

Script output:

--------------- snip --------------

[12:48] SVC-1815 Test 4: state_entry
[12:48] SVC-1815 Test 4: Blackstone
[12:48] DaAngel Roussel is Online
[12:48] SVC-1815 Test 4: Blackstone 11 - Amor Fati
[12:48] SVC-1815 Test 4: <57.74664, 229.14827, 374.62360>
[12:48] SVC-1815 Test 4: 81573897-57a8-48f0-99fb-5b554e5524da
[12:48] SVC-1815 Test 4: 2008-03-11T19:48:25.447685Z
[12:48] SVC-1815 Test 3: sensor 2

.... deeded to group here

[12:50] SVC-1815 Test 4: touch_start 1
[12:50] SVC-1815 Test 4: llDetectedKey(0) 81573897-57a8-48f0-99fb-5b554e5524da

no dialog appeared

[12:50] SVC-1815 Test 4: touch 1
[12:50] SVC-1815 Test 4: sensor 2
[12:50] SVC-1815 Test 4: touch_end 1

--------------- snip --------------

Here is the script used to islolate the issue:

// SVC-1815 repro
default
{
state_entry()

state_exit()

sensor(integer total_number)

no_sensor()

touch_start(integer total_number)

touch_end(integer total_number)

touch( integer total_number)

}

Thanks,
Alvargi

default
{
state_entry()
{
}

touch_start(integer total_number)

}

Infact, this problem is NOT related to sensors at all. When the bug occurs, all DEEDED objects trying to show llDialog() windows will silently fail. The code above is a simple but effective code to test it's presence. First rez a object and put this script inside it. Then click on it to confirm that llDialog() works in non-deeded mode. Then, DEED the object with this script and repeat clicking on it. If the bug is present in the SIM, the code will be unable to show you a llDialog() window.

I have located a couple of SIM's that this problem can be replicated:

the flying dutchman, Jayzee Isle (44, 151, 23) - Owner: whisper Ansome
A Princess's Dream, Hydrogen (97, 18, 22) - Owner: Queeny Hax

The Jayzee Isle seems to have this as a MAJOR repeating problem. So it should be fairly easy to replicate the bug at that location.

Currently there is a workaround to temporary fix this. The sollution is to REBOOT the SIM and the problem goes away for a small amount of time, but usually it reappears within a day.

I really hope this problem will be fixed, since i get about 3-5 requests per day from customers experiencing this problem. If any of the Linden Labs employees needs further information, please contact me directly in-world and i will be happy to show the problem.

I did attempt to repro this with objects without a sensor and could not. Deeded objects without sensors behaved fine for me in the two sims above, then when I added a sensor; the problem reproduced faithfully.

Regardless, this confirms there the issue with llDialog in deeded objects. I currently receive 2-3 support requests about this each day and am looking for a dev at Lindent to be assigned this bug to work with.

Best,
Alvargi

I will continue post SIM's and coordinates i find with this problem whenever i find them

This is also not region specific, it's been tested at multiple regions.

Main issue is, I own land which has been deeded to the above group, and some objects need to be deeded to the group in order to function.

This started Saturday, 19 Apr 2008, and confirmed Sunday, 20 Apr 2008

It's also been confirmed by an SL Mentor: Jessica Lyon

Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)

You are at 277299.0, 298280.0, 22.2 in Whispering Sands located at sim4583.agni.lindenlab.com (63.210.158.233:13005)
Second Life Server 1.20.1.85162

CPU: Intel Core 2 Series Processor (2999 MHz)
Memory: 2030 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 7300 GT/PCI/SSE2
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14564 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 402/554634 (0.1%)
Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a

http://slurl.com/secondlife/Uxeter/34/232/13

Before searching Jira, I did some testing using llDialog() and a deeded object, and came to the same conclusion as Thomas Conover above. His script is a simpler version of the one I was testing, so I won't bother to share mine, but the result is the same. At any rate, llDialog() works fine when the object is not deeded, but never returns when it is.

Interestingly, I also tested it by touching a deeded object across a region border. In this case, I was standing in Uxeter, but the object was in Vional to the north. The llDialog() function worked properly, even though I was a child agent of Vional and physically standing in Uxeter. The reverse, however, did not work.

when dialog appears, it displays name as "(?) (?)'s Object"

p.s. : Second Life Server 1.21.1.86182

Edited : May 9, 2008 11:49 AM PDT : After couple of hours; it displays name as "'s Object"

No "(?) (?)" anymore.

http://slurl.com/secondlife/Vional/128/128/12

Yet, the menus (llDialog) from deeded objects are not working, though it works fine on objects that are not deeded.

You are at 265554.8, 239038.4, 709.0 in Deulchangil located at sim3928.agni.lindenlab.com (63.210.156.86:12035)
Second Life Server 1.21.1.87495
Time: 1200 SLT 24/May.

Can I suggest including the sim info and time as above (help->about second life)? It may only affect particular sims (I believe a sim reboot normally moves the sim to a different physical server) at particular times.

http://slurl.com/secondlife/Bailers/123/116/701

Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)

You are at 268667.8, 254336.0, 701.3 in Bailers located at sim4310.agni.lindenlab.com (63.210.157.214:13004)
Second Life Server 1.22.1.88473

http://slurl.com/secondlife/GreenLand/102/180/23

Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)

You are at 204902.9, 283572.2, 23.5 in GreenLand located at sim7660.agni.lindenlab.com (8.10.148.227:12035)
Second Life Server 1.22.3.89352

Occured first yesterday - Group shows also "waiting" - after a few hours the problem disappear (without SIM reset!) and suddenly many of the missing dialog windows pop up.

Today problem is back, but this time group is displayed right in the edit window

http://slurl.com/secondlife/Bliss%20Forest%20Seven/149/110/22

Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)

You are at 230555.0, 228729.0, 21.5 in Bliss Forest Seven located at sim7899.agni.lindenlab.com (8.10.148.138:13009)
Second Life Server 1.22.3.89352

Group shows also "waiting"

I do a similat thing with collisions, with or without llVolumeDetect() using a variable that holds the key of the last agent to collide with them for anywhere from 1 to 5 seconds (or more, as usage dictates) such that only the first such collision is detected and all subsequent collisions are ignored.

These are common practice in RL programming (or ought to be!) and will serve you well.

Most especially when llGiveMoney() and money() events are concerned.

Menus for deeded objects no longer responding.

You are at X, X, X in Maat located at sim3205.agni.lindenlab.com (216.82.20.194:13002)
Second Life Server 1.23.4.93100

And it's not just radios, any object that is deeded to a group will no longer detect a touch, radio's, tv receivers, prim counters, anything, and the slow touch workaround does not work, nothing does that I've tried. Sort of a serious bug. I'm using the RC viewer, but i also tried the 1.20 viewer and it makes no difference.

It has nothing to do with lag, this never works under any conditions now in those 2 sims.

A couple of lines would go a long way in helping me be more comfortable as to what the status is.

Why do I care? (It would not be fair for me to gripe and not let you know what my point of view is based off of)
1. I do write scripts that occasionally need to be deeded.
2. I rent my place. As a renter I have to use deeded objects. Several are not usable at this time sue to this issue.
3. The land owner is a very close friend and this issue makes supporting her tenants more difficult.
4. It is rather difficult to describe the problem to newbies when their setting up their first radio. I do occasionally have to do this as a Mentor.

default {
touch_start(integer total_number) { llSay(0, "should see dialog now"); llDialog(llDetectedKey(0), "a dialog with no specific buttons", [], -1); }
}

When this script is running in an object owned by my avatar, both say and dialog appear. When deeding the object to the land owning group (Immersive Workspaces), the say works but the dialog does not appear.

All objects that are under that heading (which are 4 objects) do not display menus now.

Ambiance Peaks East, 32, 9, 22. The orb might not be working but we do have a man eating tiger in the garden.

(1) Normal operation
(2) Name in the title changes to (?) (?) <-- That is actually 3 question marks inside each set of parenthesis
(3) Name in the title changes to null (blank)
(4) Menus from deeded object stops working altogether

This sequence happened to me yesterday, and this morning I got no menus at all. I was planning on restarting the sim to fix it. HOWEVER, before I got around to restarting, I needed to deed a different object. The instant I deeded it, the missing menus from earlier in the day popped up, from the objects that would not give me menus earlier. It had stored them - I got one menu for each click I had done earlier.

I went to those objects and now they gave me menus, albeit with the missing name in the title.

So if you need to get your menus from deeded objects back, try deeding another object before you restart the sim.

A sim restart fixed the problem

I am having an issue with my visitor trackers located around my sim failing to respond when I touch them. In fact the main script that sends the visitor info to the logging script stops responding all together. I have to reset the main script so it will starts logging visitor data again. Which means I have recorded no data from the time it stopped responding to whenever I reset it.

I do find it odd that there are no errors displayed in the debug channel at all. I have litterly parked myself next to one of the sensors from the time I reset it to a point at which it stopped responding.

You are at 293504.4, 286336.0, 45.6 in Cardew located at sim2249.agni.lindenlab.com (216.82.16.254:13001)
Second Life Server 1.25.6.113484

Sim: Yooseul

Objects: Security Orb, Teleport system.

I hope this little quirk helps to identify the underlying cause.

default{
state_entry(){
}

touch_start(integer total_number){ llDialog(llDetectedKey(0),"Test Message",["HIT ME"],0); }
}

After considerable experimenting, I've narrowed it down to the following condition:-
llDIalog() fails when the object containing the script is deeded to a group that also has land deeded to it and the object is located anywhere in the sim containing the deeded land.

========================================================================
Second Life 1.22.11 (113941) Mar 6 2009 12:50:02 (Second Life Release)
Release Notes

You are at 260235.8, 230307.3, 33.1 in Whanganui located at sim2875.agni.lindenlab.com (216.82.19.118:13002)
Second Life Server 1.26.2.117266
Release Notes

CPU: Intel Core 2 Series Processor (2000 MHz)
Memory: 3072 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8600 GT/PCI/SSE2
OpenGL Version: 2.1.2

1. Associate a Group to the Parcel. (The parcel does not need to be deeded to the Group.)
2. Create a cube.
3. Create a script in the Prim with the following code:

default
{
   touch_start(integer detected)
   {
      //This is to make sure that the llDetectedKey() function is...
      //...retrieving the correct key for the avatar touching the object.
      llSay(0, llKey2Name(llGetDetectedKey(0)));
      //This is the actual function being tested.
      llDialog(llDetectedKey(0), "Test Dialog Message", ["Option 1", "Option 2"], 0);
   }
}

4. Copy the Object and script. (Keep one copy for comparison purposes.)
5. Deed one of the Objects to the same group associated with the parcel.
6. Touch the undeeded Object and you will see your name in the chat and a dialog menu appear. (This is just to test and show that the llDialog() function in the script works on the undeeded Object.)
7. Touch the deeded Object and you should see one's name in the chat window and receive a dialog menu. The error is when the dialog menu does not appear.

This issue is not consistently reproducable: it happens for different periods of time on a region. Sometimes it will be reproducable for a couple of hours, then suddenly start working and spams the user with all of the attempted dialog menus from the previous failed attempts.

I have the line with the llSay() function to show that the llDialog function is receiving the correct key from the llDetectedKey() function, so that leaves only the llDialog() function failing. Since the Dialog menus will all come in a spam at the user once the user triggers the function during the region's "working" period, I suspect the dialog menus are being backed up in an event queue on the region for some reason.

An identical undeeded object right beside it works every time.

You are at 180917.8, 243381.2, 27.2 in Sarahs Island located at sim994.agni.lindenlab.com (216.82.13.144:13000)
Second Life Server 1.26.3.118673
Release Notes

CPU: Intel Core 2 Series Processor (2660 MHz)
Memory: 2558 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GTX/PCI/SSE2
OpenGL Version: 2.1.1

libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.23948 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 6334/4225568 (0.1%)

I've seen this on Outreach, Teaching, Teaching 2, and Eduisland