Wanted: your top 5 ways to improve scripting

I think moving to Mono would be the biggest help so that I could code in C#.
You could go on improving LSL but it'd still not be as good.

My top 5 ways to improve scripting in LSL are these:

1) Fix known bugs (this will have a more positive effect on productivity than the other 4 put together)
2) Raise the memory limit per script to 128k
3) llDetectedTouchFace(), see http://secondlife.com/vote/index.php?get_id=288
4) Simple but persistent "prim" storage, see http://secondlife.com/vote/index.php?get_id=496
5) A "stateless" state, see /54/d7/52746/1.html

My heartfelt 2 eurocents.

Open script.

Control-A. Control-C. Switch to editor window. Control-A. Control-V.

Edit script.

Control-A. Control-C. Switch back to SL. Control-A. Control-V.



That would be very good.

Test on the preview grid.

-

Simple idea, not so simple to make.

My way (not ways) to improve scripting would be for the lindens to create a program that would easily assemble scripts by drag and drop, or work like "Lilac Soul's Script Generator" For neverwinter nights.

Things I would like:

1. Script 'links' in the sense that ALL SUCH LINKED SCRIPTS refer to the exact same script. Difference over other peoples method is that there is NO MASTER SCRIPT. Use the current permissions system to handle that. If you dont want an end user to change YOUR copy dont give them mod. But if the other person has mod permissions then if they make a change it effects ALL COPIES the same way as if the original script author made the change. This would allow for more collaborative work between fellow coders working on a project together without having to manually keep handing copies back and forth to see each others work.

2. extend the touch() event options. DO NOT ADD any more parameters as this would be unnecessary. You could easily just add llDetectedLink() to get which prim in an object was clicked and llDetectedFace() to tell which face of that prim. I WOULD NOT add a "vector llDetectedXY()" function. Yes this would also be useful but to be honest i dont believe the MAJORITY of coders in SL are responsible/skill enough to use that extra feature effeciently/appropriately.

3. an Advanced Scripting Lisence much like a drivers lisence. I think there are a few scripting features (applying force) that we just have too many people not mature enough to use. You need to take a subset of the library functions and flag them as "responsible only". I would include all functions for applying force on arbitrary targets and the ability to rez other objects in this restricted set. Possibly more but those are the big greiffer ones. To have your avatar flagged as a mature scriptor you would have to attend an Event or even take a test of some kind. People could log onto the preview grid to practice using these functions until they get their lisence to use them in the main grid. The method of enforcement would be that as long as you are lisenced you can create and give out NO MOD versions of scripts containing the restricted functions. But if you are NOT lisenced any MODABLE script containing a restricted function will not activate.


4. full READ / WRITE access to notecards and a generic 'data' type. The data type should NOT be viewable to anyone but the CREATOR. The 'data' object itself will only be readable/writable to a script with the same creator also. A no-mod data thus can only be read by a no-mod script (to preserve the security of the data contents. A mod data file can be accessed by both mod and nomod scripts but STILL only by scripts of the same CREATOR as the data itself. This just preserves the privacy of what can be contained in the data file. And again only the original creator can ever open data files in a viewer.

As a secondary feature if linked scripts are implimented as I suggested above, linked data files should ALSO be available. This could be useful for global lookup tables to help syncronize features. Like a place where scripts or prims can re-register their current id (for use in emails or whatnot).

5. Extend the list of allowable permissions a script can aquire. Force sitting. Force control (walking/facing). 32 bit integer is used for permissions and we dont use NEARLY that many permissions flags. Lets get some more use out of that value.


Things i DO NOT WANT TO SEE in lsl

1. structs. Lets face it the system in use now has bugs already. If you add in the ability to define and create user structs/classes that layer of complexity in the scripting engine could only result in problems that would outweigh the benifits. There are already methods of faking structs or of doing without them. Use them instead.

2. arrays. reasons as with structs as its just an added complexity level that with intelligent design can get done just as easily using lists. Now having access to subscript operators on a list could be useful. The tokenizer itself could just keep track of what variable type the function is being used to retrieve (by where its being assigned to) and just do a conversion on the spot with the appropriate list retreival function. This is superfluous and not really needed by would satiate some more experienced programmers by letting them use a syntax they're more used to.


and SR PUFF:

Listen() isnt an 'active' script because it requires pollings. It is classified as an active script based on the level of server resources required just by having that event there. For each listener created EVERYTHING said on ANY CHANNEL has to get processed by your object. It dont matter what filters you use. EVERYTHING SAID within hearing distances gets checked. If you listen on some channel besides zero then the process load is restricted to a simple integer check (to compare channel) and can effeciently slice out a majority of messages from requiring further processing. But even with filters listening on channel zero (or another that happens to be heavily used with object speach) requires expensive string comparisons on the key, the name and possibly what was said. Even when you dont explicitely put a filter the system still has to check IF you use a filter or not which requires processing time (even if negligible). Thats why its active, because even when execution never makes it to the point of your script itself doing processing, just your script EXISTING is causing some degree of server strain. And this is also why the lindens implimented a "too many listens" error. Bless them for thinking ahead though personally i think the limit needs lowered even further to 24 or 32 max.

That's a bug.

LL could easily maintain separate lists for commonly used channels. Just putting listens on 0 into a different list would be a big win, or listens on 0-9, or even have those lists maintained automatically and cheaply by the sim: when processing a "say" keep a count of the number of objects that matched, and if it's higher than the average* "high use" channel, put that channel into the "high use" list for that sim and periodically drop the lowest one.

Then when something is said on zero, or some other high-use channel, listens on other channels won't even be checked.

* Requiring higher than average should keep the list from shifting too much.

OK what you're syaing requires traversing through YET AN ADDITION list with even MORE checks. Beyond checking JUST the integer value of the channel now you also have to check its range, against a LIST of arbitrary channels.

Down to just the mechanics of it traversing an effecient list maintained by nodes means you have several layers of pointer dereferences going on. Your method would double the server load as far as just the aspect of checking channel validity is concerned. Very bad idea.

With the developement i've currently done im sure that LL doesnt even maintain a list of channels at all. After all its just a simple integer value. When processing what an avatar percieves its as simple as if( !msg.channel ) avatar.process(msg); With an object you would instead check that objects list of how many listen events are attached and if( msg.channel == obj.listens[val].chan ) obj.process( msg );

My point is that filtering by channel probably can NOT get more effecient. The mass of the cpu strain comes when you MATCH channels and then have to check the various strings, which requires traversal thru the list of each letter (even if only a pointer increment) and comparison letter for letter till it hits something different or gets thru the whole string and confirms a match.

*edit

re-read your post and just realized something. By your wording you might not understand that a 'channel' doesnt actually exist anywhere in memory. The server tracks what channel you or an object speaks on by just tagging it with a number and asking objects 'what numbers are you paying attention to'. Thats all. Thats why trying to maintain a list of high use vs low use channels would require MORE resources rather than be an optimization.

1. (key) llGetAttachment(key agent_id, integer attachpoint) - Returns the key of the attachment on an agent at specified agent's attachpoint. NULL_KEY returned for no attachment.

2. Ability to write a notecard.

3. Real multi-dim array support.

I recomend a method by which you could trigger a teleport from a script.

EG. Person has 3-4 locations in distant lands (S)He can develop a chair or other object that the person can sit on.

the person and object are then Teleported to the closest telehub

the object can then be moved with another script command to the final destination where the person wanted to go.

kovu

Seconded. Or even a direct point-to-point teleport only between properties all owned by the same group or individual.

First problem, animations that leave you walking in the ground or floating in the air...

1. llStartAnimationOffset(string animation, vector posOffset, rotation rotOffset);

Then I thought...

2. llStartAnimationPriority(string animation, integer priority);
Plus llSetAvatarOffset(vector posOffset, rotation rotOffset);

Even better...

3. llStartAnimationPartial(string animation, integer boneMask, integer priority);
Plus llSet AvatarOffset(vector posOffset, rotation rotOffset);

Or, to reduce latency and sim load, let the client handle the timing:

4. llStartAnimationList(list animationList, integer priority);
Where animationList = [ animation, boneMask, duration, ... ];
Plus llSetAvatarOffset(vector posOffset, rotation rotOffset);

And finally, I thought, don't we have this already? Add a "bones" and "priority" to the gesture editor, and...

5. llStartGesture(string gesture);
Plus llSetAvatarOffset(vector posOffset, rotation rotOffset);

my list:

1. I know writing to a notecard isn't an option, as the lindens have commented on asset management. But I would like some sort of permenant storage in place that scripts could read and write to.
2. Multi-dimentional arrays (lists work well enough for single arrays)
3. Switch/case would be an excellent speed increase
4. The ability to pass a string to a rezzed object on rez, or even a variable, without involving listens or e-mail. it could be added to the on_rez event of the object. This would allow for object manipulation through set params without alot of needless talking.

That's simply wrong. It all depends on the distribution of messages by channel number. If you can eliminate 50% of all listeners for each message (e.g. 50% of all messages are on channels 0 or 99, 50% are on other channels), then simply dividing it into two lists of listeners will be a big win, even though you have to do an initial check on 0 or 99 at the beginning of each message. More generally, use a hash table on the channel number to separate out into an arbitrary number of lists of listeners - re-evaluate periodically to determine the number of lists in order to keep them distributed properly.

As for string matching, most strings don't match, and don't match early on, so that's actually pretty fast. In addition, you can use hashing for that as well - store the hash of the string (message or name) that's being listened for, hash the values in the message being sent, and do a simple compare. Only do a full string comparison if the hash matches. Make sure that a hash value of 0 can't occur (use that for "match anything".

hay ya i wish thier wass a way to toern off awaymod sow win im in a chaer i wont git logd off

I request that color vectors be not clamped between 0.0 and 1.0 in scripts, but rather, when they are displayed. THe reason for this is that at times you want to fade from one color to a second color, but avoid some hue inbetween. An example would be in a sunset, where you have yellows nearest to the sun, and fading to deep purple/blue. with rgb values, you must pass through green, which does not show in a sunset.

A practical SL application of this is in particles, as we can only have a start color and an end color, so we must accept that intermediate color, like it or not. By easing the number ranges, one can do this:

rgb <1.0, 1.0, 0.0> fading to.... rgb <0.25, -1.0, 0.25> see? at the midpoint of the particle, the green component is 0.0. whithout this, i have to go rgb <0.25, 0.0, 0.25>. This leaves me with a midpoint color of reddish green.

Likewise, one could start with <5.0, 1.0, 0.0> and fade to <0.0, 0.0, 0.0> which causes red to fade 1/5th as fast as the green.

after the color is sent to display, then it can be clamped into valid ranges, sinces its getting changed to an integer at that point anyway.

I feel this adds no overhead at all to Lsl, and broadens scripters options greatly.

Thanks for listening!

Boolean data type!

It's just a tiny integer which stores a 1 or 0, no more, no less.

With the memory limit this would be really handy, seeing as how integers are 32-bits, I could have 32 booleans in that space!

maybe the scripting could accept the new 'gogirrl' type scripting?

example

\\
\if, like, de base colour was, like, red (00ff00 or whatever)
than, like, all other side would be, like, omg, the same colour!
and and, like, if it was spining and flasing (rotation speed = police light)(on/off ratio =
racheal and that dude played by david schwi,scwi, u know who)
then object would be, like, bright aswell (brightness = einstein, yah the apple guy i think)
then object name = disco light like yay!

sorry, couldnt miss the chance....

My list:

1: Arrays
2: Pointers
3: Lists within lists
4: Libraries
5: ASSEMBLY LANGUAGE FOR THE LOVE OF GOD!!

6: A pony! ^_^

I'd like to see a name box at the top when editing a script

Implement Mono

It would relieve me of having to learn an obsure, arcane and propriatry language.

It would save LL some US$ as they would not have to maintain and support an obsure, arcane and propriatry language.

hmm, a cool and intuitive way is to have special bracketing for comments to show to people who do not have mod permissions. So that you are able to see just those comments, which you might use to show a list of functions inside it the user can use. Just a thought

1. Switch / Case
2. Simplified rotation functions (llRotate(<45,0,90> I don't have time for the math )
3. Better land/script detction functions. I would like to know if a script will run on the land before I get there.
4. Find/Replace in editor
5. Writing/creating notecards

*6. AI automated, mind reading, self-scripting function. I want to just think of the script and have it written. Is that pushing it?

Thanks.

Done it. 50 Lindens and its yours.

Scripts in SL are operating in a real-time environment.

I do real-time.

It's WAY more important in real-time work that performance be consistent than it be fast, subject to obvious considerations about "well, what if it's always at least 100 times as fast", though even then it's not always a dead cert that you're better off fast.

Taking a non-real-time language and runtime and integrating it into a real-time environment is REALLY REALLY hard. Particularly when the non-realtime language compiles down to machine code, which any implementation worth using would need to do since it would be doing stuff that's currently implemented in native calls in LSL (because LSL is so much slower than native) in the compiled code.

Consider. If you write an infinite loop in LSL, the LSL runtime can break it and give someone else time because the loop code is aware of what it's doing.

If you write an infinite loop in Mono, it's going to run until the next interrupt.

Even without actual infinite loops, Mono has the potential of being insanely laggy. A handful of computationally heavy Mono scripts could easily use up 100% of the CPU of a sim in a way LSL code couldn't... and it'd be all in unstoppable native code, and LL would have to pretty much completely rearchitect the runtime to avoid this.

If you guys thought 1.7 was a big problem... the first version to use Mono is going to make it look like a picnic.