I'm looking for scripters

[Blackjack Cioc]

I'm looking for scripters interested in collaborating on new simple and fun projects. That he's only interested in money. Contact me if interested. Blackjack Cioc

[Rolig Loon]

You're posting in the wrong place.  Ask in the InWorld Employment forum.  This forum is a place for scripters to trade ideas and moan about things that aren't working in their LSL scripts.

Edited August 2, 2020 by Rolig Loon

[Lucia Nightfire]

5 hours ago, Rolig Loon said:

This forum is a place for scripters to trade ideas and moan about things that aren't working in their LSL scripts.

Don't forget, moan about things we can't do in LSL yet, but should have a decade ago. 🙂

[ItHadToComeToThis]

7 hours ago, Lucia Nightfire said:

Don't forget, moan about things we can't do in LSL yet, but should have a decade ago. 🙂

Switch statements, classes, dictionaries, dynamic variables, inheritance, auto complete, debugging tools!! 😅😆
 

Edited August 3, 2020 by ItHadToComeToThis

[animats]

1 hour ago, ItHadToComeToThis said:

Switch statements, classes, dictionaries, dynamic variables, inheritance, auto complete, debugging tools!! 😅😆

Without more memory per script, more language features would result in scripts that wouldn't fit.

[Mollymews]

if I could have only one thing other than debugging tools then I would like a struct type please

like:
 

struct mything
{
   string Text;
   vector Color;
   integer Opacity;
}

mything a;

a.Text = "Hello! World";
a.Color = <1.0, 1.0, 1.0>;
a.Opacity = 1.0;

list mylist += [a];

mything b = llList2Struct(mylist, mything, 0);

llSetText(b.Text, b.Color, b.Opacity);

 

[Profaitchikenz Haiku]

4 hours ago, Mollymews said:

struct type

Isn't this a list?

[Nova Convair]

6 hours ago, Profaitchikenz Haiku said:

Isn't this a list?

Absolutely everything can be done with lists.

It may be ugly and unreadable and inefficient but who cares about this minor details 😎

[Mollymews]

19 hours ago, Profaitchikenz Haiku said:

Isn't this a list?

is a bit more than this

i used the llList2Struct() function to show how we might be able to use/access a list of structs

as Nova suggests structs would add a whole lot more efficiency and readability to our scripts. Another example:

struct mysit
{
   string: Animation;
   vector: Pos;
   rotation: Rot;
}

mysit Sit;

Sit.Animation = llGetInventoryName(INVENTORY_ANIMATION, 0);
Sit.Pos = <0.0,0.0,0.5>;
Sit.Rot = llEuler2Rot(<0.0,0.0,90.0> * DEG_TO_RAD);

llStartAnimation(Sit.Animation);
llSetPos(Sit.Pos);
llSetRot(Sit.Rot);


// with lists then we have to write like:

list mysit;
llStartAnimation(llList2String(mysit, 0));
llSetPos(llList2Vector(mysit, 1));
llSetRot(llList2Rot(mysit, 2));

i think that the struct way of writing code is a lot more readable/understandable than the way we have to do it now

i think as well that the Linden developers who maintain the LSL codebase would like it as well if/when one day Linden make some budget available for this. Adding a struct wouldn't break any existing scripts. The existing ways would still be available and continue to work. It would tho enable us to code in a more descriptive way going forward

 

[Profaitchikenz Haiku]

I agree that readability is greatly improved, but I'm not convinced there would be any improvement at runtime.I am slightly biased here because years ago I was working on two system in parallel, a threaded-interpreted Language (Forth) and a stack-based intermediate language. In each case I was able to take the "compiled" code to a dissassembler and look to see what extra stuff was being added by the compilation process, and the stack-based intermediate language (read bytecode today) had nearly twice as much extra machine operations as the TIL. Yes, it was much nicer looking at C-code when writing the programs, but the Forth implementation ran almost 30% faster and took up a lot less space, to the point where there was no longer a need to have overlays being paged in and out.

Style and form are both great, but I will go for functionality every time.

[Mollymews]

1 hour ago, Profaitchikenz Haiku said:

I agree that readability is greatly improved, but I'm not convinced there would be any improvement at runtime

LSL is a stack based language so i think that we can only compare stack-based to stack-based

comparatively then

struct MyThing
{
   integer I;
   string S;
}

the template for the struct MyThing is a static object in heap memory (so this memory allocation is a minus for script memory use)

mything A;

create A copy in heap memory of MyThing
initialise A.I in-situ in this heap memory to 0
assign to A.S a pointer into the stringtable in heap memory
push a pointer to A onto the stack

comparatively

integer I;
string S;

push I onto the stack
initialise I in-situ on the stack to 0
 
push S onto the stack
assign to S on the stack a pointer into the stringtable in heap memory

LSL also uses pointers on the stack to other heap memory types: vector, rotation, list, etc

so in the above comparison we can say that  generally structs are more expensive memory-wise than straight variables

when we compare to list type tho we gain performance efficiences

A.I = stack pointer to (heap memory block A ) + memory offset I;

i = llList2Integer(A, 0) is a call to a look up routine

in this comparison structs will outperform lists by quite a lot

 

structs are found in languages like C.  A way to group related values of different types into a contiguous memory block to speed access

 

Edited August 4, 2020 by Mollymews
memory