Jump to content
You are about to reply to a thread that has been inactive for 79 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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 by Rolig Loon
  • Like 2
Link to post
Share on other sites
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. 🙂

  • Like 1
  • Haha 2
Link to post
Share on other sites
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 by ItHadToComeToThis
Link to post
Share on other sites
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.

  • Like 1
Link to post
Share on other sites

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);

 

Link to post
Share on other sites
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

 

Link to post
Share on other sites

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.

Link to post
Share on other sites
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 by Mollymews
memory
Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 79 days.

Please take a moment to consider if this thread is worth bumping.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...