How to: lsl for programmers of advanced languges (PHP, and C++)

Hello,
I am an advanced programmer. My two main languages are PHP and SQL. I also know C++, javascript, ruby, vb 6, and XML. I have read the LSL guide that came with sl (the entire thing seriously), the wakka crash course, and other ones.

I am having a lot of trouble because i have never programmed in C. I am more used to OOP. And what is really funny is that although lsl is "object oriented" (ur programming objects for good sakes ^_^) there isn't ANY OOP!!!!! Also I am not used to programming for performance. Readability and extendibility has always been more important. When programming server-side performance is somewhat important (slow program makes users take forever to load) but to the point of lsl. I have heard people say that lsl is similar to programming an embedded system such as a remote or a one of those little sensors on the toilet (lol).

Just any help would be awesome.

Also another thing is that I am not good at desktop programming. I would like to know how to interface with a server easily via PHP. How can I use a mysql database in my lsl scripts. I was thinking is there a way that I can send a data to a server using get variables and make a primitive "web service". Then to retrieve data I would send some variables and then retrieve the HTML from the page. Is there an easy way to do that.

Also can you send data to a webpage via POST. That would be much more effective.

I know I am asking a lot but I just want to play second life and apply my uber-1337 programming skills.

I know there is a lot of people who have trouble going from high level to low level primitive languages. The weird thing about lsl is that it has all the bad things of low level (being hard to program and the bad things of high level programming (not having enough control). It isnt easy but I know there are some fellow PHP brothers here who could help me.

Thanks a lot everyone

___________________





A little bit about myself:

My typical username is aceofspades. I am an open source PHP programmer. I primarily participate and lead projects on source forge. I have a nice web hosting package which I have been unable to use. I founded the Open Education Software Foundation and we are currently starting a large scale education CMS, called Open Educate CMS.

You are scripting *behaviors*, and LSL is a state-transition based behavior modeling language.

Previous experience and knowldege are good things, but try not to let what you already know get in your way.

Well put, Lee.

LSL is really very object oriented, except that it has no concept of "class" built into it, and there is no subclassing in the language per se. Other than that, it's really quite high level -- if you don't think so, you haven't done much low level coding! And the ability to simply drop a script into an object and it immediately has all the behaviors of the script. This is really an excellent form of subclassing -- saying this object is a member of a class, the script implementing the behaviors of the class. The main difference is how multiple inheritance works. In Java, you don't get it at all (you implement it explicitly and only inherit the interface). In C++, you have complex issues with virtual functions: if method Y is implemented in both parent classes, which does your object get? In LSL, you get BOTH.

IMHO, LSL looks very good for its purpose, with the concept of the state machine built into the language rather than being something programmers need to implement.

The way OO is often described, rather than doing something to an object, we send it a message and ask it to do something to itself -- somthing the object knows how to do. In C++/Java, we don't actually send messages, we invoke methods. That looks a lot like function calls. This is missing in LSL, but instead we have events (including actual messages), which is really closer to the OO concept than invoking methods. In this regard, LSL is more purely OO than Java or C++.

That should serve you well in learning LSL. Seriously, having knowledge of multiple languages gives one an added dimension when looking at a new one.



Well, actually, if you know C++, you've programmed in C. C is C++.. without objects! (yeah, I know, without templates, yadda yadda). You still have the same conditional statements, loop statements, variable and function declarations (not methods, just regular functions). Also, you're equivocating "object" (in-world physical representation of a 3D entity) with "object" (a programming structure abstraction and method for combining data and the code to operate on said data into one easily-graspable and extensible bundle). As such, LSL is most certainly NOT object-oriented, in the latter sense of the word, anyway.



Yes, because of the nature of what you are doing in LSL (real-time simulation systems), performance is often critical. Also, code efficiency is very important, since you have a very limited space to operate in (scripts can only use 16kb for both code, data, and stack). However, I still opt for readability, flexibility, extensibility, most importantly maintainability as much as I can. Those nasty little tweaks that are out there (*waves to Strife*) can come in handy when there's just no other way to make LSL do what you want it to do, but I try to avoid having to use them as much as possible through the use of good design. So, basically, do your best to follow your instincts and design/develop according to what you are used to (and as applicable within the constraints of LSL), but don't be afraid to sacrifice a small bit of the "good virtues" when something *has* to work. Just be sure to document the hell out of it so you don't come back scratching your head later going "WTF was I THINKING when I WROTE THAT CRAP??".



Yes, LSL provides a basic ability to make web requests and handle responses via the llHTTPRequest function and the http_response event. There is also XML-RPC support, for external servers to make calls into LSL scripted objects, but it's a bit more advanced.



Yes, part of the llHTTPRequest interface is the ability to use either the GET or POST mechanisms. Check out the LSL Wiki for more info.



Well, you should do fine. Just tackle it from the basic concepts of programming you know from your various languages, and don't try to translate the specifics. As someone else already said well: don't let your existing knowledge get in the way of learning something new.

There's plenty of folks here willing to help, and the Wiki is a valuable reference tool. There's also a Scripters of Second Life group in-world that you can join and ask questions. There are also tons of examples, both in the Wiki, and here in the forums. Don't be afraid to look at how someone else tackled a problem in order to shape your approaches to doing the same.

Yes, LSL is alot like embedded programing (the only recent large scale computer system with similar restrictions is a PDP11, so welcome to programing in the 1970's ). *waves to Talarus*, if there is anyone to talk to about optimizing LSL source, it's probably me. You really shouldn't be optimizing code unless you really need to (or really want to, at which point it would be wise to get yourself committed to a psychiatric hospital). You can waste a lot of time optimizing code that you will just end up having to re-optimize when it needs to be changed. It all comes down to prudence. If you write clean logical code with possible optimization in mind; it will optimize easier then if you just write what is easy.

I came from Java/Ruby to LSL myself and I have to say that while I was a bit intimidated when I started I did not find the transition hard at all. The event/state based behavioural thinking follows quite naturally to me from OOP (maybe that tells more about me than the languages, but still) and apart from a couple of known bugs and annoyances I find it intuitive enough in SL context. I would not say there is "none" of OOP in LSL, either.

As to the optimization, when you start needing it you will notice and there are people around (like in the Scripter's groups you can join) who are willing and able to help.

As a wise person once said to me, "Optimize algorithms, not code."

Of course, like any general rule it's not always true. But it's always the first thing to do.

To be honest, this sounds like a book-smart vs. street-smart situation.

Instead of telling us what a great programmer you are while complaining about LSL, just roll up your sleeves and start coding. You could read the wiki 10 times over and still not learn as much as you would from writing your own app.

*nods nods*

Experience is worth more then education (unless you need the certificate to get the job).

Fortunately, we haven't sunk to the level of "LSL certification required to participate" becoming part of RFPs.. yet.

Definitely true, though, about getting your hands dirty. "There is no substitute for experience."

Ifyou know how to program the language is reasonably irrelevant. Yes there are syntaxical differences and programming models that need learning but the basic (NO PUN INTENDED!) reasoning remains pretty constant.

Like any API there is a lot to LSL that needs to be learnt and the best way to do that is by diving in and trying.

Well, plus a lot remains undocumented. The thoroughness of the documentation is lamentable. It's not what I consider pro quality work, frankly. As a result, we learn to expect behavior that's not guaranteed and might change in the future.

But all in all, it's a game, right?

Actually, the Wiki is VERY thorough, and covers I'd say easily over 95% of the subject quite well.

I wouldn't agree more. I am sorry if I came off as complaining about the languge. I just meant that it is hard.

Thank you for your responses. It is quite encouraging, I will just read some examples and try to apply them and modify them.

I I also wondering what the best way to interact with a server.

I was just kidding when I said I had uber-1337 programming skills (or was i LOL) and I know some guys who can program a whole lot better than I can.

Anyways I got that lsleditor (edit: wow its even got an offline version of the wiki!) cause I hear it is pretty good.

Thanks a lot everyone it is nice to know that you guys are so kewl.

I will start working on some scripting and making online interfaces for lsl objects. For example I was thinking of making an online interface for casino objects. Then I could make a "legal" online casino ^_^.

Anyways wish me luck.

I am gonna go try to figure out how to do a web service on PHP.

I am happy to meet you all.

I looked at this thread earlier and there is one thing I am curious about. With all of that background, I would have thought that scripting would have been the first thing you dove into in the game. I am asking that because I joined in May, don't know any languages, started scripting at end of August. Now there isn't much that I can't figure out how to do with LSL.

Not trying to pick on you, I am just really curious about it. Curious because to me scripting is a truly wonderful thing here now. How many languages are there that you can cobble something together in a little bit of time as a beginner and get instant feedback when you throw it in a prim. WOOT!!! the first time you take the default script and change it to say something else besides "Touched"!!!

Anyways, Welcome! The more the merrier!

PS your best freind here is "Search this forum", underneath the "Page 1 of ....." in the upper right. Between the wiki, examples and the search function in scripting tips, nearly all of the bases are covered.

he He Jesse, I was here nearly a year before I even bothered looking at LSL. It wasnt why I was here, but professional curiosity got the better of me....

"Pretty good" is not how i would describe it. It lacks much of LSLs core functionality and in many situations it does not behave how LSL behaves (many of my scripts do not compile or return odd results). Some of the things it allows are not valid LSL. IMHO it isn't at the stage yet of being useful, but it is getting there.

I would recommend getting a copy of lslint. It is an offline syntax checker that gives better error messages then SL's compiler (not to mention you don't have to be online to use it).

So it's the language that determines proficiency! Well, FMH.

No, what's really funny is that all OOP language interpreters and compilers are written in Java. Er, except for Java which, of course, is written in molasses.

// and /* */ are your friends.

Nah, just blame Microsoft.

I would advise against programming while on the toilet -- you might fall in.

default
{
    touch_start() {
        llHTTPRequest("http://ursite.com/sumdumscript.php",
            [HTTP_METHOD,"POST"],
            "f=lsl&u=is&b=so&a=damned&r=easy");
    }
    
    http_response(key iReqId, integer iStatus, list iMeta, string iBody)
    {
        llOwnerSay("I received this response to my request: " + iBody);
    }
}

<?
    $f = $_POST['f'];
    $u = $_POST['u'];
    $b = $_POST['b'];
    $a = $_POST['a'];
    $r = $_POST['r'];
    echo "$f $u $b $a $r";
?>

If that isn't clear enough. Try this:

default {
    state_entry() {
        llLoadURL(llGetOwner(),
            "Wanna RTFM?",
            "http://www.lslwiki.com/lslwiki/wakka.php?wakka=llHTTPRequest");
    }
}

Funny how the reverse is less common.

Yep, LSL is the Wrong Thing. Beware of raster burn. Avoid getting in eyes. If contact with eyes should occur, rinse eyes out with copious amounts of tabasco or wasabe. Contact the CDC immediately for a full rectal exam.

LOL dude I laughed IRL at what you said. That was pretty funny.

Anyways thanks that really helps. I guess a few of the thing came out wrong >.<.

Anyways once I read the last 900 pages of apress.pro.php.xml.and.Web.Services ill be all set >_>

BTW how is sloth. It is an eclipse plugin and I was just wonderin how good it is. The lsl editor doesnt work at all. Which am i better off using, notepad++ or sloth???

I was just thinking maybe lsls strength is SOA. I am gonna to start testing a server to object interaction. My goal is to make a waking online interface for casinos. All you have to do is slip the script into your casino and upload the php scripts and you have an online casino. Later my building friend can make some nice casino objects and I can program them.

I use Scite-EZ with lslint tied into it. It is also tied into the wiki. Hit F1 at a function and it will pull up that wiki page. You also have option of saving as an esl and stripping the white spaces out autamatically and generate an lsl. file. Customize away. I have mine tied into a copy of the wiki in my computer. Just update the functions in it as they come out.

You can do a forum search for both Scite and Notepad++. There are some threads laying around with more comments.

I always thought Java was written in BrainF*ck.

no its written in lsl.......

((please dont kill me its just a joke no harm or foul))


Btw ok thanks btw does sloth have a syntax checker???

Nice post, just to be pedantic Current preferred PHP programming style is to use full opening tags <?php instead of short tags, and short tags are disabled in the default and reccomended php.ini.

I'm still not sure why the myth of HTTP POST is more secure/better than HTTP GET comes from. If PHP is used server side, then there is no difference between the two in terms of functionality or security.

But agree with all the comments that the best way to learn LSL is just to start writing it and always have the Wiki to hand

I am still trying to read a 1000 page book (go to http://www.3m2.net/ebook) on integrating XML into PHP and creating web services. My plan is that I am going to make a generic casino web service that receives an XML document from any application. The data that would be sent would be
*The type of game (poker, blackjack, slots)
*The amount of money in
*The odds (you may want to increase the chance of the object winning by 10%)
*The client ID
*The machine ID (optional for stats)
*The orgin/device (php-gtk gui, C++ gui, LSL, etc)
*The person's id (or IDs for certain games)
*The person's name (or names for certain games)
*The time that it was sent (for testing transfers speed it is optional)

It would than interface with a database and the tables it would use would be prefixed by the client ID.

Basically it does all the normal stuff.

It then sends back
*The outcome
*Who won
*The payout

And anything else. I guess im missing some things as I have no idea how casino programs work. If I could see an example of a script that would be nice. Then I could figure out how to adapt it.

So I would make a class for each games. I would need help with the algorims and stuff.

It would only be run on my server (or maybe it could be distruibuted) and its on a commision basis or a something. Ill figure that out later.

Then I dont have to care about lsl (except the small interface and processing scripts). It would be more efficient because all the math would be done by the server and it would also reduce the amount of scripting. Another benefit is you could make a machine that did every casino operation (it would change its textures) and it would be a casino in one.

This would raise the speed of casino scripts. They would no longer need to do all the memory intensive stuff and make the user wait 3 minutes. PHP is uber fast and it could easily do this. I still have no clue how to do any of this stuff from the lsl side but I dont have to. The point of it is for independent developers who make casinos to use it. It would aslo make it easier to track commissions for people who provide their casinos on an affiliate basis.

I see a huge future for this and there is no doubt about this.It is simply innovative. I will need ALOT of help doing this. And I am willing to share both the eventual profits and the work load.

If anyone wants to help me out and knows PHP I would be quite appreciative.

I know this is quite ambitious but this is even further than second life. With the use of an API devs of all languges can make a casino interface using anything from a C++ app, or a java app, GTK app, a online javascript application, or even a cell phone application.

Now come to hink of it I probobly would distribute it. It would have to be encrypted though.

/me drops to the floor, shaking and frothing at the mouth. Java, my cryptonite.

NEVAH! <? if(strlen("?php" > strlen("?") { carpal_tunnel >>= 1; } ?>

Maybe because get variables are displayed on the address bar for all to see? There are other significant differences between GET and POST:
http://www.w3.org/2001/tag/doc/whenToUseGet.html#uris

XML == eXcessively Multitudinous Labels. I suppose it's cool if you've got gigabytes of memory to spare, but with 16k per script in LSL ... then again I've seen ppl implement bigint math and rsa encryption in LSL, so more power to you. When I pass values between PHP and LSL I tend to use as economical a format as possible [c.f. KISS].

Dunno if this helps, but llHTTPRequest passes server variables to the PHP script.

<?
$objectName = $_SERVER[X_SECONDLIFE_OBJECT_NAME];
$objectUUID = $_SERVER[X_SECONDLIFE_OBJECT_KEY];
$objectRegion = $_SERVER[X_SECONDLIFE_OBJECT_REGION];
$objectPosition = $_SERVER[X_SECONDLIFE_LOCAL_POSITION];
$objectRotation = $_SERVER[X_SECONDLIFE_LOCAL_ROTATION];
$objectVelocity = $_SERVER[X_SECONDLIFE_LOCAL_VELOCITY];
$objectOwnerName = $_SERVER[X_SECONDLIFE_OWNER_NAME];
$objectOwnerUUID = $_SERVER[X_SECONDLIFE_OWNER_KEY];
?>

llHTTPRequest speaks SSL.