Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

"Object" variable type in scripting
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
10-16-2005 09:04
Just a note to say that I've added a feature request for something which could be VERY useful in the Linden scripting language. I'll quote the feature request itself so you can see:

From: I
I feel that the Linden scripting language could benefit strongly from the addition of an "Object" variable type, which basically encompasses all variables (ie an integer is an object, so is a vector, a float etc, all can be handled under this heading if you do not know which data type you will have, or wish to work with several via the same function).

In this way instead of being forced to pass only integers, keys or strings to linked objects through the llMessageLinked command, I could pass a single object; or if it allowed multiple variable syntax several, like llMessageLinked(linknum, Object1, Object2...ObjectX).

It's just that I've created an object I want users to be able to click on and change the colour of easily, but it has lots of primitives. So each primitive would have a function to change it's colour, but this requires a vector or a float. With this implimented I could simply pass one of the two as an object.

Now the obvious consideration is that this would require me to make sure I know what object I am going to receive (either a floar or a vector). But this could be handled by a set of comprehensive Object2Type and isObjectType functions. Object2Vector would take any numeric information and convert it into a vector, or return a null vector in the case of a string with no digits. isObjectString would return true (or integer 1) if the object is a string.

This would REALLY help scripting out quite a bit, as it's a very restrictive limitation.


It also occurs to me that it would be possible to add this in without damaging any extra functions when you think about it, for example:

llMessageLinked(integer linkNum, integer num, string msg, key id);

Can be converted to:

llMessageLinked(integer linkNum, Objects);

Since 'Objects' could be any combination of items, any existing script which sent the original information (num, string and id) would still be accepted, as these would be three objects.
Since the corresponding link_message() event would be looking for these, they would correspond directly without error, but the functionality is there ready to be used!

If the llMessageLinked had only a single object then it would still work, as the link_message event would simply assume null values for anything it expects, that the llMessageLinked function does not provide (ie if it expects more variables than were provided).
If it receives more objects than it wants, then it would simply ignore the rest.

In this way it wouldn't even break existing scripts!

So if you think the idea has merit, then please vote for it by clicking here so we can get this sucker into the game ;)
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
10-16-2005 10:10
Some of the typelessness that you want in Objects is implemented in Lists, with corresponding llList2Type() functions and a function to determine what type a given item in a list is. This has an advantage over a single Object type of allowing multiple variables to be stored together. There's been a lot of pushing to get llMessageLinked() to take just a link number and a list... this would encompass your solution and be even more flexible. I think there might even be a feature in the voting tool for that.

Until then, you can pass up to two lists via a link message, although in a somewhat hacky manner:

CODE

list list1=[7, <0,1,2>, "foo"];
list list2=[5, <2,1,0>, "bar"];

llMessageLinked(linkNumber, 0, llList2CSV(list1), llList2CSV(list2));


On the way out, do this:

CODE

link_message(integer link, integer num, string str, key id) {
    list list1;
    list list2;

    list1 = llCSV2List(str);
    list2 = llCSV2List((string)id); // not sure if the cast is even necessary
}


It's not necessarily a good idea to treat a key as a string, but it seems to work alright so far. Hopefully that doesn't break in the future.

Note that the llCSV2List() function will bring the list back as a list of strings. Even the data that went in as vectors or integers will come out as strings. I think llList2Integer() will still work in such cases, but I know I've gotten hung up before by passing keys as part of my list; they required a cast to key afterward. If you want to be sure your list makes it through with types intact, check the examples on the wiki entry for llCSV2List.
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
10-18-2005 01:47
Hmm, I must admit I hadn't considered lists when I submitted this idea, however I feel there may be advantages in both.

Firstly, using lists alone would break compatibility with existing scripts, unless we had the language look for either a list OR the variables as they are now, which is just nasty.

And actually, the object type as I'm describing it would encompass lists, allowing you to do things like:
CODE
list list1 = ["Buh", "Bah", "Foo"];
llMessageLinked (LINK_SET, list1);

But also:
CODE
list list2 = ["Blah", "Meep", "Ping"];
llMessageLinked (LINK_SET, list1, list2);

This allows you to pass two or more lists as seperate entities, having them automatically passed as two seperate variables when they reach the other side, rather than having to either place all elements in a list and split them, or having to place two lists within another, parent list (if this is even supported, I don't see why not but I haven't tried).

It would also remove the need to place single or very few items into a list, which although not a huge inconvience is still a bit restrictive, and as I say it avoids the additional step of then removing the information from the list again.
Jesrad Seraph
Nonsense
Join date: 11 Dec 2004
Posts: 1,463
10-18-2005 01:57
Funny that, Strife's TLML allows for the kind of functionnality you want :) You can easily dump the list into a string (with llDumpList2String), send the string by link message, then unpack it in the child prim (with llParseString2List).
_____________________
Either Man can enjoy universal freedom, or Man cannot. If it is possible then everyone can act freely if they don't stop anyone else from doing same. If it is not possible, then conflict will arise anyway so punch those that try to stop you. In conclusion the only strategy that wins in all cases is that of doing what you want against all adversity, as long as you respect that right in others.
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
10-18-2005 11:14
Yeah, I know that, and it's a good solution for now, but with this we wouldn't have to, saving uneccessary code :P
Templar Baphomet
Man in Black
Join date: 13 Sep 2005
Posts: 135
10-18-2005 19:41
If the rumors of Mono becoming the script runtime platform are true, you'll get your wish to a large extent!
Unit4 Grasshopper
Registered User
Join date: 13 Mar 2005
Posts: 2
well
10-18-2005 22:34
you could change them to whatever you need, for example you listen for a number and you want it as a float so that you can change things about it like multiply or add or whatever. you can just change it like so:

CODE

listen(integer chan, string name, key id, string message)
{
     float number = (float)message; //returns 0 if it isn't a number
     if(number != 0) //check it to make sure it is valid
     {
          //actions
          float newnumber = number * 2;
          llSay(0, (string)newnumber);
     }
}