[BUG-5533] llTeleportAgent() and llTeleportAgentGlobalCoords() can break any script in any attached object that contains a change event. #13502
Comments
Lucia Nightfire commented at 2012-07-31T14:14:12Z, updated at 2012-07-31T16:32:38Z Everytime I use llTeleportAgent() and llTeleportAgentGlobalCoords() whether called from an attachment or a rezzed object any script in my attachments that has a change event risks breaking with the following error: Unable to load script state. This broke scripts using change events that check: I just had half my HUDs break because of it. This happens on all sim channels using version 12.07.24.262437, including main channel where it is the first time I experienced this issue after the teleport functions were activated. I have not had this issue with these functions doing this until today's rolls on main channel. Now its doing it on all regions running version 12.07.24.262437. Please investigate ASAP. Thanks. Latest Info: Can't seem to get scripts with change events in child prims to break. |
Chalice Yao commented at 2012-07-31T17:03:09Z I can verify the behavior, tested in the sandbox 'LeTigre Sandbox 3'. On inter-sim teleports, the scripts of other attachments show no bad behavior. Intersting facts: |
PcTek Cyberstar commented at 2012-07-31T17:45:03Z I am experiencing this same exact problem. In different huds using the llteleportagent causes other scripts in the hud to randomly break. I would not have known if i had not been wearing the watchguard script which tells me when scripts have broken or stopped (it monitors them). There may be a huge impending doom problem here about to be uncovered with this issue. |
Maestro Linden commented at 2012-07-31T18:52:13Z Hi guys, I've tried this out but can't reproduce the issue yet, in Second Life Server 12.07.24.262437. Here's what I tried:
In my testing, the script with the changed event never broke:
|
PcTek Cyberstar commented at 2012-07-31T19:03:44Z I noticed something else strange some of the scripts it broke in my attachment do not contain a changed_region event, just a changed event period. One of my scripts contained this and it broke this script... |
Chalice Yao commented at 2012-07-31T19:04:06Z, updated at 2012-07-31T19:04:26Z Maestro, remember to save and start the script that contains the CHANGED_REGION event in a sim that is not on the letigre/Magnum sim version. Create it on a normal main channel region, save, attach. Then TP to the Letigre region where the teleport functions are enabled, put your teleport object together and test then, without touching the already created object containing the script with the CHANGED_REGION check. I am sure it will trigger that way, since, as I observed, once the crashed script gets reset in the LeTigre sim, it will never crash again. Hence I suspect scripts saved or reset in the LeTigre region will never be usable to reproduce the issue. |
PcTek Cyberstar commented at 2012-07-31T19:37:47Z, updated at 2012-07-31T20:02:15Z I have an attachment. The attachment contains 10 scripts, various objects such as landmarks, notecards, actual objects. One of the 10 scripts was a teleport script. I switched it from rezzing an object to sit on to teleport - to use the new llTeleportAgent. Then whenever I teleported the other scripts would randomly crash, but not the script containing llTeleportAgent. I moved the llTeleportAgent script to an empty prim on the attachment object, and it no longer crashes the other scripts. |
Chalice Yao commented at 2012-07-31T20:22:12Z, updated at 2012-07-31T20:33:09Z I found a simple way to reproduce the bug:
<PENDING>
default
{
attach(key foo)
{
llSetTimerEvent(0);
if(llGetAttached())
llRequestPermissions(llGetOwner(),PERMISSION_TELEPORT);
}
touch_start(integer foo)
{
if(llGetAttached())
if(llDetectedKey(0) == llGetOwner())
llTeleportAgent(llGetOwner(),"",<llFrand(255),llFrand(255),llFrand(100)>,llRot2Euler(llGetRot()));
}
}
Observe crashing first cube script after one, two TPs. |
Maestro Linden commented at 2012-07-31T20:33:30Z Chalice, why should we avoid LeTigre/Magnum specifically, when testing? LeTigre, BlueSteel, and Second Life Server all currently run the same simulator version (12.07.24.262437), which has the new functions enabled by default. Magnum 12.07.25.262546 mostly has the same code regarding llTeleportAgent(), llTeleportAgentGlobalCoords(), and llAttachToAvatarTemp(), but it has a configuration option set to disable these functions. My original testing was limited to a Second Life Server 12.07.24.262437 region, since the bug was reported against this specific version. I repeated the tests in Second Life RC BlueSteel 12.07.24.262437 just now, but unsurprisingly, I see the same behavior as in the other region. I also recompiled the scripts as LSO and repeated the tests, but this also didn't trigger a failure. |
Chalice Yao commented at 2012-07-31T20:33:55Z, updated at 2012-07-31T20:34:30Z Ignore my last comment, I didn't notice that it was another script that was crashing, instead of the one I had prepared for the test. Oh the irony. The other script is a little too long and too complex to really pinpoint the bug tho. I will try to pinpoint the cause and update my last post with the code. |
Darien Caldwell commented at 2012-07-31T23:39:47Z This issue was already reported 6 months ago: https://jira.secondlife.com/browse/SVC-7521 Since LL seems to actually be paying attention here, i'll link that as related. ;p |
Maestro Linden commented at 2012-08-01T01:10:29Z Yes, this is probably the same issue as SVC-7521. The trouble with that report was that nobody was ever able to provide the full steps to reproduce the bug, including script source. I'll try Chalice's steps as soon as her (3) is filled out. |
Lucia Nightfire commented at 2012-08-01T12:25:13Z, updated at 2012-08-01T15:57:02Z Okay, day 2 testing observations: Only seems to break Mono scripts. Mono teleport scripts seem to be the only ones that can break attachments. Still can't seem to break scripts in child prims. Can't seem to easily break scripts compiled/saved on sim versions 12.07.24.262437 & 12.07.31.262785. Test on older Mono scripted stuff instead. I cannot break my attachments with a teleport script created by someone else. (Object creator, object/inventory perm mask does not matter) If I include a "return;" immediately after any teleport function it will not break my attachments. Any additional code after the teleport function, whether handled or not, increases the chance of breaking my attachments. I tested with a while loop that executes 10x or 100x or 1000x, showing the cycle in settext immediately after the teleport function. When an attachment is about to break, there will be a stop in the settext updating, but the code still completes. I still get teleported and there is a 1 - 5 second pause before the script error occurs. If it doesn't occur, clicking the teleport object again will break an attachment. I can't seem to break more than one attachment at a time. |
Lucia Nightfire commented at 2012-08-01T15:03:10Z Now happening on Magnum 12.07.31.262785 |
Ariu Arai commented at 2012-08-01T16:21:20Z, updated at 2012-08-01T16:37:42Z I've confirmed what Lucia stated in her previous comment. Adding a loop after the llTeleportAgent function does increase the chances of crashing other attached scripts. So far it doesn't seem to matter what the affected scripts do in the changed event. Most of the scripts that crashed in my HUD do absolutely nothing but an if/else. What the script is doing at the time of the teleport is more than likely what's causing the crash. I'm testing some possible repro's. I have 11 scripts, 10 of them change the floating text on touch, change and a 1 second timer. The other script will teleport you on touch and wait 15 seconds in a loop. When it successfully reproduces the bug ( My Phenom Evolution HUD seems to be the only HUD affected so far ), the execution of the touch-teleport script will cease. I'll post the scripts once I have more time to play with it and isolate the exact cause. |
Maestro Linden commented at 2012-08-01T17:45:57Z
|
Moy Loon commented at 2012-08-05T09:28:23Z Happens to me on Second Life Server 12.07.24.262437 Video: http://youtu.be/Kb-SFVNwqTw Whenever objects teleport my avatar, my AO breaks every time, forcing me to unpack and setup a fresh copy, the script breaks every time! |
Daemonika Nightfire commented at 2012-08-11T04:25:31Z I have the same Problem. sincerely yours |
Jasdac Stockholm commented at 2012-08-17T12:27:26Z This happens for me too, without the script needing a changed event. "Script run-time error Currently only tested in: Second Life RC PF 12.07.31.262785 |
Si Shinn commented at 2012-08-17T21:51:35Z, updated at 2012-08-18T06:55:48Z This issue is reproducable for me in : Second Life Server 12.08.06.263130 As Lucia suggested to put a return after the llTeleportAgent() and uncheck the mono flag it seems to avoid crashing the combat meter and the AO. Maestro's test tp script did not trigger the bug. key teleportee;
integer has_perm=FALSE;
do_tp()
{
llTeleportAgent(teleportee, "", llGetPos()+<0,0,10>, <13.0, 12.0, 23.5>);
llDialog(llGetOwner(),"This is a dialog",["OK","No"],0);
}
default
{
state_entry()
{
llSetText( "Touch to teleport", <1,1,1>, 0);
}
touch_start(integer total_num)
{
teleportee = llDetectedKey(0);
if (has_perm) do_tp();
else llRequestPermissions(teleportee, PERMISSION_TELEPORT);
}
run_time_permissions(integer perm)
{
if(PERMISSION_TELEPORT & perm)
{ do_tp();
has_perm=TRUE;
}
}
} With this change (in mono) it breaks the combat meter every tp. The meter used is SPD-J Health 1.6. It is a freely distributable so if anyone likes to reproduce this. send me an IM in world and i give you the meter. I tried to change the touch counter script to show the bug too, but could not find the needed addition. |
Si Shinn commented at 2012-08-18T06:54:10Z Tested in : Second Life RC BlueSteel 12.08.13.263365 It seems that more than one event handler is involved. integer counter;
integer i;
default
{
state_entry()
{
llSay(0, "changed test script");
llSetTimerEvent(1.0);
llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION | PERMISSION_TAKE_CONTROLS);
llListen(1,"",NULL_KEY,"");
}
changed(integer change)
{
llSay(0, "Changed: " + (string)change);
}
touch_start(integer total_number)
{
llSay(0, "Touched this many times: " + (string)(++counter));
}
timer() {
i++;
}
control(key id, integer level, integer edge)
{
if(level & CONTROL_FWD && edge & CONTROL_FWD)
{
llSay(0,"Fwd");
}
}
run_time_permissions(integer perm)
{
if (perm) llTakeControls(CONTROL_FWD , TRUE, FALSE);
}
listen(integer _chan,string _name,key _key,string _msg)
{
llSay(0,"Received from " + _name + " message " + _msg);
}
} With this code in the touch object it breaks every time for me. If i test this in : Second Life Server 12.08.06.263130 the bug still does not show up (with combat meter the bug still shows) |
Maestro Linden commented at 2012-08-20T22:22:39Z Hm, I tried out Si's 2 new scripts (one for teleporting, one for the other attachment which breaks), and I'm not seeing breakage (or incorrect dialog labels) in my Second Life Server 12.08.06.263130 test region. Both llTeleportAgent() and the other object's event handlers trigger correctly for me. The 'touch object' script does stop grabbing my controls when I detach and reattach it, but I think this only happens because the script doesn't call llTakeControls() upon attach/rez; the touch_start and change events continue to trigger after teleporting a few times, reattaching, and teleporting a few more times. The wrong object name in the llDialog() prompt is strange, but it's not happening for me. Could it be that you renamed the attachment from "touch object" to "TP object" via the build tool while it was attached, then reattached the object from there? If the name of the object was 'touch object' in your inventory, this would cause the object name to change upon reattach, and cause a confusing dialog label to appear. Otherwise, I'm not sure what would trigger this behavior; I'm wearing the TP box on my left hand and the touch box on the right hand; perhaps there's a bug with dialog prompts if you have 2 objects on the same attachment point? |
Rian Jayaram commented at 2012-08-20T23:17:15Z i am still getting script errors in other HUDs when i use the llTeleportAgentGlobalCoords in a HUD. It tends to be a different script each time... |
Darien Caldwell commented at 2012-08-21T00:34:06Z, updated at 2012-08-21T00:36:50Z I decided to try the two scripts Sin made as well, since nobody can seem to come to a consensus on this. I created new, fresh prims and put a script in each. I then attached both to my right hand. (same attach point). First time teleporting, nothing happened. Second time teleporting, my collar broke. (it's attached to the Spine, if that matters) "SiniStyle Posture Collar - Spikes(S) (spine) [script:Lara's Messager] Script run-time error I have the source to the script that broke, it has the following 4 event handlers: changed(), listen() link_message(), and timer(). It was compiled to mono about 2-3 years ago and has about 30k free. One of the prevailing theories is that this crashing only happens with scripts compiled before a recent server releases, so this would seem to back that up. I'll do some other experiments and see what I can observe. This was in Second Life RC LeTigre 12.08.13.263365 |
Darien Caldwell commented at 2012-08-21T01:01:10Z 15 tries, 15 breakages. I can pretty much guarantee it will break every second TP. I only now see what Sin meant about the dialog, I didn't even realize the TP script had a dialog in it, the dialog never appears! Never, until you detach and re-wear a broken item that is. Then it appears, with the broken item's name. If you reset the script before detaching/reattaching, the dialog never displays. Dialog stating its from my collar: http://home.comcast.net/~volfin/2012082100462372.jpeg Now, as for what is breaking, it's seemingly random scripts in the collar. but there are some commonalities: [script:Lara's Messager] event handlers: changed(), listen() link_message(), and timer(). changed() and link_message() seem common to all. Now that I can create the issue with 100% certainty, I will test the "compile theory" and recompile a coppy of this collar on the latest server, and see if it still happens. |
Darien Caldwell commented at 2012-08-21T01:50:19Z Ok recompiling did not in fact eliminate the issue. So much for that theory. I can still crash this at will. The item is around 25 scripts, I have reduced it down to a cluster of 3 scripts. I am now further reducing it down by trial and error until I can provide a crashable test case. |
Darien Caldwell commented at 2012-08-21T02:42:54Z, updated at 2012-08-21T03:19:08Z I've boiled it down to two scripts. It seems one script sets up the condtion, and the other script receives the error. Either script on it's own does nothing when being TPed. So to make things clear, I'll go from the start. First: use Sin's TP script in one attachment: key teleportee;
integer has_perm=FALSE;
do_tp()
{
llTeleportAgent(teleportee, "", llGetPos()+<0,0,10>, <13.0, 12.0, 23.5>);
llDialog(llGetOwner(),"This is a dialog",["OK","No"],0);
}
default
{
state_entry()
{
llSetText( "Touch to teleport", <1,1,1>, 0);
}
touch_start(integer total_num)
{
teleportee = llDetectedKey(0);
if (has_perm) do_tp();
else llRequestPermissions(teleportee, PERMISSION_TELEPORT);
}
run_time_permissions(integer perm)
{
if(PERMISSION_TELEPORT & perm)
{ do_tp();
has_perm=TRUE;
}
}
} In the second attachment, place these two (or more) scripts. I will call one the Initiator (sets up the condtion) and one the trigger (errors under the condition). If you have multiple triggers, A) you're more likely to see an error, and B) the error will randomly occur in one of the triggers. Initiator: key null_key =NULL_KEY;
key Owner;
initialize()
{
// busy work
integer i;
i++;
}
default {
state_entry() {
Owner=llGetOwner();
if ( llGetAttached() )
llRequestPermissions( Owner, PERMISSION_TRIGGER_ANIMATION|PERMISSION_TAKE_CONTROLS );
}
on_rez( integer _code )
{
initialize();
}
attach( key _k )
{
if ( _k != null_key )
{
Owner=_k; // change owner in case of ownership change.
llRequestPermissions( Owner, PERMISSION_TRIGGER_ANIMATION|PERMISSION_TAKE_CONTROLS );
}
}
run_time_permissions( integer _perm )
{
if ( _perm == (PERMISSION_TRIGGER_ANIMATION|PERMISSION_TAKE_CONTROLS) )
{
llOwnerSay("Trying to Take Controls. Should only be called when requesting Permission");
llTakeControls( CONTROL_BACK|CONTROL_FWD, TRUE, TRUE );
}
}
link_message( integer _sender, integer _num, string _message, key _id)
{
// busy work
integer i;
i++;
}
listen( integer channel, string name, key id, string message) {
// busy work
integer i;
i++;
}
} Trigger: key owner;
// ==================
do_null()
{
integer i;
i++;
i--;
}
// ==================
default
{
state_entry()
{
owner=llGetOwner();
}
changed(integer change)
{
if (change & CHANGED_OWNER) { // and it was a link change
owner=llGetOwner();
}
}
attach(key attached)
{
// If wearer detached their item,
if (attached == NULL_KEY)
{
if (TRUE)
{
integer i;
for (i = 0; i < 4; i++)
do_null();
}
}
else
{ // on attach
do_null();
}
}
link_message(integer sender_num, integer num, string variable, key value)
{
if (variable=="A")
{
do_null();
}
else if (variable=="B")
{
do_null();
}
else if (variable=="C")
{
do_null();
}
else if (variable=="D")
{
do_null();
}
else if (variable=="E")
{
do_null();
}
else if (variable=="F")
{
do_null();
}
}
} With only one trigger, it may take anywhere from 3 to 10 TPs for it to occur, with 3 or more triggers, it's almost always on the second TP. So try different # of trigger scripts. Use the TP script to TP, you will get an indicator when the crash will occur, the Dialog will not appear. When the dialog doesn't appear, the next TP will cause a crash in a trigger script 100% of the time. After the crash, take off the Initiator/Trigger attachment, and reattach. The missing dialog (or dialogs, if you crashed it multiple times in a row) will then appear, but showing as coming from the Initiator/Trigger attachment, and not the TP attachment from which it actually originated. Tested as crashing in the following servers: |
Darien Caldwell commented at 2012-08-21T05:50:39Z, updated at 2012-08-21T05:51:01Z Lucia was kind enough to try out this reproduction, and initially it wouldn't repro for her. So we examined all the variables, and determined what sim the scripts are compiled in seems to be a factor. She compiled her testbed in Region: LeTigre Sandbox 3, Sim Channel: Second Life RC LeTigre, Version: 12.08.13.263365, and the script crashes didn't happen. My Testbed with the same scripts (as above) always crashed, but was compiled in Region: Borgbeef, Sim Channel: Second Life RC LeTigre 12.08.13.263365 We traded testbeds, and verified that she saw crashes with mine, and that I did not with hers. I recompiled her testbed in Borgbeef, and it then also exhibited the crashes. So it seems these scripts must be compiled in Borgbeef. O.o I do not know why that matters, but Lucia pointed out that maybe there are additional fixes in the RC sandboxes not 'turned on' here yet. Also: we noticed something of note: her testbed had 10 of the 'trigger' scripts included, Trigger thru Trigger 9. After repeated crashing, a pattern to the crashes emerged: Only a max of 3 of the triggers would crash, and always the same ones in the same order: SCR-382 test initator [script:Trigger 3] Script run-time error SCR-382 test initator [script:Trigger 3] Script run-time error SCR-382 test initator [script:Trigger 3] Script run-time error .... |
Cheshyr Pontchartrain commented at 2012-08-21T14:36:40Z, updated at 2012-08-22T00:20:17Z Excellent work on the repro and test cases, Darien. Let's hope Linden Lab pays attention this time. They've denied this bug exists for over a year, since it first appeared in the Linden Realms sims. Caleb, thank-you for reopening it. |
Darien Caldwell commented at 2012-08-22T20:39:51Z Figured I should check if Sim: Borgbeef still produces compiled scripts that exhibit this behaviour, now that it's been rolled to a new version. (Second Life RC LeTigre 12.08.17.263666) I'm happy (or sad, or both) to report that scripts compiled here still crash. So the Repro is still valid. |
Daemonika Nightfire commented at 2012-09-03T08:07:33Z @ Maestro What do you think about a self-AR when the Error appears again? This bug is realy bad, because i can reproduce it. [01:00:54] You have been teleported by an attachment on daemonika.nightfire Today it breakes a script inside the same Attachment where is the Script with that i teleport. Again, for me it looks that there ever breake Scripts with any permissions. sincerely yours |
Moo Spyker commented at 2012-11-02T02:01:10Z Any new info on this...? Its still very broken... |
Cheshyr Pontchartrain commented at 2012-11-02T03:41:18Z I've not heard anything, but yes, it's still broken and useless. I'm surprised we could comment though. Linden Lab closed the JIRA for new issues, as they dislike public commentary. But that said, shouldn't this issue be flagged a showstopper or at least critical? It damages content. |
Si Shinn commented at 2012-11-02T07:58:53Z The workaround with a return; statement directly after the llTeleportAgent() works in my scripts .. i have seen no strange happenings there and i use it combat settings with many players .. |
Lucia Nightfire commented at 2012-11-07T17:46:51Z Looked at this again and seeing breakage with LSO or Mono scripts with a return; after a tp function in a UDF. |
Rohacan Hirons commented at 2012-11-11T22:13:35Z, updated at 2012-11-12T22:52:03Z Hi, this is a showstopper for me too. I've tried the workaround and it seems to work for me but in all case it would be better to have this fixed Edit : After more tests the workaround did not changed anything. Please fix this LLabs. You're working on many new stuff, cool, but please fix first your current bugs before to create more bugs in new stuff.. no ? |
Alexa Linden commented at 2014-03-27T00:20:53Z Move this to BUG as the prior Jira Project Type was no longer active. This has already been imported internally and I've bumped the priority as it's still reproducible. |
Alexa Linden commented at 2014-03-27T00:22:08Z Darien, Thanks for the repro steps... I've also imported them. |
Cheshyr Pontchartrain commented at 2014-03-27T03:31:12Z, updated at 2014-03-27T03:31:40Z Thank you, Alexa. Hopefully this will get some TLC. I reported this issue 3 years ago or so, when Linden Lab started using the function (before releasing it to the public) in the Linden Realms sims. Crossing my fingers for a quick fix. |
Maestro Linden commented at 2014-03-27T15:38:47Z This BUG is in a bad state now (it shouldn't be 'awaiting review', as we've already imported it). I'll resolve it as a 'duplicate' of the issue from when we imported it, originally. |
llTeleportAgent() and llTeleportAgentGlobalCoords() breaks all scripts in other attached objects that use change events that check for CHANGED_REGION
Attachments
Links
Related
Original Jira Fields
The text was updated successfully, but these errors were encountered: