Welcome to Second Life



  • You may not be aware of Second Life's scripting language the "Linden Scripting Language"



    There is much to explore so here are a few bullet points found in the wiki http://lslwiki.net/lslwiki/


    Keep in mind that since there appears to be no official documentation all information is provided by volunteers (WTF #1)



    in no particular order









    • lack of structs or other constructs



    • function parameters are always passed by value (even lists)


    • the best way to append a element to a list is:



      myList = (myList=[]) + myList + ["new_item"];



    because (quoting from wiki)



    • Don't ask me why but I can save 3-4KB of memory with adding 90 elements. - PsykePhaeton


    • Is this broken as of Aug-21-2007? It doesn't appear to work - VagnerSousaBR


    • "This voodoo magic seems to work fine. Just pay attention to the "new_item" square brackets when it's already returned as a list type in a function like llParseString2List(). I got a stack-heap collision error when I was composing an huge list by the usual way. This way has worked fine."


    • This works because LSL makes a temporary copy of all variables in an expression before it evaluates it. Say you're concatenating two 2kb lists: You originally use a total of 4kb of memory. The normal method of concatenation would copy them (then requiring a total of 8kb), then concatenate them (total of 12kb), then copy them into the original variable (14kb), then destroy all the temporary copies. The "voodoo magic" here is that after the temporary copies are made for evaluating the expression, the original variable is cleared, requiring extra memory only during the copy. This gives the rest of the operation a significant amount of breathing room. -DunselHodgson



      http://www.lslwiki.net/lslwiki/wakka.php?wakka=list


    • its compiled to bytecode to a maximum of 16K per script, but it has no optimizing compiler



    • no support for lists of lists, or multidimensional arrays: so the suggested way is to use a so called strided list




    integer STRIDELENGTH = 3; // this is very helpful when dealing with strided lists to keep your code flexible



    list visitors = ["Ama Omega", 5, "2004-06-12", "Catherine Omega", 12, "2004-06-28", "Ezhar Fairlight", 25, "2004-06-30"];



    visitors += ["Mistress Midnight", 1, "2004-06-30"];



    • even the most basic list manipulation functions aren't O(N)



    • The function to retrieve data about an object (llGetObjectDetails) when you know the key always uses lists, even when you just want a single piece of data (in my opinion, there should be an llGetObjectDetail)



    I believe there is much more to be found


    This post had the collaboration of Sgeo and DrJokepu, my thanks :)



  •  myList = (myList=[) + myList + ["new_item"];

    should be

    myList = (myList=[]]) + myList + ["new_item"]; 

    In case anyone was about to say how The Real WTF was the [ thing..

    TRWTF is that Community Server ate a ]



  • TRWTF is Second Life



  • Since most people play the game (for very small values of "play"), rather than script the game, I can see where the scripting language wouldn't be designed for performance. 

    Given that open-source scripting engines are available on just about every corner, I wonder why they wrote their own.



  • @bobday said:

    TRWTF is Second Life
    2nded. It seems to get a ridiculous amount of media exposure compared to how many people are actually involved in it. World Of Warcraft has about ten million subscribers; it can reasonably be assumed that few of them are people not playing but still paying. SL conveniently won't say how many regular players there are, but I'd be surprised if it's even one million.



  •  

    - "This voodoo magic seems to work fine. Just pay attention to the "new_item" square brackets when it's already returned as a list type in a function like llParseString2List(). I got a stack-heap collision error when I was composing an huge list by the usual way. This way has worked fine."

    It's always fun to have voodoo magic for basic intrisic data manipulation, it makes the language more challenging.  I mean, any weenie can do "list.add(item)", but without undocumented side-effects or arcane incantations that's just lame!

        -dZ. 

     





  • @bobday said:

    TRWTF is Second Life

    TRWTF is feeling that you really need a scripting language in Second Life

     



  • Enjoy your mug, I've seen worse...

    * 10 byte length ints

    Worse in QuakeC: no ints AT ALL, just floats, vectors, strings and entities.

    • no bool short circuiting


      Same in QuakeC. Shortcut bool is a non-standard compiler option, though.

    • no built in list comparison function

      Same in  Perl and QuakeC.


      • ["a"] == ["b"] return true, since it only checks for length

    Worse in Perl:

    "3" != "4"
    "3" == "03"
    "8" == "010"
    "foo" == "bar"
    "nanosecond" != "nanosecond"

    Not an issue in QuakeC, as QuakeC has no lists (available as compiler extension though... and then there is no way to compare them either).

    * one function per type to retrieve an element from a list (there is no generic one)

    You don't want to know how fteqcc emulates arrays in the non-array-supporting QuakeC VM.

    • lack of structs or other constructs

    Same in QuakeC, there is one global type "entity", that's all. You can add fields to it anywhere in the code, though.

    • function parameters are always passed by value (even lists)

    Actually, ALMOST the same in QuakeC. A function can also take a field as an argument (which is a "pointer to a member" in C++ speak):

    void(entity e, .float f) increase_field = {
        e.f = e.f + 1;
    }

    Also, entities are never copied, and neither are strings (but they are immutable).

    • the best way to append a element to a list is:

      QuakeC has no built-in lists, just fixed size arrays... see below for an even worse (but today fixed) problem in QuakeC. 

      * its compiled to bytecode to a maximum of 16K per script, but it has no optimizing compiler


    The only "optimizing" QuakeC compilers generate incredibly broken code when actually enabling them, but there is no real size limit in today's Quake engines.

    • no support for lists of lists, or multidimensional arrays: so the suggested way is to use a so called strided list

    Same in QC with "emulated" lists.

    * even the most basic list manipulation functions aren't O(N)

    In QuakeC with FTE extensions, accessing the n-th list element of an array is O(log n). Can't get any worse than that.

     

    Now, to add my own WTF: QuakeC's string handling.

    Most builtin functions just return pointers to static storage of the function. Thus, calling that function again will change the value of the first string!

    string s;
    s = ftos(1); // s is now "1"
    dprint("two is ", ftos(2), "\n");
    dprint("s is now ", s, "\n"); // s is now 2 (it is a reference to ftos's static string)

    Later, some engines introduced an extension to allow certian functions use one of a buffer of eight static strings in a cyclic manner, to allow a bit more string manipulation easily: 

    while(...)
    {
        mytemp = strcat(mytemp); // revive mytemp
        // now do something else with strcat (at most 7 calls, or it will destroy mytemp!)
    }

    DarkPlaces fixes that by an extension called  DP_QC_UNLIMITEDTEMPSTRINGS which always allocates return value strings from a temporary buffer, which gets cleared when the game engine's call to the QuakeC function is over.

    In any case, to make a string hold longer (it then is kept until the current round of the game ends), you can pass it to strzone():

    string s;
    s = somethingtemporary;
    self.someproperty = strzone(s);
    // 3 minutes later
    dprint("my someproperty is ", self.someproperty, "\n");

    Care has to  be taken to not cause memory leaks that way; although strings are freed at the end of the match, one can easily have a memory leak that allocates hundreds of them in a frame.  There is a function called strunzone() that can free strings, though... and this spawned a special function to change a string field of an object so it can persist:

    void(entity e, .string field, string value) setstringproperty =
    {
        if(e.field != "")
            strunzone(e.field);
        if(value == "")
            e.field = "";
        else
            e.field = strzone(value);
    }

    When the entity is to be freed, one has still to take care to strunzone() all its strings... 



  • @mrprogguy said:

    Given that open-source scripting engines are available on just about every corner, I wonder why they wrote their own.

     

    That was my first thought.  Come on people, there's even one designed specifically for games - Lua!  What's wrong with using something established and stable that already has programmers using it like Python?  No, it must be easier to come up with an entirely new language, write an interpreter from scratch, and be rewarded with tons of bugs and missing functionality.



  • @OperatorBastardusInfernalis said:

    "3" != "4"
    "3" == "03"
    "8" == "010"
    "foo" == "bar"
    "nanosecond"
    != "nanosecond"

    What did you expect? <font face="Courier New">==</font> and <font face="Courier New">!=</font> are numerical comparison operators. For strings you use <font face="Courier New">eq</font> and <font face="Courier New">ne</font>.

    Also, "nanosecond" == "nanosecond".



  • @OperatorBastardusInfernalis said:

    * ["a"] == ["b"] return true, since it only checks for length

    Worse in Perl:

    "3" != "4"
    "3" == "03"
    "8" == "010"
    "foo" == "bar"
    "nanosecond" != "nanosecond"

    Am I correct assuming that the original poster's point was that in LSL, there's no official way to compare two arrays, and the intuitive way (using equals operator) is valid syntactically but doesn't work as expected?

    Because in that case, comparison to Perl wouldn't be valid, because Perl does have perfectly functional string comparison operators ("eq" and "ne"), and its only sin is that the "normal-looking" comparison operator isn't overloaded.

    But if my assumption is wrong and the situation is similar to Perl, well, Perl is hardly alone - I've given up relying on automatically assuming equals operations work in any languages in any non-trivial situations, and look at the documentation and do a test in worst case. Paranoia creeps in so easily. =)



  •  Strings aren't lists in LSL, and string comparision works just fine with == ... if it didn't, my gem would be malfunctioning all over the place

    However, there's no function to compare lists.. I guess one could check lengths with == and see if llListFindList() returns 0 or -1, or just use a loop to check each entry..



  • Aye, LSL is a bit of a WTF. I can mention one more: The preprocessor (is there even one?) can't do basic math.

    integer part_flags = PSYS_PART_EMISSIVE_MASK | PSYS_PART_WIND_MASK; // Compile error
    float inner_angle = PI / 4; // Compile error
    
    init()
    {
        // These are just fine, since the constants are or'd at runtime.
        part_flags = PSYS_PART_EMISSIVE_MASK | PSYS_PART_WIND_MASK;
        float inner_angle = PI / 4; // I suspect the 4 is converted to float at runtime too
    }


  •  Anyone feel that this quote from http://www.xkcd.com/371/ is somewhat relevent?

    "Checking whether build environment is sane ... build environment is grinning and holding a spatula.  Guess not "

     Ok, so maybe LSL isn't exactly a build environment, but still..



  • @WWWWolf said:

    @OperatorBastardusInfernalis said:

    * ["a"] == ["b"] return true, since it only checks for length

    Worse in Perl:

    "3" != "4"
    "3" == "03"
    "8" == "010"
    "foo" == "bar"
    "nanosecond" != "nanosecond"

    Am I correct assuming that the original poster's point was that in LSL, there's no official way to compare two arrays, and the intuitive way (using equals operator) is valid syntactically but doesn't work as expected?

    Because in that case, comparison to Perl wouldn't be valid, because Perl does have perfectly functional string comparison operators ("eq" and "ne"), and its only sin is that the "normal-looking" comparison operator isn't overloaded.

    But if my assumption is wrong and the situation is similar to Perl, well, Perl is hardly alone - I've given up relying on automatically assuming equals operations work in any languages in any non-trivial situations, and look at the documentation and do a test in worst case. Paranoia creeps in so easily. =)

    yes that is the case, if you wish to compare two lists each of your scripts must include a user defined function to that effect.

    http://lslwiki.net/lslwiki/wakka.php?wakka=annoyances



  • Actually, wrong. "nanosecond" gets parsed as NaN value (because it starts with "nan"), thus "nanosecond" != "nanosecond". IMHO this is a big weirdness... try it...

    What speaks against Perl is that the regular == operator actually "works" on strings, but behaves wrong (and one has to use eq/ne instead).

    What speaks FOR perl here is that there is at least a warning (when "use warnings" or -w is enabled) for using == where eq would belong.

    BTW, Perl does not provide a way to compare lists either, and it is not even a trivial task (how to compare references and numbers correctly?)...



  • @OperatorBastardusInfernalis said:

    Actually, wrong. "nanosecond" gets parsed as NaN value (because it starts
    with "nan"), thus "nanosecond" != "nanosecond". IMHO this is a big weirdness...
    try it...

    [code]
    use feature 'say';
    
    if ("nanosecond" == "nanosecond")
    { say q~"nanosecond" == "nanosecond"~; }
    
    if ("nanosecond" != "nanosecond")
    { say q~"nanosecond" != "nanosecond"~; }
    [/code]

    On my system (Windows XP, Perl 5.10.0) this prints "nanosecond" == "nanosecond". Guess it's system-dependent.

    (The Real WTF is the 'say' function, which was "timely" introduced in 5.10 and has to be enabled manually.)



  • Indeed, I did this on Linux. So in Perl, the outcome of "nanosecond" == "nanosecond" is even OS dependent? Worse than I expected...



  • @OperatorBastardusInfernalis said:

    So in Perl, the outcome of "nanosecond" == "nanosecond" is even OS dependent?

    Apparently, since it also works on XP with Perl 5.8.8.



  • Funny, I just recently got into working with LSL.

    The 16K limit is the most annoying thing I've run into so far. It pretty much mandates that anything relatively complex will result in the need to split the logic up among many scripts that run in parallel.

    As a result, it's kind of like an interconnected set of event-driven finite state machines. A somewhat refreshing change from writing linear programs.

    Despite LSL's clunkiness and inefficiency, it's still a usable programming language. In a large community of non-programmers who own a lot of in-game currency, knowing how to program has the potential to be lucrative.



  • Indeed, I haven't spent a single dollar on SL yet. I can't sell my Lindens for USDs without a paid account though, but I'm having fun so I don't really care.



  • @Faxmachinen said:

    I can't sell my Lindens for USDs without a paid account



    Try SL Exchange. I've found they offer better L$ to USD rates than SL's LindEX, and you can then have the USD's sent to your Paypal account for a minor fee.

    I believe you can do it without needing a paid account.

    I'm not making a fortune, but I've gotten more money out of the game than I've put in, which suits my tastes.



  • @pinguis said:

    You may not be aware of Second Life's scripting language the "Linden Scripting Language"

    There is much to explore so here are a few bullet points found in the wiki http://lslwiki.net/lslwiki/

    Keep in mind that since there appears to be no official documentation all information is provided by volunteers (WTF #1)

     The official documentation is in file lsl_guide.html in your installation folder. It is more like a specification/reference than like a guide, and there are a lot of things that are not specified exactly (like in-memory representation) and subject to change.

      

    in no particular order



    Don't forget that the "memory usage" is for a global variable, and it includes bytecode that is used to initialize the variable. So, this will be 4 bytes of initial value, 2 bytes bytecode, and 4 bytes to store the actual value. (as scripts support a reset command, the initial value has to be stored at a different location than the actual value).

     

     

    * one function per type to retrieve an element from a list (there is no generic one)

    http://www.lslwiki.net/lslwiki/wakka.php?wakka=list

    As there is no generic datatype that can hold all values without data loss, this is the straightforward implementation. And it will implicitly typecast if needed. So llList2String(myList,i) is like Java's myList[i].toString().

    my 2¢ 

    mihi 



  • @OperatorBastardusInfernalis said:

    Indeed, I did this on Linux. So in Perl, the outcome of "nanosecond" == "nanosecond" is even OS dependent? Worse than I expected...

    "nanosecond" == "nanosecond" for me on Linux.  I have a feeling you just have no idea what you are talking about and are trying to backpedal on your stupid comments regarding perl's string comparison operators.  I get the feeling you're one of those people who complain when they can't compare objects or pointers with ==.  Seriously, learn the language before you make idiotic comments.



  • @morbiuswilters said:

    I have a feeling you just have no idea what you are talking about and are trying to backpedal on your stupid comments regarding perl's string comparison operators.
    $ perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }"; perl --version
    not equal

    This is perl, v5.8.8 built for x86_64-linux-thread-multi


    Y:>perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }" & perl --version
    equal

    This is perl, v5.10.0 built for MSWin32-x86-multi-thread
    (with 3 registered patches, see perl -V for more detail)


    $ perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }"; perl --version
    not equal

    This is perl, v5.8.8 built for cygwin-thread-multi-64int
    (with 8 registered patches, see perl -V for more detail)


    C:>perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }" & perl --version
    equal

    This is perl, v5.8.8 built for MSWin32-x86-multi-thread
    (with 18 registered patches, see perl -V for more detail)



  • Hmm..  I get 'equal' on 5.8.7.  So it's odd, but not something you should be doing anyway.  My point is that whoever brought this up in the first place was just whining pointlessly either because they didn't know about the string operators or they felt that it was somehow a huge deal.  Seriously, this has been standard for perl forever.



  • The real WTF with SL is the viewer source code, the std:: namespace is too good for linden lab apparently.

    LLString

    LLCrashAndLoop(); // default fatal function

     

    Those 2 are my favourite examples. Not that I have much against SL in general (I in fact own a direct competitor) but there's a few random WTFs with it. 



  • @GarethNelson said:

    Not that I have much against SL in general (I in fact own a direct competitor) but there's a few random WTFs with it.

    You own a direct competitor to Second Life in Second Life or in First Life?  Is it called Third Life? 



  • @morbiuswilters said:

    You own a direct competitor to Second Life in Second Life

    Can't get much more nerdy than sitting in front of a PC steering a character to sit in front of a PC to steer a character in third life.



  • @ender said:

    @morbiuswilters said:
    I have a feeling you just have no idea what you are talking about and are trying to backpedal on your stupid comments regarding perl's string comparison operators. 

    $ perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }"; perl --version
    not equal
    

    This is perl, v5.8.8 built for x86_64-linux-thread-multi


    Y:&gt;perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }" & perl --version
    equal

    This is perl, v5.10.0 built for MSWin32-x86-multi-thread
    (with 3 registered patches, see perl -V for more detail)


    $ perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }"; perl --version
    not equal

    This is perl, v5.8.8 built for cygwin-thread-multi-64int
    (with 8 registered patches, see perl -V for more detail)


    C:&gt;perl -e "if ('nanosecond' == 'nanosecond') { print qq(equal\n) } else { print qq(not equal\n) }" & perl --version
    equal

    This is perl, v5.8.8 built for MSWin32-x86-multi-thread
    (with 18 registered patches, see perl -V for more detail)

     

     

    $ perl -e 'print "nanosecond" * 1.0;' ; perl --version
    nan
    This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
    (with 13 registered patches, see perl -V for more detail)
     



  • @derula said:

    @morbiuswilters said:
    You own a direct competitor to Second Life in Second Life

    Can't get much more nerdy than sitting in front of a PC steering a character to sit in front of a PC to steer a character in third life.

    [url]http://www.theonion.com/video/warcraft-sequel-lets-gamers-play-a-character-playi,14240/[/url]


  • 🚽 Regular

    @nexekho said:

    http://www.theonion.com/video/warcraft-sequel-lets-gamers-play-a-character-playi,14240/
     

    I wouldn't be surprised if that was already true with The Sims.

    On another topic, why was this thread resurrected from the dead?



  • @RHuckster said:

    @nexekho said:

    http://www.theonion.com/video/warcraft-sequel-lets-gamers-play-a-character-playi,14240/
     

    I wouldn't be surprised if that was already true with The Sims.

    On another topic, why was this thread resurrected from the dead?

    D'oh, my fault.  Snoofle's "Not new but it gave me a chuckle" thread prompted me to try googling up an "Enjoy your mug" reference, and then I left it open in a tab without realising it wasn't one of the current threads and ended up replying to it.




  • Also, on topic of Bad Games Engine Scripting Languages:

    This compiles under UScript:
    [code]

    AttachmentClass=class'UTAttachment_PhaserMk3'




    Begin Object Name=PickupMesh

    SkeletalMesh=SkeletalMesh'Borgsiege_Weapon_Rifle.Riggedh'

    End Object
    [/code]

    This does not, citing some random crap that makes no sense.
    [code]

    AttachmentClass = class'UTAttachment_PhaserMk3'




    Begin Object Name = PickupMesh

    SkeletalMesh = SkeletalMesh'Borgsiege_Weapon_Rifle.Riggedh'

    End Object
    [/code]



    Hey, I like spaces in code. I like to have words separated out so it doesn't become a mush and it's harder to lose your place. If you can't figure out how to robustly parse text, maybe you shouldn't be writing a parser for one of the most widely used games engines out there.



  • @DaveK said:

    $ perl -e 'print "nanosecond" * 1.0;' ; perl --version
    nan
    This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
    (with 13 registered patches, see perl -V for more detail)
    Since we're resurrecting the dead, here's what the native Windows perl prints:
    W:\Perl64\bin>perl -e "print 'nanosecond' * 1.0;" & perl --version
    0
    This is perl, v5.10.1 built for MSWin32-x64-multi-thread
    (with 2 registered patches, see perl -V for more detail)



  • A quick Google of "perl NaN" showed me this in [url=http://perldoc.perl.org/perlop.html]perlop[/url]:
    @perlop said:

    If your platform supports NaNs (not-a-numbers) as numeric values, using them with "<=>" returns undef. NaN is not "<", "==", ">", "<=" or ">=" anything (even NaN), so those 5 return false. NaN != NaN returns true, as does NaN != anything else. [b]If your platform doesn't support NaNs then NaN is just a string with numeric value 0.[/b]

    1. perl -le '$a = "NaN"; print "No NaN support here" if $a == $a'
    2. perl -le '$a = "NaN"; print "NaN support here" if $a != $a'

    So apparently it is indeed platform-specific. Why the Cygwin vs Windows ports differ is a mystery that can likely be solved with another Google search. I'll let someone else have that glory.


Log in to reply