llGetObjectName

llGetObjectName...

if the object name is actually blank, what gets returned?

Seems to me I read recently in this forum that it returns null or somethng, but I have the worst luck with the search engine in this forum in trying to find things again.

Why would you post this question when it takes like 30 seconds to find out..

default
{
state_entry()
{
integer length = llStringLength (llGetObjectName());
llSay(0, (string)length);
}

}

It returns a string length of zero, hence a null string.

>> Why would you post this question when it takes like 30 seconds to find out.

Um, cause I ddin't know how to find it out, OK? I'm really dumb you know. And ektually, I spent 15 minutes searching before asking my question, so apology accepted. If it was that much trouble for you to have answered, you needn't have bothered.

So, to clarify, to test if it's empty

you don't go

if (llGetObjectDesc == ""

but rather

if (llGetObjectDesc == NULL_KEY)


?

Actually Chaz, it's llGetObjectDesc = "". Empty quotes signify a null-string. The NULL_KEY notation is for an empty key. I imagine keys work with both "" and NULL_KEY, but that strings only test on "".

if (llGetObjectDesc() == ""

is the correct version

(key)"" is not equal to NULL_KEY, though

NULL_KEY == "00000000-0000-0000-0000-000000000000"

You know...after having gone to sleep and woken up, I should have known that Thanks for straightening that out.

Okay, I'll go back at trying.

The reason I asked is that I'd already played with that:

if (llGetObjectDesc() == ""

saying, kk, if true, then write something into it.

state_entry() {

if (llGetObjectDesc() == ""
llSetObjectDesc("Banana";

}

But, though I think I was being labelled lazy for posing the question :} I had actually spent 45 minutes scratching my head as to why it never kicked in, and then more time searching here for what I thought I remembered (but after 12 hours at one script, you are no longer clear what you know, never mind what you remember :})

Maybe linden servers were just having a funny turn at the precise time I was trying it.

/me points out that the thread it titled for llGetObjectName but that that your sample code uses llGetObjectDesc..

Yes. I was actually trying with both "fields". But good catch, as it sure would have been a palm against forehead moment otherwise.

Basically, when an "app" starts up, I'm trying to say, kk, if the prim name and prim desc fields are blank, write some default variables into them.

But must have been the phase of the moon or something, as the dang thing just wouldn't detect if it were blank or not. That's why I got *lazy* :} after an hour of trying and searching and asked.

I will try again later this afternoon to see if testing for llGetObjectWhatever == "" will now magically work.

Actually,

llStringTrim(llGetObjectWhatever()) == "";

would be better because then you will catch " " as well. Assuming, of course, that you consider spaces to also be nothing.

Also, I'm not sure about this, but it wouldn't surprise me if testing string length is is faster than comparing its value. ie:

llStringLength(llStringTrim(llGetObjectWhatever())) == 0;

I'm sure someone with lower level knowledge than I will have something to say about that.

Didn't think you were lazy, just that I thought since you were scripting, you'd test it rather than post, sorry if you took it the wrong way, wasn't trying to hammer you.

There's the off chance that you weren't resetting the script after each description change or checking on_rez(). State entry is only called when a state is entered, and state persists between picking up and re-dropping. So describing HOW you tested it is definitely important. For example if you:

1. modified the code
2. changed the description to ""
3. picked up and redropped the item.

You might find that its still "". However if you were to put your same check in on_rez() as well, you would find that it did, because no state transition occurs on a rez, but a rez event does.

Details like that can screw ya just as easily as (and much more frequently than) bugs in LSL.

Ie. post the full source, and describe what you did when it failed. It may be very apparent and prevent a lot of discussion based on assumptions.

here's exact code. the assignment to tmp01, tmp02 is just there temporarily, as I was doing a bunch of tests *before* I lazily posted my question. so yeah, was using trim.

state_entry() {
string tmp01 = llStringTrim(llGetObjectDesc(),STRING_TRIM);
if (tmp01 == "" {
llSetObjectDesc("Black|Black|1|White|English";
}
string tmp02 = llStringTrim(llGetObjectName(),STRING_TRIM);
if (tmp02 == "" {
llSetObjectName("30|Ring|Access Denied|Elevator Door Heavy";
}
}

I like the idea of the string length thing; might be more reliable. On the other hand, maybe it will work as is today, phase of the SL moon and all that, who knows? Cause I can't see any reason why it shouldn't have worked. Maybe just tired eyes missing an obvious typo. Back at it later. Thanks for feedback everyone. Lazily yours (grin), etc.

looks ok to me

default
{
    state_entry() 
    {
        string tmp01 = llStringTrim(llGetObjectDesc(),STRING_TRIM);
        llOwnerSay("start desc: " + tmp01);
        if (tmp01 == "") 
        {
            llSetObjectDesc("Black|Black|1|White|English");
        }
        llOwnerSay("end desc: " + llGetObjectDesc());
        
        string tmp02 = llStringTrim(llGetObjectName(),STRING_TRIM);
        llOwnerSay("start name:" + tmp02);
        if (tmp02 == "") 
        {
            llSetObjectName("30|Ring|Access Denied|Elevator Door Heavy");
        }
        llOwnerSay("end name: " + llGetObjectName());
    }
}

results:

new object

[17:59] Object: start desc:
[17:59] Object: end desc: Black|Black|1|White|English
[17:59] Object: start namebject
[17:59] Object: end name: Object

cleared both fields

[17:59] : start desc:
[17:59] : end desc: Black|Black|1|White|English
[17:59] : start name:
[17:59] 30|Ring|Access Denied|Elevator Door Heavy: end name: 30|Ring|Access Denied|Elevator Door Heavy