Possible change proposal for LSL - a "stateless" keyword

I find that I'm often repeating a lot of event code between states. Functions often don't cut it. For the simplest example, I often use the "reset on rez" pattern in every state. i.e.:

default {

    ...

    on_rez(integer start_param) {
        llResetScript();
    }
}

state other {

    ...

    on_rez(integer start_param) {
        llResetScript();
    }
}

A possible solution to this could to bundle "stateless" events together into a block that is triggered in all states which would cut down a lot of extraneous lines of code in non-trivial scripts, for example:

stateless {
    on_rez(integer start_param) {
        llResetScript();
    }
}

default {
    ....
}

state other {
    ....
}

...what does everybody think of this?

/esc

Not sure what advantages that would have over triggering the same global function in multiple states.

Besides slightly less typing.

One way to do this is to think "multi-script". Have one script handle "stateless" changes, while have other scripts handle various functions of your object with their corresponding states.

Well, Jeffrey, I am a fan of states. I do see a lot of globals being used to flag minor state changes to avoid repeat code. This idea (I think) would encourage the use of states where response to events changes slightly depending on state, rather than the less usual case where the response to events changes completely depending on state. It becomes more evident the more complexity is required of a script that responds to many events, but mostly in the same manner. e.g.

// the current situation

func_a() {
    ....
}

func_b() {
    ....
}

func_c() {
    ....
}

default {
  link_message(...) {
    func_a();
  }
  listen(...) {
    func_b();
  }
  on_rez(...) {
    func_c();
  }
  touch_start(...) {
    llOwnerSay("This message");
  }
}
state other {
  link_message(...) {
    func_a();
  }
  listen(...) {
    func_b();
  }
  on_rez(...) {
    func_c();
  }
  touch_start(...) {
    llOwnerSay("That message");
  }
}

...or...

// the proposed situation
stateless {
  link_message(...) {
    ...
  }
  listen(...) {
    ...  
  }
  on_rez(...) {
    ...
  }
}

default {
  touch_start(...) {
    llOwnerSay("This message");
  }
}

state other {
  touch_start(...) {
    llOwnerSay("That message");
  }
}

/esc
*edit: PS, not just easier to read, and less typing but *less memory usage* (memory something that all my more complex scripts fight with, often being split simply to cope with the strict limits...).

Good point, Hank. That would solve the issue in a few situations. However, I don't think it is as good a solution though... my reasoning being this: the "stateless" events will process on the basis of changed global variable values and thus be far more powerful.
/esc
*edit: don't get me wrong/think i'm being negative - this is exactly the feedback i was looking for...*

This sort of perversion is 100% possible in the bytecode. It's an idea i've been toying with. Just so many projects haven't had time to write a compiler.

OMG too funny! And as you can tell my broken arm is generating my personal interest in reduced typing... lol.

Er... but can you explain "perversion" a bit here, Strife?

best
/esc

This might be handy for cutting down on script bytecode size... hrrm.
*stamps*

-Adam

Meh. Maybe I'm a purist, but this still strikes me as putting a Band-Aid on a broken leg.

If we're looking to seriously conserve bytecode, we should do it right and start pushing for real includes and pointers instead.


For example, I want...

state_entry()
{
     object me = llRezObject("Object",llGetPos(),<0,0,0>,llGetRot(),1);

     me.llSetPos(<1,1,1>);
     me.llSetRot(<0,0,0,1>);
     me.llSetScale(<3,3,3>);

     me.llSay(0,"This is a dream example of pointers.");
}

You've also got O.O.P. in there. Does LSL have any of that yet? O_o;
I mean, the only way to access another object or avatar is to use a string/key and pass it to the appropriate function. =/
Object oriented programming... *drool* :>~~

OOP and Script Includes would be the next best thing since blocked cheese o_O

To be fair, the best ways to "fake" OOP are to encapsulate scripts in objects and run them with listeners. Only problem is that's an exponential increase in asset load.

Of course, once you get to objects inside objects inside objects inside objects inside objects (that's five for those who don't want to count), it gets fairly stupid. And yes, I have something that does that with an actual reason for doing so (a level randomizer).

Maybe eventually.

Oh i should probably mention, last time i submitted a syntax addition to LSL to Kelly, i was told they don't plan on changing the syntax till after Mono. Lets just wait for mono.

We are unlikely to see pointers, for the obvious security and stability reasons. Not only that, but from what I gather Cory doesnt believe pass by reference is a design goal of LSL.

Includes are definetely something I'd like to see, but how they are implemented is going to make or break them, and is something we will see 'after mono'.

For now, I'll take any band-aid we can get, the bytecode limitations of LSL are not nice to deal with.

-Adam

What prevents scripters, who like using multiple states, from splitting their code into two scripts? Am I missing out on some detail that makes states strategically important?

*dreams of classes, arrays, xml-rpc, static pointers for pass variables in functions, static variables, read and write data storage, and other O.O.P. goodness*

In two words "shared globals". In more words, because a state usually changes a global which affects the execution of a second state. Splitting means signalling changes via messaging which obscures and bulks out the code in each script. Ahem. Maybe that old adage "globals are evil" is the root cause of the broken leg... OK, just give me that Java API... or when we get to Mono a Java CIL compiler... eek what am I saying, ok just ignore me lol.

This doesn't really have anything to do with the thread or even with LSL, but I love pointers. Who can't appreciate the conciseness of something like this?

char *strcpy( char *dest, char *src ) {
    while( *src != '\0' )
        *dest++ = *src++;
    *dest = '\0';
    return dest;
}

Object oriented stuff is fun too, in a different way. Especially when coupled with garbage collection.

I agree that what you are suggesting would be great, but I think that global functions are close enough to it that it would not be worth the effort on LL's part to implement "stateless" events.