What kinds of problems can stop a scripted object from rezzing?

What kinds of problems can cause a 3 prim scripted object (a photo album I made) to refuse to rez from your inventory onto the ground in front of you? (on land where you are allowed to rez things) Can't wear or attach to hud either.

Customer reported the problem -- they put photos in, and now it won't rez inworld for her. She passed it back to me, and I can't get it to rez either. I just tried 5 different sims including mainland. I even had a friend allow me to rez on their parcel, but turn off scripts, so I could isolate (or make a guess) whether it was a issue with the script, or the prim. Still wouldn't rez, even where the scripts in it weren't allowed to run.

The no copy item leaves your invy for about a second, fails to rez with no error msg, then returns to your invy.

Could it be corrupted / invalid text in prim name or description? I once had a problem like this, a long time ago.... when i used to used ^ as a memory param seperator in the desc line of prims... then, remember, the Lindens monkeyed (er fixed a bug) with what the desc line would accept. Here's the contents of the objects desc line: does this look like it would cause a problem for rezzing? On*On*<1.00000, 1.00000, 0.00000>*On*On

Could it be the script is stuck in a state where, dunno, it's not happy?

I don't know the answer - in all likelihood only Linden Lab can properly diagnose the problem - however, can you put the offending object into the inventory of another object? And, if so, what happens if you have it rez the object? At worst, maybe you'll get some kind of failure message.

default
{
    touch_start(integer total_number)
    {
        llRezObject("MyObject", llGetPos() + <0, 0, 2>, ZERO_VECTOR, ZERO_ROTATION, 0);
    }
}

Well, interesting test. Just did it. Object fails to rez with no visible error msgs. Nor are there any apparent related error msgs in debug console.

I worked a bit with Amber Linden on the issue. Her only suspicion to date is that it might be related to a "special character" somewhere -- either the apostrophe in the name of the object "Joan and Martin's photo album", or an asterik in the desc line of the object, or a special character that SL doesn't like in the file name of one of the photos inside the object's content.

(llGiveInventory works fine -- it will give it to you from the rezzed box -- it just won't rez it in-world for you.)

This isn't the first time I've heard of this phenomenon, but sadly still haven't seen or heard a definitive cause.

One more long shot - anything reported in SecondLife.log?

(XP directory: C:\Documents and Settings\YourAccount\Application Data\SecondLife\logs)

Amber Linden did say one useful thing (not applicable in this case) -- she's seen failure to rez when you have active a group that is either defunct, or that has a special character in its name that SL isn't entirely happy with. To test for that, you just set active group to none.

I've been watching those logs the past few days. My problem in understanding them, and in watching the debug console live on the screen, has been trying to relate what I see to what I did -- as something that seems like it might relate, often pops on the screen 3 minutes later. Take this msg for instance:

2009-04-27T19:05:57Z INFO: LLAssetStorage::reportMetric: Couldn't store LLAssetStoreage::reportMetric - no metrics_recipient
2009-04-27T19:05:57Z INFO: LLXferManager:rocessFileRequest: xfer request id: 11697890017966083222 to 216.82.19.73:13002
2009-04-27T19:05:57Z INFO: LLXferManager:rocessFileRequest: starting vfile transfer: ab65095c-4ed7-6ad9-15b5-a2ed611b5117,texture to 216.82.19.73:13002
2009-04-27T19:06:04Z WARNING: LLInventoryModel::accountForUpdate: No category found for update 00000000-0000-0000-0000-000000000010

That looked somewhat vaguely promising, but it happened like 3 minutes later, and no matter how many times I repeated the attempted rez action, that error msg did not show in the console again.

At random points I also saw this:
2009-04-27T19:02:21Z INFO: LLAppViewer::idle: Kills on unknown objects: 1

but then a few minutes later, I'd see:
2009-04-27T19:02:21Z INFO: LLAppViewer::idle: Kills on unknown objects: 7

and go, oh.

So I really don't know if what I'm seeing logged has anything to do with the price of tea in China.