LSL comment blocks

// I would like to be able to write
// a short paragraph at the
// beginning of my LSL scripts. Doing
// this with a '//' at each line is
// cumbersome and annoying.
/*
I think it would be better if we had
proper C-style slash-star, star-slash
comment blocks. This would make
the opening documentation MUCH
less of a hassle to write. Don't you
agree?
*/

edit: changed title of thread to LSL Compiler Suggestions. Anything else you want to see? Might as well have it in one thread.

So far, /* */ comment blocks and grouped variable declaration, i.e. "integer a, b, c, d, e". Anything else? I'll toss in another one... #include.

edit edit: doh, can't change the thread title... guess I will open a new one.

/*
Yes I do agree
*/

lol yeah i agree

// speaking of C... I'd like to be able to do...

integer a,b,c,d,e;

// instead of...

integer a;
integer b;
integer c;
integer d;
integer e;

Speaking of C, we can make the subject in to C++, and then talk about making LSL show it's C++ side more


String parsing!

Let's say I told an object to die when I said "goodbye." Not only would I like it to react if I said "Goodbye," "GoodBye," or GoOdBYe," but I would also like it to react if I say "Goodbye there little friend" (i.e. use it in a sentence"

Maybe something like so:

if (llToUpper(llGetSubString(listenEventString, 0, 6)) == "GOODBYE")
{
     // stuff
}

with "listenEventString" being what's passed to the event, then it would react on "Goodbye", "goodbye", "GoOdByE", "Goodbye!" and "Goodbye, good night, see you tomorrow".

Ama Copylefted uber code follows.

if ( llSubStringIndex(llToUpper(message),"GOODBYE") >= 0 ) { // do stuff }

That will "do stuff" if goodbye is in the message in anyform, any place in the message. If you only want to respond if it is at the beggining replace the > with == .

[edit] Fixed a one character bug Tcoz pointed out.

I think Ama's is more what I was talking about... no offence of course...

Number of us have done the string recognition thing...upper case conversion is old programmer technique, and substring recognition is pretty easy to do with the LSL functions. I have a sorta NPC in Nexus Prime that recognizes a variety of phrases as well as people; any Linden that speaks to it gets a certain pool of messages, and so on. Send IM if you like more info.

Interesting how we all do things a little differently...for the substring index thing I just use if != -1, since any value other than -1 indicates the string has been found...0 could mean the phrase was found at the beginning of the message as far as I know, though my feeble brain isn't recalling whether 0 or 1 is the start of this particular index.

if ( llSubStringIndex(llToUpper(message),"GOODBYE" != -1)

You are right Tcoz and my first function needs to be adjusted from > to >= . My mistake.

Hi, this is a defacto standard, it sure would be handy in LSL! (I cannot believe it ISN'T already there! holy cow..)

llGetTime()
llGetTimeOfDay()
llGetDate()
etc...

pfffft! At times, I want real time, when I don't care what time the server booted, an object was created, or what date (preformatted!) it is.

You can dump at least 2 functions for the following new function:
llGetCompTimeStandardInSecondsSince00:00:00(GMT)Jan1st1970ThankYouVeryMuch();

You can opt for a shorter named function call, if that pleases you.

Thanks,
Bosozoku Kato

llGetWallClock() will get you partway there.

For your suggestion, I think I would prefer llGetTicks()



--
Grim

If you're interested...it's sort of off tangent but we seem to have lost the thread anyway...

I was curious why in line declaration would be left out of the compiler specs, i.e. if (integer i = 0; i <= 5; i++). Just seemed like a no brainer.

This may have nothing to do with it, but LL has stated that they attempt total multiplatform and portability when possible. Some bell was ringing in the back of my head about this one, so I started digging. Turns out that inline declaration is a late edition to the ANSI standard and is not implemented by all compilers. To write absolutely multiplatform/compiler code, you would not use in line declaration, at least not until a compiler that doesn't support it is no longer considered ANSI standard compliant.

Guessing? Oh yes. Maybe the compiler is a retro fit of one that doesn't support this feature...maybe LL are true multiplatform/hardcore standards nuts. Maybe they just left it out. We seek meaning where we may.

I don't think the ANSI standards mention anything about "states" and I sure as hell know they say something VERY different about what "[" and "]" are supposed to mean. I'd guess they didn't give us inline declaration because a) they didn't get around to it or b) it would break something else.

Well...I don't think I suggested that the SL compiler was intended to be ANSI compliant. What I was more suggesting was that some of these features people seem to think of as "standard"...are not, and that such exclusions are actually more widespread than I had thought, largely for these reasons. I don't think it's out of the realm of possibility that the compiler framework was not baked from scratch (i.e. the C-like structure of the language), and that the features were influenced by it. But as I said, I was just noodling.