Bug report: Locked / unlocked scripts unreadable

[Snoots Dwagon]

I've noticed a consistent possible-bug in my work that I'm wondering if someone can verify.

Create an object. Place a script in it. Lock the item.

Relog. Unlock the item. Try to edit the script.

I am finding the script is unreadable, in every tested case without exception.

The only way I've been able to "fix" this issue is to shift-copy the item and delete the original. The duplicate will then have a readable script.

This appears to me to be an actual bug.

Thanks.

[Ada Radius]

There are a couple of other situations where scripts stop working or are unreadable. I'm not a scripter, didn't look into it. Shift-copy the item - the one that moves is actually the original, I think - and delete the one that looks like the original, is such an automatic response on my part that I barely register I'm doing it.

[Iain McCracken]

Another pair of eyeballs confirms. Lock, relog, unlock, trying to open the script yields "Grid: Unable to load the script. Please try again."

The script is still running and functions properly even though the grid cannot load it.

When I shift-drag copied the prim, the script in both copies can be opened.

And confirming Ada's thought, the one that moves is the original, and the one left behind in the original spot is the new copied prim.

Edit: Grid can't load the text portion of the asset -- the bytecode must be loading (or loaded) because the script is running...

[Snoots Dwagon]

I confirm Iain's expanded experience. When relogging, unlocking and trying to read the script, I get the system message: "Unable to load the script. Please try again." However, the script still functions.

Then as Iain states,when the shift-drag is done, BOTH object scripts become visible.

As Ada and Iain both mention (and has been long known by builders) when one shift-drags an object, rather than the original remaining in place and the shifted item being the copy (as would be intuitive), is is the opposite: the copy remains in place and the object that is shift-dragged is the original. This isn't a problem if one is aware of that fact. For new builders it can be counter-intuitive and confusing.

This issue of the script initially not being accessible strikes me oddly similar to avatars being "invisible" at log in. They're not actually invisible; the avatar parts are refusing to load and wear from the asset server (or viewer cache, one of the two). In both cases, the asset(s) cannot be accessed at login. In the case of the avatar I've found no way to correct the situation other than replace it with another avatar. Even then, if one tries to wear the original avatar again, it refuses to load.

These may be totally unrelated incidents, but both have the similarity of the system not being able to locate object components on login. The circumstances vary, so I'm thinking these are two similar but un-related bugs. Or they could be different manifestations of the same bug.

[Ilan Tochner]

We rolled out a fix for this issue. Please test it and let us know if you still encounter this problem.