Browsing Options Clear Filters
Top 5 Tags: musing[2] scripting[2] mono[1] lsl[1] object communications[1]
Summarized 2 of 6 Categories:
· thearidians.org (11) newest: We\'re Back apollo 18th Feb @ 15:32 EST
· quicklinks (3) newest: Snowball Combat apollo 1st Jan @ 18:34 EST
May 2007
Several Years Later
apollo [LSL] Wed 23rd @ 04:30 EDT
object communications
According to the SL 1.16 release announcement, they are adding the function llRegionSay to the scripting language. What does this new feature do?
Says the string msg on channel number channel that can be heard anywhere in the region by a script listening on channel.
This is a very useful feature and one that I was quite shocked to find missing, back in the days when I used to script in SL. I still believe there should be a better inter-object communication system in addition to chat listeners, but this function should help to peel back a layer of complexity when trying to construct any system with distributed nodes. As long as those nodes are in the same region, of course.
January 2007
LSL: Too Much Kissing
apollo [LSL] Sun 21st @ 12:02 EST
lsl, mono, musing, scripting
Whatever your position on Microsoft might be, I happen to think that some of their ideas are well-founded and some of the design decisions they enable others to make are useful too; it would not have been fun to wait 20-odd years for a mouse with more than one button, for example. One of the products that I believe they consistently get right is Visual Studio and the technology that supports it.
I use the .NET platform extensively at work because our organization is primarily Microsoft-centric. I use decidedly non-Microsoft technology for this website though and I like both approaches in their respective environments. The point of all this? Well according to the OLB we're much closer to a mono infection now.
My hideous geek-style sense of humour aside, this announcement can only mean good things for SL. It's no secret that I'm not the biggest fan of LSL as a programming language and I'm also not particularly fond of how sluggish it is or how detrimental it is to simulator performance. I'm glad LL focused their energy into fixing some of the more pressing problems first, but I see the move to mono as pretty significant too.
With the First Look client and the recent network protocol changes they are already well on the way to fixing at least 60% of the sluggish feel of SL, subjectively speaking anyway. Making LSL vastly more efficient would, obviously, significantly reduce simulator lag associated with running scripts but given that a good percentage of simulator lag is caused by scripts in many cases, these changes are going to have a significant impact.
After the FL client becomes the real SL viewer and after the mono engine comes online, the only significant causes of [performance degradation] will be bandwidth and the monolithic asset server cluster. Changes to the SL protocol that are underway and restructuring of agreements with providers could and are making inroads into the former, which leaves us with only the latter as a major threat to the future scalability and current operation of the system. Well that and the login servers, which can be said to be under some strain at peek times if the occasional long login queue is any indication.
My point in all of this is really to say that 2, 3 and 4 months ago one could have easily been forgiven for predicting the imminent implosion of SL under the crushing weight of a million or so free accounts, but it honestly seems like the system - SL as a whole - is beginning to stabilize. The single biggest "win" for SL as a whole will be making the asset system fully scalable and capable of handling the current and future load, but this push into mono for LSL is still going to be a pretty big win on performance criteria alone.
All that and I didn't even discuss how eventually this change will gift LSL developers with a more robust, industry-standard language capable of realistically applying current programming techniques such as classes and objects and perhaps even genuinely real arrays, that is if I understand correctly that the intent is to move away from the LSL syntax completely one day. I can only dream.
December 2006
Exercise Can Be Negative
apollo [LSL] Mon 18th @ 15:33 EST
musing, scripting
My real life job involves writing a lot of code in a variety of different languages, some of which include php, the .net managed plaform in VB and C# for Windows and Web, as well as Microsoft SQL Server 2000's scripting language for Stored Procedures and User-Defined Functions and Structured Query Languge itself for MySQL and SQL2000, so as you might expect I have been known to tinker with the odd LSL script. I can honestly say that of all these languages, coding in LSL is the one that most often feels like an exercise in futility.
My principal complaint is that there is little uniformity to LSL and that the small amount of uniformity that is present seems to exist only to drive home the point that LSL dislikes the most commonly accepted programming conventions. On top of that, things that should be simple are encumbered by the need to perform arcane coding rituals, things that would not be complicated in any other language are made so by LSL itself and things that are genuinely complex to achieve feel as though they are composed of sticky tape and cardboard and could fly apart at any moment.
That said, I do still attempt to create scripted objects in SL, not because I am a masochist but because I want to make things that are fun and interesting, that are interactive and useful, and as annoying and idiosyncratic as LSL is, it is also all that we have. To be fair to LSL it does actually work once you prod and coerce and ultimately bend to its whims. I only wish that it wasn't such a debilitating process.