Wanted: your top 5 ways to improve scripting

There is a user-created .chm here:
/invalid_link.html

Newest version is at the bottom of the thread

[QUOTEThere is a user-created .chm here:
/invalid_link.html[/QUOTE]

I've already found that and have a copy, thanks.

But, it's still incomplete and doesn't have implementation examples for all functions, which what I assumed others meant here when they talked about complete documentation.

And there are some ambiguous references, as well. For instance:

------------------------------
llRezObject
llRezObject(string name, vector pos, vector vel, rotation rot, integer param);

Creates an instance of the specified inventory object at position pos with velocity vel and rotation rot. The created object must have the "Physics" box checked on its property page in order for the velocity to apply. The created object’s on_rez() event handler is invoked, and the param argument is passed to it.
------------------------------

Does these mean the object's inventory or my avatar inventory, or either?? What are pos and rot relative to? (The object, the sim, the world, the owner, the target?) To you it may be perfectly clear. I, however, have been in-world for two days. It's not so clear to me. Considering the lag caused by out-of-control scripts and the potential to crash the sim, it would be preferable for me to have good docs than to learn everything by experimentation.

I realize the fact that the current help file's condition isn't the fault of the authors. It's not their job, they're doing it out of the kindness of their hearts, and they do have other things to do in their FL than make my life easier. Which is why I'm requesting that LL actually take responsibility and maintain such a document instead.

--
Grim

woohoo some good criticism!!! hey grim would you mind picking through the doc and either emailing me at nada@badgeometry, or send me an im in world about all the stuff that needs clarifing? or... what would be even better is if you started a thread that had all this in it, then other people could add their comments as well. we need some fresh blood to look at it and tell us what it needs. heh we are too close, so we need some pointers so start a thread, and we will start answering these q's.

[/b]
pos is related to the world/sim coordinates, and you are limited to a ten meter radius from the rezzing object. Setting a rotation is always related to the world axis. (there are ways around this, rotation math lets you determine what the needed rotation is to rotate it about its local axis) i will say i did run into a problem last week where an object had been put into another object already rotated, and when it came out, we couldn't get it to set the proper rotation. needs more testing though.

If you give a script via llGiveInventory, it is off by default in the recieving primitive object. It is also not possible to turn on that script via LSL. The llSetScriptState function simply fails in this circumstance.

I had a set of requests - but I realized, making llSetScriptState function on a script given to an object solves all of my requests.

Is this behavior by design or a bug?

I've had a similar problem, although in my case the object was rezzed at the right rotation, but wrong position. Damn annoying

Something to check for an object that can't move or rotate on rez: I rezed a locked object and while the locked object could change its size via script, it could not rotate itself or move itself.

I'm adding to this thread for two reasons:

1) I have a few more things I'd like to see, now that I'm more familiar with LSL

2) I want to bump this thread, since we're getting closer to v1.1.

My new list of 5:

1) script permissions/ownership (already in, but I'm not gonna change it)
2) Create/Alter notecards
3) set "constants" from a pie menu
4) determine if an avatar is in a specified group, even if that group isn't their "active" group.
5) state-scoped variables and functions, with evaluated initializers

Stupid Noob Comment here but... editing sctipts IN the inventory would be nice.
I find it a hassle to always dump things out on the ground to just "look" at the code.

Or am I missing some way that this can be done?

You can edit a script in your inventory, so long as the script is actually in your inventory, and not in an object that's in your inventory.

I think what you really want is to be able to access an object's contents without having to rez the object. (Join the club. ) I think you'll see this, if you dig deep enough, in the feature suggestions forum. It hasn't really been brought up here because it's not an actual change to the scripting language itself, it's more a change to the client interface.

Bump to "Rez" (pun intended?) a good thread...

As for suggestions I don't have anything specific at the moment, but I would rather see more *functionality* than something like switch statements (for example).

If it can be done currently, but just happens to be a little longer to type or whatever, I'd much rather see more llEtc functions and stuff like that.

Switch/case would be cool but if it's between being able to use that and being able to write to notecards...who would rather see switch/case??

Of course, this might not be the type of suggestion being looked for...but the type of improvement wasn't specifed.

(Okay....how about a
llFindObscureRuntimeBug.ThatWouldTakeForeverToFindWithoutThisFunction() ?

How about a better way to learn it ??!!

Ho, ho, ho! It's hand grenades I throw!

1. as has been oft suggested, switch
   
   
2. llRezObject() should return key of object created so that you can
   further manipulate it; moreover, a KEY_NULL can be returned for
   objects that failed to rez. Currently there is no way to get a
   handle on created objects nor get feedback that they were, in fact,
   actually created.
   
   
3. I want to select N objects and pass them to the script. E.g., I
   have an Effector object that takes N objects and will space them
   evenly in a circle round a point. There is no way that I can select
   objects and pass them in as arguments to a script. (Urm, at least
   as far as I can tell. Can anyone enlighten me otherwise?) I have to
   add all the objects to the Effector's inventory and then run
   the script.
   
   
4. A means of #include so that it's possible to generalize common
   script functionality.
   
   
5. With all the mention of "java" in the documentation, there sure as
   hey is very little in the way of object oriented anything in LSL.
   I'd love to see classes with complete inheritance, polymorphism, and
   encapsulation. I realize that's a lot to ask, so I'll be happy with
   structs.
   
   
6. Ability to import external 3D formats. This would reduce the load
   on the servers as builders can then build prototypes locally on
   their machines using such free tools as gmax, and then u/l them en
   masse. I'm not talking having to support every format out there;
   something like a sub-set of VRML would be ok. (And have the
   importer do the Right Thing (tm) if it should, say, not find
   corresponding textures, or not able to complete the import due to
   other problems. THis would include importing what you can, or
   prompting the user to continue if encounters errors. Imported
   objects should go directly to inventory so that you don't have to
   worry about running out of money in the middle of importing a
   complex object.) The other advantage to this import mechanism is
   that it would make it A LOT EASIER to tailor textures for
   specific objects. I'm having the devil of a time getting a texture
   to map perfectly over a dome after sweating over the GIMP for a
   while. I'd hate to have to u/l N instances at L10 a pop before
   converging on the optimal texture. It'd be far more efficient to
   noodle with the texture on my machine to get a perfect fit before
   uploading it to SL proper.
   
   
7. a debugger would be nice
   
   
8. For that matter, how about cobbling up an external "simulator" build
   tool? Again, users can build to their hearts' content on their
   local machines without logging in and using universal SL machine
   resources. They pop online to squirt/synch their scripts and
   objects. Natch, this has the disadvantage of cutting down on
   socializing opportunities. (Then again, there's always e-mail and
   AIM, no? )
   
   
9. Having script messages be sent directly to you (or a note for later
   review!) instead of dumping out for all to see would be a goodism.
   
   
10. an eval() for dynamic scripts; (and for the sick people out there, a
    gateway to writing your own built-in LISP interpreter)
    
    
11. hash or dictionary containers
    
    
12. containers of containers (e.g., lists of lists -- no I'm not going to build that LISP interpreter. Really!.)
    
    
13. a way to get a snapshot of current location and/or have its own camera. Imagine, for example, a drone that feeds its video back to you, or a security camera that takes pictures. Yes, I realize this may be difficult to implement, but who said all suggestions had to be serious?
    
    

(ICYC, I wrote my first script the other night. It was a ball, but
very frustrating. However the radial object placement effector now
makes it easy to evenly place objects in a circle, a la Stonehenge or
gazebo support columns.)

Wow...

Well I'm sure they'd be happy to start on that if you donated $1,000,000 (real life) to hire some new employees. hehe

I bet it's easier to add new functionality (new llEtc functions) than it is to add major new script language enhancements...I think that'd be a pain...(personal opinion). Of course that's what I'd rather see so maybe I'm biased

I think the *first* and probobly eiasiest of the camera functions that should be implimented is llDetectedCamera();
For objects it will return <0,0,0>. But for avitars, it will return the offset of the camera from the avitar's position (in mouselook, it should return <0,0,0>

1. Hash
2. Regex
3. Manip the HUD, 2d UI funcs
4. Write to notecard or better yet, create table, select, insert, update, delete
5. Determin x/y coords of the face where the touch_start event was triggered.

Make
Somone
Else
Do
It

Actually, many of the items I mentioned should be fairly trivial to implement. For example, the llRezObject() return value should be dead easy since presumably the newly created object's ID info is right on hand. The switch() should be straightforward, unless you want to take advantage of O(1) optimizations, which is what occurs in present-day compilers and interpreters. (What, you thought that switch() was merely translated into else ifs? Nope. There's a reason why switch(), in C and C++, has cases based solely on numeric values and not also on more sophisticated comparisons. That's because the switch()'s case values are usually computed as jump offsets. That is, the switch data value is not so much used in O(n) cascading ifs and else ifs, but as an O(1) index into a function offset table. Even still, such an implementation shouldn't be too hard. I think.)

If you'd like, I could give a terse analysis on the relative implementation complexity for each of my line items.

Regarding llRezObject, you can get the key of the rezzed object with the object_rez() event handler. I don't know of any way to tell if the rez attempt failed, though; a mechanism for obtaining that information would be helpful.

Ah, ok, that's good to know. Duly noted! Thanks!

It'd be easy to tell if llRezObject() failed if it returned NULL_OBJECT. (Urm, or whatever the appropriate constant is. I'm at work and so cannot consult TFM.)

A problem with the method you provide is that things that are closely associated are better implemented within as close to the same lexical scope as possible. That is, if you have two semantically identical implementations, but one has things broken into disparate parts in separate files, and the other has its entire implementation within the same part of one file, the latter implementation is easier to understand and maintain. It's easier for human beings to cognitively link things together the closer those things are to one another. This is one of the touted advantages of object-oriented encapsulation in that the data and the functions that operate on them are forced to be declared within the same lexical scope; pathological configurations whereby the data and its functions are separated are syntactically discouraged.

Urgh. I'm showing I'm an academic again. Pardon me whilst I don my geek pointy hat and sulk in the corner again.

"Academic" is right I didn't even read that last big paragraph...it must have been out of a school.

"Academic" dirty word..

Above I was referring more to the number of suggestions (ahem, they asked for 5 ), although yes some of them are pretty complex. But I'm still sticking to my opinion that I'd rather see more actual game functionality than a switch statement, for example.

I completely agree. I advocate object-oriented encapsulation when possible; alas, LSL makes it difficult.

LSL often uses event handlers when it would be more convenient to the scripter if a library call simply returned a value. I don't know why LSL was designed this way, but my guess (and this is just a guess) is that it's a performance issue. Some of the library calls involve requests that are potentially time-consuming, and LSL's designers figured it'd be better to let the script continue executing instead of making it wait.

For example, llGetNotecardLine doesn't simply return a string, because it might take the system a long time to look up that string. So instead your script goes on about its business and you just wait for your dataserver() event handler to be called when the data is available.

llRezObject seems to work pretty quickly -- it would have to, since it's how guns fire bullets -- but maybe getting the actual key of the rezzed object is time-consuming? (Again, this is pure speculation on my part.)

::nod:: Events are generally difficult to impliment into large-scale scripts which rely on data being passed directly.

I believe that states were created for the purpose of getting around this limitation:

default
{
state_entry() { llGetNotecardLine(); state getData;}
}

state getData
{
dataserver()
{
//Dump data to global string.
state useData
}
}

state useData
{
//Use data here
}

It involves alot of loop-around, bend-the-rules, make-a-mess-and-clean-it-up kind of thinking to actually create a working complex script based on the event principle. But luckily LL provided us with a way we can sort-of encapsulate things, states.

Why not use a sensor?

//Psuedo-code:
default
{
    state_entry()
    {
        llResObject("foo");
    }
    object_rez(key id)
    {
        llSensor(id);
    }
    no_sensor()
    {
        llSay("AIEE!! The rez failed!");
    }
}

You'd need to have a script in each object you'd want to effect using the effector, the effector would then tell the script you put on that object to move the object to a position, rotate the object, etc. There really isnt much of a way you can externally effect objects that the task (script) isnt running in.