User Defined Functions

Is it possible to get some info on User Defined Functions, what you can and can't do with them?

you just define them in your global name space along with your global varibles

ie

dostuff()
{
code
}

you can also pass it varibles
ie

dostuff(name)
{
if (name = name)
{
blah blah blah;
}
}


in your state / event you would do something like dostuff("osgeld barmy"

or you can have it return values
ie

dostuff(name)
{
if (name = name)
{
return(true);
}
}

in your state / event you would do something like if (dostuff("osgeld barmy")

ect
and you can pretty much do anything you can in any event

I know how to define them and trigger them just fine.

ok returning a variable is where I am in need of more explanation. Can I have it return a list so I can say do this


list lThisList = DoStuff(name);

?

yes

just make a local list inside the udf, do all your work there, and return the local list

ok my next question is then, can you only return one variable or can you return more?

1 afaik

course you could just have the udf work on a global variable directly, and then you could biuld a list with multiple values

i wish you could return more than one, ive been quite spoiled by that in lua

says only one, however you can compose multiple types and variables to a list and return that

You forgot to tell me I had to define the udf as the type I wanted to return. I figured it out though. Here is a script I was working on to learn more about User Defined Functions.

list GetInventory(integer iInventoryType)
{
    integer iCount = 0;
    integer iInventoryCount = llGetInventoryNumber(iInventoryType);;
    string sInventoryName;
    list lInventoryList;
    lInventoryList = llDeleteSubList(lInventoryList, 0, -1);
    while(iCount < iInventoryCount)
    {
        sInventoryName = llGetInventoryName(iInventoryType, iCount);
        lInventoryList += sInventoryName;
        ++iCount;
    }
    return(lInventoryList);
}

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        list lThisList = GetInventory(INVENTORY_OBJECT);
        integer iListLength = llGetListLength(lThisList);
        integer iListCount = 0;
        llSay(0, "There are " +(string)iListLength+" objects in here.");
        while(iListCount < iListLength)
        { 
            llSay(0, llList2String(lThisList, iListCount));
            ++iListCount;
        }
        lThisList = GetInventory(INVENTORY_TEXTURE);
        iListLength = llGetListLength(lThisList);
        iListCount = 0;
        llSay(0, "there are "+(string)iListLength+" textures in here.");
        while(iListCount < iListLength)
        {
            llSay(0, llList2String(lThisList, iListCount));
            ++iListCount;
        }
        
    }
}

You could also benefit by reading the following...

http://www.lslwiki.net/lslwiki/wakka.php?wakka=UserDefinedFunction

Thanks.

Just to quibble, you can't pass variables, you can only pass values.

What's the diff? (I know Osgeld knows, this is for the peanut gallery.)

If we were passing variables (a.k.a, "pass by reference", a function could modify a passed variable. That is:

function foo (list mylist) {
    mylist += (list) "A";
}

...
    list q;
    foo(q)
    llSay(0, llList2CSV(q));

If we passed variables, this code would chat "A". But, in LSL, we cannot; we can only pass values. Changes to values don't get propagated back to the variables that had earlier held them.

This concludes today's lecture.

Now that takes me back to the old programming classes, thanks!

/me straightens his bow tie and grins.

i did, but wow, you put way too much faith in my knowledge lol

to get around that, you can have the function operate on a global and return nothing as Os mentioned earlier

Hmm sorry for bringing this back up, but I understood what he meant by passing a variable. While I can't exactly quote exact terminology like all of you. I do have programming experience. Just curious about how it was handled in the lsl. Didn't realize it had been 4 months since I last worked on my code. The help here has been more then I expected though. Thanks!

You may have understood what he said, but what he said, "you can also pass it variables", is false.

It's better to say what's true than to say something false, even if many people will still get the right idea.

Accuracy is important.

What he meant to say was simply "you can also pass it values".

This isn't criticism or chop-busting, it's just a correction in the interest of accuracy. I make mistakes in my posts all the time, and I really appreciate it when others correct me.

seconded... much as I hate screwing up, I hate hate not knowing I did more.