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

[BUG-5533] llTeleportAgent() and llTeleportAgentGlobalCoords() can break any script in any attached object that contains a change event. #13502

Closed
1 task
sl-service-account opened this issue Jul 31, 2012 · 40 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Jul 31, 2012

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
Field Value
Issue BUG-5533
Summary llTeleportAgent() and llTeleportAgentGlobalCoords() can break any script in any attached object that contains a change event.
Type Bug
Priority Unset
Status Closed
Resolution Duplicate
Reporter Lucia Nightfire (lucia.nightfire)
Assignee WorkingOnIt Linden (workingonit.linden)
Created at 2012-07-31T14:09:30Z
Updated at 2014-04-16T21:50:43Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2012-07-31T12:03:09.020-0500',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': '.',
  'What were you doing when it happened?': '.',
  'What were you expecting to happen instead?': '.',
}
@sl-service-account
Copy link
Author

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:
change & CHANGED_COLOR
change & CHANGED_INVENTORY
change & CHANGED_REGION

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.
Scripts in root prims also seem to require the presence of additional inventory (objects, scripts, etc).
Scripts don't have to explicitly have the change type occur when they break and don't always immediately break after teleport as the error can be delayed.
Only seem to be able to trigger this with intra-sim teleporting.

@sl-service-account
Copy link
Author

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.
On intra-sim teleport, breakage occurs

Intersting facts:
The scripts will not break again when reset in the LeTigre region manually.
The scripts will break on the second intra-sim TP, judging from my observations, not the first.
The breaking script contained a CHANGED_REGION check in the changed event, as Lucia described above.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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:

  1. Rez a box and create this simple teleport script in it:
key  teleportee;
 
default
{
    state_entry()
    {
        llSetText( "Touch to teleport", <1,1,1>, 0);
    }
 
    touch_start(integer total_num)
    {
        teleportee = llDetectedKey(0);
        llRequestPermissions(teleportee, PERMISSION_TELEPORT);
    }
 
    run_time_permissions(integer perm)
    {
        if(PERMISSION_TELEPORT & perm)
        {
            llTeleportAgent(teleportee, "", llGetPos()+<0,0,10>, <13.0, 12.0, 23.5>);
        }
    }
}
  1. Wear the teleporter box on your left hand
  2. Rez a box and create this script in it:
integer counter;
default
{
    state_entry()
    {
        llSay(0, "changed test script");
    }
    
    changed(integer change)
    {
        llSay(0, "Changed: " + (string)change);
    }

    touch_start(integer total_number)
    {
        llSay(0, "Touched this many times: " + (string)(++counter));
    }
}
  1. Wear this new script on your right hand
  2. Touch the right hand box a few times, and verify that the touch event works properly, and that the counter increments.
  3. Touch the left hand box and accept the TP permissions. It will TP your avatar 10m above his current position.
  4. Note whether changed event occurs in the right hand box, and what change was detected
  5. Touch the right hand box a few times, and verify that the touch event still works properly
  6. Repeat steps 6-8 a few times, and look for breakage

In my testing, the script with the changed event never broke:

  • Each time after the left hand attachment teleported me, CHANGED_TELEPORT = 512 triggered in the right hand attachment, as expected

  • The touch event in the right hand script continued to work, with an ever-increasing counter, as expected

  • I also tried adding an object to the right hand attachment's inventory, per Lucia's comment. This did not help

  • After a few rounds of testing, I changed the color of my attachment, and found that CHANGED_COLOR = 2 triggered correctly

  • When I was done testing, I manually TPed to another region via the world map. When this happened, the right hand attachment triggered CHANGED_TELEPORT|CHANGED_REGION = 768, which is correct.

    Do you have a simple recipe to trigger this bug?

@sl-service-account
Copy link
Author

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...
changed(integer a)
{
if(a & (CHANGED_INVENTORY | CHANGED_ALLOWED_DROP))
{
if(llGetInventoryNumber(INVENTORY_LANDMARK))
{
current = 0;
request = llRequestInventoryData(name = llGetInventoryName(INVENTORY_LANDMARK,0));
}
}
}

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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:

  1. Create a cube in a non-letigre/magnum region
  2. Create a script in it
  3. Use this as the script code:
<PENDING>
  1. attach the cube.
  2. TP to a LeTigre/Magnum region
  3. Create a cube
  4. Create a script in the cube
  5. Use this as the script code:
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()));
    }
}
  1. Save, attach the cube, accept the TP permissions
  2. click the new cube attachment to get a random TP somewhere into the same sim

Observe crashing first cube script after one, two TPs.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2012-08-01T15:03:10Z

Now happening on Magnum 12.07.31.262785

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

Maestro Linden commented at 2012-08-01T17:45:57Z

Now happening on Magnum 12.07.31.262785
This makes sense since Magnum 12.07.31.262785 should be identical to Second Life Server 12.07.24.262437 with respect to llTeleportAgent(). In the previous version of Magnum, llTeleportAgent() was disabled and would fail silently when called.

@sl-service-account
Copy link
Author

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!

@sl-service-account
Copy link
Author

Daemonika Nightfire commented at 2012-08-11T04:25:31Z

I have the same Problem.
Ever when i teleport with llTeleportAgentGlobalCoords are breake a Script from other Attachments.
For me it looks that there is a permission problem, each script what breake uses granded permission.
Scripts with Permission vor animate the Avatar and Scripts which take Controls are breaking.
Other Scripts without any permissions i have not see.

sincerely yours
Dae

@sl-service-account
Copy link
Author

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
Unable to load script state.", triggering llTeleportAgent without a landmark, so only inter region teleport, and does not always seem to happen.

Currently only tested in: Second Life RC PF 12.07.31.262785

@sl-service-account
Copy link
Author

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.
i edited the script to :

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.
when i detach the meter and reattach it shows the dialog that is in the tp script as above and works again till next tp touch.
So the dialog from the tp script shows for the wrong attachment after reattach.

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.
I tried controls and timer (which is in both AO and combat meter)

@sl-service-account
Copy link
Author

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.
I changed Maestro's touch test script to :

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.
The dialog of the tp script is not shown until the touch object is detached and reattached and it is presented as a dialog for the WRONG object .. it says it is a dialog for the touch object.

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)

@sl-service-account
Copy link
Author

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?

@sl-service-account
Copy link
Author

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...

@sl-service-account
Copy link
Author

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
Unable to load script state."

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

@sl-service-account
Copy link
Author

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
and I assure you I didn't name my cube that. The TP script is in a cube named "TP item" as shown here: http://home.comcast.net/~volfin/20120821004717215.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().
[script:Lara's Animator] event handlers: changed(), attach(), link_message()
[script:Dari's RLV Relay] event handlers: state_entry(), on_rez(),changed(), listen(), link_message(), timer()
[script:Lara's Detacher] event handlers: state_entry(), changed(), attach(), link_message()

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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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:
Second Life RC LeTigre 12.08.13.263365
Second Life Server 12.08.06.263130
Second Life RC Magnum 12.08.14.263480
Second Life RC BlueSteel 12.08.13.263365

@sl-service-account
Copy link
Author

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
Unable to load script state.
SCR-382 test initator [script:Trigger 7] Script run-time error
Unable to load script state.
SCR-382 test initator [script:Trigger 1] Script run-time error
Unable to load script state.
[ITEM RESET after no more would crash]

SCR-382 test initator [script:Trigger 3] Script run-time error
Unable to load script state.
SCR-382 test initator [script:Trigger 7] Script run-time error
Unable to load script state.
SCR-382 test initator [script:Trigger 1] Script run-time error
Unable to load script state.
[ITEM RESET after no more would crash]

SCR-382 test initator [script:Trigger 3] Script run-time error
Unable to load script state.
SCR-382 test initator [script:Trigger 7] Script run-time error
Unable to load script state.
SCR-382 test initator [script:Trigger 1] Script run-time error
Unable to load script state.
[ITEM RESET after no more would crash]

....

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

Daemonika Nightfire commented at 2012-09-03T08:07:33Z

@ Maestro

What do you think about a self-AR when the Error appears again?
That mean, when i Teleport with the new commands and get this Error, i report meself so you can check the logs.

This bug is realy bad, because i can reproduce it.

[01:00:54] You have been teleported by an attachment on daemonika.nightfire
[01:00:54] DS TP-HUD 2.04: DS TP-HUD 2.04 [script:DS TPH_Radar v3.0.09] Script run-time error
[01:00:54] DS TP-HUD 2.04: Unable to load script state.
[01:00:54] Daemonika Nightfire's DS TP-HUD 2.04: DS TP-HUD 2.04 [script:DS TPH_Radar v3.0.09] Script run-time error
[01:00:54] Daemonika Nightfire's DS TP-HUD 2.04: Unable to load script state.

Today it breakes a script inside the same Attachment where is the Script with that i teleport.
The Radar uses the PERMISSION_TRACK_CAMERA for a Compass.

Again, for me it looks that there ever breake Scripts with any permissions.

sincerely yours
Dae

@sl-service-account
Copy link
Author

Moo Spyker commented at 2012-11-02T02:01:10Z

Any new info on this...? Its still very broken...

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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 ..
So yes . .still a bug but with a good workaround.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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 ?

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

Alexa Linden commented at 2014-03-27T00:22:08Z

Darien, Thanks for the repro steps... I've also imported them.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

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