Objects refuse to shift-drag-copy, refuse to delete...

[Iain McCracken]

I have a problem with objects failing to delete, no allowing me to copy using shift-drag, failing to run scripts, failing to even admit that there's a script in the prim.

Objects seem to behave normally, except for one script I wrote which corrupts them somehow. I put the script in, and it fails to run. I click the "reset" button on the edit pane and get an error telling me there is no script in the object.

I try to shift-drag in edit and get no new prim. I put a llOwnerSay in the state_entry handler and get a message every time, indicating that a new prim is being created and the script is being run in the new prim, but there's no prim left behind as there should be when you shift-drag.

I created another prim and dropped the same script into it, and tried to link the two prims. They refused to link.

Now one of them can't even be deleted.

This takes one of my designs for a project and flushes it down the toilet. But it also raises concerns that I might get this freaky behavior any time I write a script.

Here's the simplest variant of the script that corrupts prims like this:

vector color = < 1.0, 1.0, 0.5>;
float prob = 0.3;
integer on = FALSE;


turnon() {
llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_COLOR, ALL_SIDES, color, 1.0,
PRIM_POINT_LIGHT, TRUE, color, 5.0, 0.5, 1.0,
PRIM_FULLBRIGHT, TRUE]);
on = TRUE;
}

turnoff() {
llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_COLOR, ALL_SIDES, <0.5, 0.5, 0.5>, 1.0,
PRIM_POINT_LIGHT, FALSE, color, 1.0, 0.5, 0.5,
PRIM_FULLBRIGHT, FALSE]);
on = FALSE;
}

default {
state_entry() {
llOwnerSay("about to reset");
turnon();
llOwnerSay("done reset");
}

link_message(integer sender, integer num, string msg, key id) {
float blah = llFrand(1.0);
if (blah > prob) {
if (on) {
turnoff();
} else {
turnon();
}
}
}
}


The turnon() routine apparently does nothing, which is nonsensical as it works fine in another script.

I just logged back in and found a bunch of other prims I'd deleted come back from the dead, and the undeletable prim has its parameters changed as if the turnon() routine ran while I was logged off. WTF?

The prims that came back from the dead and the undeletable prim allowed me to delete them, but what guarantee do I have that they'll STAY deleted -- they've already come back from the dead once today.

Can anyone tell me what in that script is causing the sim to fail so badly? I have an almost identical script that runs perfectly. Prims can be shift-dragged to copy, they change parameters correctly, they can be rezzed and deleted when I want, etc.

[Iain McCracken]

Okay, now I'm really frustrated. I just cleared cache and relogged -- and objects that I had left there have VANISHED.

I'm getting very concerned about Kitely's stability.

PS, I tried creating a prim, dropping that script in, and taking the prim. No go. I just get an hourglass. No object in inventory.

I'll have to tell my boss Selby I can't do my job. Sigh.

[Ilan Tochner]

Hi Iain,

What world are you doing this all in? Is it in a sandbox or your own world?

What viewer are you using? (and version)

Have you tried this with other viewers as well?

[Ilan Tochner]

I suggest you create a new script (not by duplicating an existing script) then copy/paste the script code into that script. Then place that script in a newly created cube and report what happens when you try to manipulate it in all the ways you stated.

[Iain McCracken]

Here's my viewer info

Firestorm 4.6.1 (40478) Mar 10 2014 05:38:17 (Firestorm-Releasex64) with OpenSimulator support
Release Notes

You are at 17.5, 212.9, 24.0 in Flying Saucers set located at ec2-54-219-76-172.us-west-1.compute.amazonaws.com (54.219.76.172:9032)
SLURL: hop://grid.kitely.com:8002/Flying%20Saucers%20set/17/213/24
(global coordinates 2,461,710.0, 2,066,640.0, 24.0)
OpenSim 0.7.6.1 Post_Fixes (Unix/Mono)
Error fetching server release notes URL.

CPU: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz (2594.11 MHz)
Memory: 8070 MB
OS Version: Microsoft Windows 8.1 64-bit (Build 9600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GT 635M/PCIe/SSE2

Windows Graphics Driver Version: 10.18.0010.3308
OpenGL Version: 4.3.0

RestrainedLove API: RLV v2.8.0 / RLVa v1.4.10a
libcurl Version: libcurl/7.24.0 OpenSSL/1.0.1e zlib/1.2.6 c-ares/1.10.0
J2C Decoder Version: KDU v7.3.2
Audio Driver Version: FMOD Ex 4.44.26
Qt Webkit Version: 4.7.1 (version number hard-coded)
Voice Server Version: Vivox 4.5.0009.17865

Settings mode: Firestorm
Viewer Skin: Firestorm (Grey)
Font Used: Deja Vu (96)
Draw distance: 376
Bandwidth: 500
LOD factor: 2
Render quality: Medium-High (4/7)
Texture memory: 512 MB (1)
Built with MSVC version 1600
Packets Lost: 16/9,768 (0.2%)


Just TPd to another world and back, and one of the mysteriously vanished objects has mysteriously reappeared.

Tried to c&p the script contents into a fresh script, and get the same results. No shift-drag, can't take the object, prim parameters refused to change under script control.

Also, the other script that was working with the turnon and turnoff functions is now not working.

I'll try the 32-bit Firestorm. Any other suggestions for viewers to try if that one also doesn't solve the problem?

[Ilan Tochner]

When experiencing intermittently vanishing items it's usually a view inventory cache problem. Clearing the cache via the viewer doesn't clear that. I suggest uninstalling the viewer and installing the version we provide here: http://www.kitely.com/file?type=viewer

[Iain McCracken]

I found the problem!

The script has a bug in it where it was attempting to set the point light intensity to 5. I have verified by fixing the faulty script in a corrupted prim (and the corrupted prim suddenly starts behaving properly), as well as by putting the corrected script into a fresh prim, then edit the bug back into it and the prim gets corrupted.

So... It looks like the llSetPrimitiveParams family of functions don't do argument checking, and somehow setting the prim point light intensity parameter to a value > 1 causes the prim to get weird.

At least I'm back on track again.

[Ilan Tochner]

Thank you for the update Iain.

[Handy Low]

Thanks for this information, Iain. It was indeed a problem with range-checking: the invalid intensity value caused problems in almost any operation having to do with the prim. I have now added the missing range checks.