LSL needs too many hoops…

Recently, when the Regency opening party was to occur, a friend mentioned a problem with the Writer Steam Works 8 Seat Skyjumping Lift, which was unfortunate, as she had intended to place it for use for the event. I was disheartened. So much so, that with other things that were on my mind (not SL related), I was about to place all my land for sale and then leave SL for good. I was, to say the least, frustrated.


I’ve had strange little issues occur with the lift since the beginning. At first, it was learning how to do vehicles in LSL. It’s not really very intuitive and the instructional materials I’ve found just didn’t seem to be geared towards my frame of mind. No big deal, as I’ve tought myself many programming languages over the years, so LSL wouldn’t be the one to stump me for long.

I managed to work around many of the LSL and SL limitations in order to make the unit work. Usually. There always seemed to be another little bug that would pop up at the most inconvenient time. Of course, I could never seem to duplicate the bugs. When I’ve written RL applications, I’ve always had debugging tools with which to find something I did that I shouldn’t have, but in LSL, you need to work around even that.

Years ago, I had to write a program to transfer data from a data collection terminal to a PC (still ooc). The manufacturer of the terminal had gone out of business, but the large company I was working for had several of the terminals and needed to use them. Problem was, the manufacturer’s program stopped working when faster computers were used. We’re talking 12MHz 286’s here, so this is dating myself!! The terminals, for whatever reason, did not respond to flow control of any kind. What was worse was, there wasn’t a technical user manual for the unit. I had to improvise. I wrote a new program that had a timing routine that would gauge the throughput of the computer and slow down the transfer such that it would not overwhelm the terminal. It worked and the company was able to use the devices again. It bothered me to use such an inelegant approach, but I had little choice.

LSL has brought me back to the bad old days of computing. The language, in and of itself is not the problem. It’s reasonably powerful for a scripting language. It can do most things I want, even if I have a wish list a mile long of things I would like it to do. Sometimes, if there is something I want to do, but LSL is unable to do, I improvise. It is flexible enough that one can do this for many things. Not all, but many. Problem is when it comes to timing. LSL is by no means deterministic. Not by a long shot.

I cannot guarantee that something that needs to be done will be done when it needs to be done. As it is more an event-driven state machine than a procedural language (try nesting functions!!), you have to change your state of mind to work with it. For certain functions, LSL asks the server to do something. On a fast sim, you might get the response quickly. On a slow sim, you might get the response eventually. To work around the timing issues, you can create temporary states or you can use timers and then check. There are other tricks, such as setting up the next event within the event handler of the previous event. I do that as well.

What is really frustrating is when I work on something, think I’ve accounted for every impossibility, put something on the market, only to find that there was an impossibility that I had not accounted for. To make matters worse, I sometimes cannot reproduce the problem! It is very difficult trying to troubleshoot something that you cannot make occur. That is what happened with the lift. I could not, for the life of me, make the problem occur. I went so far as to create an alt so that I could test it just in case it was some strange hidden rights thing. No, that didn’t help.

A customer purchased the unit this morning and it didn’t work. It would work if he went to 500′, but if he went beyond, he would have to re-rez the lift platform. Not very convenient and quite frustrating. I know that when I buy something, I expect it to work as advertised. I decided to put in coding that would account for even more impossible happenings and after a little bit gave the customer a replacement. I put in coding such that if you touch the platform, you will force the unit to scan for the lift. Not since that program on the 286 did I have to take into account things that should not have to be taken into account.

I’m not likely to leave SL just yet, but I’m becoming quite disillusioned by the hoops one must go through to make things work. I’ve always been a perfectionist when it comes to coding. I’ve always gone a little bit further than necessary to make my code elegant. Readable, provable code is important to me. Hoops, on the other hand, are for children.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s