LSL, User Defined Types

Another addition that would simplify coding, User Defined Types. This would make some things so much simpler. Or Structs, or Unions or Enums, whatever you want to use. Imagine this for storing user information in a message recorder:

type user_info
{
      key id;
      string name;
      string message;
      integer time;
      string date;
}
//Yada-yada-yada
      llSay(0, "User " + name + "Came by and said: " + message + " on " + date + " at " + (string)time);

I have actually been working out a 'standard' for struct type data. It basically stuffs everything into a specifically ordered string and I am working on functions to handle it.

Here is sorta an overview of what I'm thinking now:

- Two parts. A list of type definitions, and the structs themselves.

- The definition and the structs are each stored in a comma seperated string

- Format for a definition: "typeName,numOfElements,elem1Name,elem1Default" etc. So I could have "visitor,3,name,"",id,"",visits,0"

- Format for an instance of this would look like: "type,elem1,elem2" etc. So for the example above it would be "visitor,Ama Omega,(whatever my key is),4"

- I building methods to do the following:
- - Define a new type (builds the string, counts the elements, adds it to the list of types, checks for existing type of same name)
- - Create a new instance of a defined type. ex.
structNew("visitor" returns a string with the default values.
- - Pull an element out by name of element ex.
structGet(myVisitor,name) would return the name.
- - Change the value of an element by name of that element


Its not the most beutiful solution, but its workable I think. Getting the define new type not to be too cumbersome is the biggest issue I have. Please feel free to comment.

If I ever get all that done and nice I would look into sorting a list of those types based on specified value and other list operations such as find etc.

No offense Ama, cause I'm sure it work's fine, but wouldn't a list make that alot easier? Sure you couldn't access it like a struct by going variable.substruct , but you could create a function that knows that there are 3 things in the struct,1st is a string, second is a key, and 3rd is a vector. At least thats the closest thing I'm using on my scripts where I store multiple types of Data.

there is a parsing call that you can use to change any string into a list, however you choose. ama just happens to convientently be using commas, so the standard llCSV2List() is all he needs. i am not sure if he is using em that way, but i would be mildly surprised otherwise...

Anyway, this is aside from my point. I would like structs built into LSL to decrease server load for scripts with numerous information to store, and to allow for easily customizable and optimized code.

Ya nada I use llLCSV2List.

And there are a couple of reasons I use strings and not lists:

- There is currently a severe memory leak from returning a list from a function. Something like doing it 20 times or something causes a program to crash.

- You can't store lists inside lists easily, its always just one list. Sure you can insert another list but it will just look like [l1e1,l1e2,l2e1,l2e2] or something. You gotta keep track of where each starts and stops. For strings you can cram em into a list all you want - ["l1e1,l1e2","l2e1,l2e2"].

- Strings are the only other type capable of holding any other type, even lists.

I went into a lot more detail then I really should have I think, but I wanted to make it kind of a standard that anyone else working on something similar we might collaborate.

I hope to make it more or less painless for someone to use without knowing whats going on. Someone will just be able to call defineType("typeName","element,default"; to make a type, string myType = new("typeName"; to make a new one and setElement(myType,"element","newValue".

I debated making it strongly typed vs weekly typed, but decided that it added too much overhead to force a strongly typed system in a weakly typed environment. The overhead is in both the storing of the types for each field and the checking when data is put in, and a seperate method to pull out each type of data. I don't need any of that if I just leave it loosly typed, and less code = less 'undocumented features'.

=============

I agree types would be nice, or actually structs I think are what you are requesting. However I know that any scripting revision is quite a ways off and for any near immediate solution is gonna hafta be player made. I'm just showing I think it can be done.

You can insert lists into lists without serializing the inserted list.

if you have:

list1 = ["blah", "blah", "blah"];
list 2 = [];
templist = [];

and use this call...

templist = llListInsertList(list2, list1, 0);
list2 = templist;

list2 now = ["blah, "blah", "blah"];

This was a big piece of getting the multidim code working.

Word is we see a fix for the llList2Leak this week...unofficial of course.

You don't even need templist in that code.

I know you can but the reason I'm using strings is that in the end you still have one list. Let me give an example, say you have the struct type avatar with elements name and age. Here are the two options:

["Ama Omega",24,"Joe Bob",32,"Suzy Freak",27]

or

["Ama Omega,24","Joe Bob,32","Suzy Freak,27"]

The first one I have to keep track of how many elements in the struct and basically only allow 1 stuct type per list. In the second one you can put any number of struct types in the same list if you want, and I don't need to keep track of how many elements per struct type or any math. The first way can be done but requires more checking and more limits. The second is a lot easier and more flexible, hence why I am using it.

That makes a bit more sense. For the Time being I think I'll stick to the first way though. I have created very easy for loops that go through my lists and pick and use the variables I need in the correct spots.

Currently I have a series of scripts that rez's certain parts of my house/pad based on avatar proximity and commands. There are approximately 60 pieces which are currently being created and destroyed via those scripts (about 15 seperate linked objects, think I'm going to code 60 seperate ones? ) And my list contains the name of the object, vector location and rotation of each (linked) object.

I don't think I would want to script it with each of those being CSV, then parsed to another list, THEN being placed into the proper spots on the llRezObject() function. It seems a very round about way of just having a long list that you know contains items that have 3 distinct parts. So the number of items = llListLength(list)/3

When you move into deeper dimensions than one tier, a unit of usability (slice and listinserts) as opposed to depending entirely on string parsing was much more appealing to me. Ideally you should not have to do any string parsing at all if the abstraction layer is robust.

Depending on what you are doing, the templist may be required. I put it in as pseudocode to illustrate that you can get new lists from old ones by inserting other lists. By holding that list you can insert it anywhere you want into any other list without manipulating the original...including the original.