Linden Logic

or: 1=1 is NOT TRUE!

Scripting a bit 5 came across some strange characteristics of the scripting language of Linden Lab. Strange characteristics mean that it wont do what you expect, or that you have to be very careful working with it. Programming is following intuitively rules about how the language in general functions. Intuition stumbles over these strange things, they are not expected. Bugs come in various sorts and kinds, the stupidities, the typing errors, the designs which are simple not working, but the most awful to debug are the results of situations where the script is plainly not well designed.
In principle you can program everything because of Leibnitz’s great phrase: Nihil est sine causa, or nothing happens/is without a reason. It was of course Heidegger who turned this around in: Being is just that which has a reason. So since programming is just following the lines of causing, you can program everything which is. Only some things take a bit more time to program than others. This more time is multiplied by 2 because of illogical features of a language.
An example, a string is a sequence of characters or numbers or spaces. You can print a string. For instance a name is a string. Inserted in a string can also be a command like new line. Then you can add to your name a telephone number, or an email address. The address can be on the next line. So far the Lindenscript is ok. Then the script offers the floating text llSetText. In it you can put a string and it will be displayed above the prim it is in. And suddenly the string behaves differently! Two commando’s new line placed directly behind each other will give only one new line. The same string in the llSay commando displays the two new lines without a problem. So putting a string like that in a floating text, you have to search for two RETURN’s and put a space between them…….(my oh my…)
Then you decide that the string has to be placed in a database and want to retrieve it again. For this llEscapeURL is used, because of the niceties of the HTML posting, putting %20 where there is a space. That’s is ok so far, but then you actually want to retrieve a large string, so you go the other way around: llUnescapeURL, and behold: the string is shortened considerable! What has happenend, oh dear, search the dBase, search your script, pull you’re hair out!!!
But no: Lindenscript, thank you: this function llUnescapeURL only returns a string with 254 characters, so it cuts off a string which is as a string is defined, in principle without a limit, the limit being the memory available. SO strings can be as long as you want, but using llUnescapeURL it is cut off, and also this cutting of gives a PARSE error in the client…..hmmm, we like that very much, mister Linden!

Talking about the database, you can make a lot of things possible working with a database. The Lindenworld is slow, but get your data to a PHP page connected to a database, you can get the speed of a PHP page connected to the trigger from SL. In ideal combinations for making games possible which need lots of calculations.
Here again something strange happens. The answer coming from the dBase is a string (yes!!! there we go again….) in front of this string is a mysterious return, which is not traceable, nor can be filtered out. That means that if the answer from the PHP page is 1, you cannot compare it to the number 1, nor with the string 1, because this one has the mystery RETURN in front and so is different!
So 1==1 can be FALSE!!!
Now, to get around this 5 uses this trick: let the PHP page send this back: 0 *** 1, then make this a list, with llParseString2List, so it becomes [0,1], the first 0 being contaminated, and just take the second entry in de list!!! This way you avoid the contamination, and 1==1 is TRUE again, as it should be.
This all is clumsy, and has cost a lot of debugging time. Being is that which has a reason. But it doesn’t have to be reasonable it seems, in de SL scripting world.