While I personally am rather fond of the LSL language itself, the bindings between the language and the server side are a mess! There's a whole pile of things that you could do, if only the supporting routines had been implemented, and these crop up more and more often with some of the new features. While some of this post probably belongs in "new feature suggestions", the bulk of this is devoted to discussing limitations of the current system that make the job of a scripter a LOT harder than they need to be. And then there are a couple glitches that will snag any builder, not just the scripters.
Problems:
- The HUD is great. It's arguably one of the most innovative features added to SL lately. Unfortunately, one of its primary purposes - displaying the control panels on vehicles or other interactive devices - is severely hampered by the complete inability to effectively dispose of such a temporary attachments. llDetachFromAvatar leaves it in the inventory, and llDie does not work on attachments. Even better would be if an attachment had a flag that would destroy it on detachment.
- llMapDestination comes very close to the functionality of llTeleportAgent that those of us who have been designing things like, say, working stargates have been needing for ages. Unfortunately, it cannot be triggered from a collision event, and according to the wiki, even touch events are broken, triggering it for the wrong user. Triggering from a collision event is only fundamental to every single teleportation field, event-horizon, and step pad in existance (not including those that require seperate activation with buttons).
- And while we're on that topic, llTeleportAgent has been a long time coming. I really hope that it's not hampered by the same problems. Since that's stilll more in the "missing features" than broken current features, I'll leave that one be.
- There is no function to trace a path from one point to another through space, returning the distance that the path is unobstructed. I find this absolutely baffling, as this function is standard in virtually every other 3D environment script system in existance. Even QuakeC had it. llSensor is supposed to be able to handle this case, but unfortunately, it only detects objects centered within the scan cone, and only returns the object's position, not the trace intersection. This deficiency hampers everything from pathfinding systems to the ability for a vehicle to make a sensible landing on a non-ground landing pad.
- The llDetected* functions are lacking a few that would be really useful. One that comes to mind immediately is the ability to detect the face and UV coordinates of a touch event, which among other things, would allow the creation of realistic control panels with a minimum of prims.
- There is, to my knowledge, no way for a script to read the currently set map nav point from a user's map. This, unfortunately, makes point-and-click autonav systems impossible, leaving only the possibility of landmark-based ones. With llMapDestination available now, this problem is all the more serious.
- Speaking of landmarks, apparently there is still no function to return the name of the sim in the landmark, or the landmark's local coordinates in that sim. I have not personally encountered this one, although this apparently caused serious problems with llMapDestination (resolved now, I believe).
- The ability to toggle on and off mouselook, with appropriate permissions, from a HUD attachment would be useful for many, many things. Everything from using a starship targetting computer to various interactive game elements. Since HUD attachments are often used as extended UI controls, this is only logical.
- Vehicular Teleportation. It's bad now, and it's only going to get worse when llTeleportAgent arrives on the scene and people try to do all the neat things with it that one would expect (like, say, flying my starship through a stargate). Right now, SL does the worst possible thing when teleporting while in a vehicle: the vehicle stays behind. While actually *solving* this problem would be wonderful, a script call parallelling llDie() that returns the object to the user's inventory would be nice. A suggestion for a real solution, tho, would be a flag on the sat-upon object that determines whether, if sat upon by its owner, it should follow or remain behind upon teleportation (to avoid, say, bringing chairs and houses along for the ride if the object was NOT a vehicle).
- Linksets are constrained in a number of annoying ways. It's impossible to in any way add a prim to a vehicle in flight. As it is now, a starship shield needs to be a tiny prim hidden somewhere until called upon, for instance. The llRez functions have no provision for directly adding to a linkset, and llCreateLink cannot function when the user is sitting on the object. And heaven forbid that one would actually try to set a prim inside a linkset phantom.
- And as for prims, is there any particular technical reason that prim cuts are clamped to a 0-1 range? Expanding this to, say, 0-2 or -1-1 would allow arbitrary cuts on prims, and while I don't have the actual generation equations for the prims in front of me, the only change that should be required to implement this is opening up the clamp range slightly. The only risk is that some people will make self-intersecting prims, but that can be dealt with by simply clamping start+end<=1. Just try to make an ellipse, with the tall side facing upward, with an upright rectangle cut into it, and you'll see just how much this simple limitation can hamper a creative build.
- Communication between scripts at very long range is problematic at best. The only reliable way to do it is via email, which has been a severely suboptimal solution for a very long time. How about allowing objects to receive IM's, or removing the same-sim limitation from llGiveInventory? And it would not be a bad idea to fill in llDetected* with the details of the user doing the dropping when calling the changed() event upon notification of inventory change, either.
Unfortunately for me, I've run into the bulk of these first-hand. I like to push the limits of the scripting environment to make innovative builds, and I've run into an aweful lot of these little design glitches along the way. I'm very much an enthusiast of the SL experience, and I'm hoping to be able to eventually complete some of the builds that got shelved due to the above.